I wonder why Miva didn't have the "0.9 in binary" problem back in Empresa
v3.x -- perhaps their compiler is causing the problem.
Tom
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Nicholas Vrtis
> Sent: Thursday, April 21, 2005 8:31 PM
> Cc: [email protected]; [email protected]
> Subject: Re: [mru] [MVM:BUG] fatal arithmetic bug still in v5.01
>
>
> 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.... ~:-)
>
> 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.
>
> 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....
>
> Nick
>
> Ivo Truxa wrote:
>
> >I've been contacted by Miva and it was explained to me that if the
> result of
> >the expression 100*(1-0.9) - 10 was equal to zero in Empresa v3,
> it was in
> >fact a bug. Whatever illogically it may sound, 100*(1-0.9) - 10 won't never
> >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() and
> >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 similarly
> >"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 long
> >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 engine
> >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=TRUXOFT-MMDIAG) reports">http://www.mivacentral.com/truxoft/?...TRUXOFT-MMDIAG) reports</A>
> >that the old fatal arithmetic rounding bug is still kicking in the freshly
> >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 stores,
> >and cause big damage if wrong amounts are billed through payment gateways.
> >
> >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 simple
> >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="{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="{100*(1-0.9)}"> /
> ><MvEVAL EXPR="{100*(1-0.9) - 10}"> /
> ><MvEVAL EXPR="{int(100*(1-0.9))}"> /
> ><MvEVAL EXPR="{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 expression
> ><MvEVAL EXPR="{100*(1-0.9)}"> returns "1" instead of "10"
> >
> >Example:
> >
> ><MvEVAL EXPR="{100*(1-0.9)}"> /
> ><MvEVAL EXPR="{100 * (1 - 0.9)}"> /
> ><MvEVAL EXPR="{100.00 * (1 - 0.9)}"> /
> ><MvEVAL EXPR="{100.00 * (1.00 - 0.90)}"> /
> ><MvEVAL EXPR="{100.00 * ((1 - 0.9) ROUND 2)}"> /
> ><MvEVAL EXPR="{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
> >
> >
> >
> >