"0.9 cannot be represented exactly in binary"
Not in a million years (or 1,000,000.00000043479 years) would I have
thought about that. Thanks for an excellent explanation.
On 4/21/05, Nicholas Vrtis <[email protected]> wrote:
> Ivo, it is perfectly logical. Standard mathematics... You can't make
> 100/3 - 33.33 come out to zero in decimal either for the same reason...
> 1/3 cannot be represented exactly in decimal. 0.9 cannot be represented
> exactly in binary. There are techniques which can help if you want to
> limit your range of numbers.... Integer arithmetic 100*(10-9) - 100 with
> an implied decimal point.... but that limits you to one decimal point
> (or a fixed decimal point at least).. and division gets messy. There are
> some routines available that do exact decimal arithmetic... That might
> help somewhat.. but somebody that gives a 33% discount on a list of
> products and forgets to ROUND could have an invoice that does not add
> up.... Or we could all change to Yen instead of dollars.... ~:-)
>=20
> Fun with numbers... In the early days of banking automation there were a
> few programmers who supplemented their meager salaries by collecting the
> penny fractions into their own account.
>=20
> See <A HREF ="http://www.visoracle.com/sat/cc/float-precision.html for some">http://www.visoracle.com/sat/cc/float-precision.html for some</A>
> additional information....
>=20
> Nick
>=20
> Ivo Truxa wrote:
>=20
> >I've been contacted by Miva and it was explained to me that if the resul=
t of
> >the expression 100*(1-0.9) - 10 was equal to zero in Empresa v3, it wa=
s in
> >fact a bug. Whatever illogically it may sound, 100*(1-0.9) - 10 won't ne=
ver
> >more return zero, and no programmer should expect it. Same goes for many
> >other similar expressions, and also for the use of the functions int() a=
nd
> >floor() - int(100*(1-0.9)) or floor(100*(1-0.9)) will never return the
> >expected 10, but rather just 9.
> >
> >Told in other words, the illogical results are not considered a bug, but
> >rather an improvement of the engine. The results now better match simila=
rly
> >"correct" results in other languages (PHP, C).
> >
> >The consequence for Miva Script developers: double check all expression
> >using int(), floor() and all conditions checking for zero values - as lo=
ng
> >as they handle non-integer values, you'll have to use ROUND or another
> >similar technique to receive the expected effect.
> >
> >The behaviour is not considered "bug". It is a "bug fix".
> >
> >I sincerely apologize to Miva Co. for incorrectly asking to pull the eng=
ine
> >off any server. Developers, please change your scripts and your logic
> >instead.
> >
> >Ivo Truxa
> >
> >| http://miva.truxoft.com
> >| Advanced Miva Merchant modules
> >
> >
> >
> >
> >
> >
> >
> >-----Original Message-----
> >From: Ivo Truxa
> >
> >MmDIAG (<A HREF ="http://www.mivacentral.com/truxoft/?product=3DTRUXOFT-MMDIAG) re=">http://www.mivacentral.com/truxoft/?...TRUXOFT-MMDIAG) re=</A>
ports
> >that the old fatal arithmetic rounding bug is still kicking in the fresh=
ly
> >announced Empresa v5.01. See my report from 2004 below. It still has the
> >same effect in v5.01 too.
> >
> >The results from ME v5.01 (FreeBSD):
> >10 / -0.00000000000000177636 / 9 / 9
> >
> >Should be:
> >10 / 0 / 10 / 10
> >
> >I am afraid that the engine should be immediately pulled off any server =
- I
> >can easily imagine that such a huge error can completely wreck some stor=
es,
> >and cause big damage if wrong amounts are billed through payment gateway=
s.
> >
> >Ivo
> >http://mivo.truxoft.com
> >
> >
> >-----Original Message-----
> >From: Ivo Truxa [mailto:[email protected]]
> >Sent: Sunday, June 20, 2004 7:58 PM
> >To: '[email protected]'
> >Cc: '[email protected]'
> >Subject: RE: [MVM:BUG] fatal arithemtic bug
> >
> >Almost a year ago I reported a bug giving completely wrong results at si=
mple
> >arithmetic operations. This bug was supposedly fixed in the following VM
> >version.
> >
> >Unfortunately, I just found that only a secondary cosmetic effect of the=
bug
> >was resolved, but the serious bug itself is still causing fatally wrong
> >results in many arithmetic calculations.
> >
> >The original bug was as follows: the code <MvEVAL EXPR=3D"{100*(1-0.9)}"=
>
> >displayed "1" instead of the correct "10" as the result. Current engine
> >versions display correctly "10", but the value itself, and any further
> >operations with the values, still give wrong results. Try this code:
> >
> ><MvEVAL EXPR=3D"{100*(1-0.9)}"> /
> ><MvEVAL EXPR=3D"{100*(1-0.9) - 10}"> /
> ><MvEVAL EXPR=3D"{int(100*(1-0.9))}"> /
> ><MvEVAL EXPR=3D"{floor(100*(1-0.9))}">
> >
> >Correctly it should return: 10 / 0 / 10 / 10
> >Older VM version return: 1 / -0.00000000000000177636 / 9 / 9
> >Current VM returns: 10 / -0.00000000000000177636 / 9 / 9
> >
> >It means only the cosmetic MvEVAL was fixed, but further handling of the
> >value still results in completely wrong values.
> >
> >Like at many other bugs, this one is also being detected and reported by=
the
> >MmDIAG/TxDIAG v2.00 diagnostic tool.
> >
> >Ivo
> >http://mivo.truxoft.com
> >
> >
> >
> >-----Original Message-----
> >From: Ivo Truxa
> >Sent: Monday, August 18, 2003 5:40 PM
> >
> >Unlike what expected and what v3.9 correctly returns, in MVM the express=
ion
> ><MvEVAL EXPR=3D"{100*(1-0.9)}"> returns "1" instead of "10"
> >
> >Example:
> >
> ><MvEVAL EXPR=3D"{100*(1-0.9)}"> /
> ><MvEVAL EXPR=3D"{100 * (1 - 0.9)}"> /
> ><MvEVAL EXPR=3D"{100.00 * (1 - 0.9)}"> /
> ><MvEVAL EXPR=3D"{100.00 * (1.00 - 0.90)}"> /
> ><MvEVAL EXPR=3D"{100.00 * ((1 - 0.9) ROUND 2)}"> /
> ><MvEVAL EXPR=3D"{100-100*0.9}">
> >
> >Results in v3.xx (correct):
> >10 / 10 / 10 / 10 / 10 / 10
> >
> >Results in MVM v4.07 and v4.09 (wrong except of the last two):
> >1 / 1 / 1 / 1 / 10 / 10
> >
> >I wonder that nobody experienced any problems with it yet. It must often
> >return wrong results even in Miva Merchant!
> >
> >Ivo
> >http://mivo.truxoft.com
> >
> >
> >
> >
Comment