1. Re: Whats the problem in this function?<decoded from the
Steve Lee writes:
> --1648.17400 rounded down by digit 2 into 1600.00000
> --1648.17400 rounded down by digit 1 into 1640.00000
> --There's no digit 0!
> --1648.17400 rounded down by digit -1 into 1648.00000
> --1648.17400 rounded down by digit -2 into 1648.10000
> --1648.17400 rounded down by digit -3 into 1648.17000
> --1648.17400 rounded down by digit -4 into 1648.17300
> problem starts to occur!! expecting
> -- 1648.17400!!
> --1648.17400 rounded down by digit -5 into 1648.17390
> --1648.17400 rounded down by digit -6 into 1648.17399
>
> -- I know many other excellent routines for this job but i still want to
> know WHAT IS THE
> -- PROBLEM IN MY ALGORITHM!!
You've fallen into a trap that occurs in most programming
languages, except maybe Cobol and some forms of Basic.
Floating-point numbers are typically stored
in binary, not decimal. Integers such as 1648 can be represented
exactly. Fractions such as .5 (one half), .25 (one quarter), .125
(one eighth) can be represented *precisely* as binary fractions.
Numbers such as .1 or .4 cannot. .4 will be mapped to the closest
binary fraction, which could be .39999999999999999999...
If you multiply this by 100 and floor it, you get floor(39.99999...)
or 39, not 40 as you expected. There was a big discussion
about this before on this mailing list. Check the archives.
Cobol gets around this by having a data type that stores
*decimal* fractional digits - 2 digits (0..99) per byte.
This avoids problems with rounding off pennies. People
get mad when your floor() function cheats them out of a penny.
I think Cobol also supports binary floating-point as a separate
data type.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
