----- Original Message -----
From: "Jon Anderson" <jon@xxxxxxxxxxxxxxxxxx>
tg-php@xxxxxxxxxxxxxxxxxxxxxx wrote:
hah yeah, always worth a little skepticism, but it seemed to make some
kind of sense. If you always round up or always round down, that's
obviously not right and you end up losing potentially a lot of money or
over-estimating the money involved.
Founding up for 5 through 9 and down for 0 through 4 seems like it makes
some kind of sense, but apparently it doesn't work out that way.
I'm sure someone out there knows what I'm talking about (it might be the
first time, but I know I'm not making this up hah), but rounding 0.75 up
to 0.8 and 0.65 down to 0.6 (or vice versa) is supposed to be more
accurate or at least leads to fewer anomalies.
Someone feel like writing a quick script that generates random numbers
and does the rounding based on these two ideas (doing it the 'hard way')
and see how much variation there is after like 10,000 iterations? If I
have time later, I'll do it. Now I'm even more curious.
I wasn't aware of the accounting trick before today, but I believe I can
explain it: If your numbers are statistically random, then the above
solution will lead to an even distribution of rounding up and rounding
down.
The reason is simple:
0: No rounding. It's already there. (8.0 doesn't need to be rounded to 8 -
it already *is* 8.)
1-4: You round down -> 4 of 9 times you round down.
5-9: You round up -> 5 of 9 times you round up.
That is not quite correct, there is no such 4 ninths agains 5 ninths. You
round down in the interval from 0 to0.499999999 and you round up from 0.5 to
0.9999999. If you substract the .5 from 0.99999, you get 0.4999999 so it is
about the same interval for both.
If there is any difference, and actually there is, is because any number is,
in reality, truncated, and not rounded, at some point. Depending on the
number of bits of the mantissa, it might be a long way off, but eventually,
it will happen, and that one is truncation, nor rounding, and if you repeat
any calculation involving fractional numbers, it will eventually add up to
something noticeable.
Actually, there is the further problem that computers actually use binary,
not decimal, so they cannot represent decimal numbers exactly. To offer an
example of what I'm talking about, 1/3, which results in a never ending
0.333333 is exactly 0.1 in base 3 arithmetic! Conversely, many 'round'
numbers in our decimal notation are not 'round' in binary and viceversa. So
it is all the piling of lots of rounding errors in real-life number
representations that produce the error, not the mathematics of rounding,
which actually work in an abstract world of infinitely precise number
representations (in other words, infinite bits to represent any numbers).
Satyam
So you round up 11.1% more often than you round down. As a result, if you
round up when it's odd, and down when it's even, you eliminate the 11.1%
difference in when you'd round up then round down.
That said, if someone were aware of the above rounding trick, it wouldn't
take someone very much effort to come up with things like "fee structures"
or "pricing structures" that could take advantage of that scheme to force
rounding errors to remain permanently in the person's favor.
I certainly hope that PHP continues to use the standard technique, and not
the "accounting trick" above. :-)
jon
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.441 / Virus Database: 268.17.37/682 - Release Date:
12/02/2007 13:23
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
