On 10/12/07, tedd <tedd@xxxxxxxxxxxx> wrote: > > At 7:30 PM -0700 10/11/07, Instruct ICC wrote: > > > > > >Now I see why BCMath was mentioned. > > Yes, but precision is not the issue. > > It doesn't make any difference if you are rounding. > > (a) 1.489123451985765 > > or > > (b) 148912345198576.5 > > You still have to make a decision as to if the above (a) rounds to: > > (a) 1.48912345198577 > > or > > (a) 1.48912345198576 > > or the above (b) rounds to: > > (b)148912345198577 > > or > > (b) 148912345198576 > > It's a question of rounding, not precision. precision is still an issue; after a certain number of digits are used as the argument; round becomes inaccurate. from the cases you listed above (a) 1.489123451985765 bcmath results in one of the possible results you listed, (a) 1.48912345198577; round results in neither possible result. case (b) 148912345198576.5 bcmath results in one of the possible results, (b)148912345198577; round results in neither possible result. this is because the internal binary data type is already filled to capacity when these calculations are imposed on that data. im not sure how bcmath handles this internally, but it appears to be more precise and more accurate. results will vary based on your hardware, but you can use the second tool i passed out to find the breaking point on your system and the first one to test possibilities against the breaking point. nathan@devel ~/working/www $ ./bcRound.php 1.489123451985765 14 round result: 1.48912345199 roundbc result: 1.48912345198577 Numerical Comparison: the results are the same String Comparison: the results are different nathan@devel ~/working/www $ ./bcRound.php 148912345198576.5 0 round result: 148912345199000 roundbc result: 148912345198577. Numerical Comparison: the results are the same String Comparison: the results are different i cant seem to get bcmath to choose the alternate rounding path in either one of the cases. -nathan
