RE: [mru] [MVM:BUG] fatal arithmetic bug still in v5.01

Greetings Merchant and Miva Script users,

The behavior described so far actually isn't a math bug. It's just that
there is more to the issue of how computers calculate and store floating
point numbers, and how they use integer operations in floating point
arithmetic. Following is an explanation of this.

Floating point arithmetic introduces an inherent amount of imprecision,
and application writers need to be aware of the implications of using
rounding and integer operations on calculated floating point values.

The expression provided for discussion (100*(1-0.9)) creates a floating
point number *very close to* (but not exactly) 10. The internal floating
point representation when shown to 20 digits of precision is:
9.99999999999999822364e+00. =20

The integer value of this number is 9. In other words, INT and FLOOR
operations on numbers very close to a specific integer value may provide
unexpected- but not incorrect- results. Whereas the integer value of
this number *after* rounding it to two digits of precision (10.00) will
be 10.

The main points to keep in mind are as follows:

1. Miva Script handles floating point arithmetic in the same way as
other programming languages including C, C++, PHP, and others...=20

2. After performing math operations such as price group adjustments,
Miva Merchant rounds to two digits of precision, eliminating the
floating point issue. So in any case, it will yield the correct result
for handling currency.

James Harrell
Director of Software Development
Miva Corporation
<[email protected]>
858-731-4121 Direct
858-731-4200 Fax
858-735-1294 Cellular
=20

RE: [mru] [MVM:BUG] fatal arithmetic bug still in v5.01



On Mon, 25 Apr 2005 16:55:15 -0700, Harrell, James E.
<[email protected]> gave utterance to the following:

> Greetings Merchant and Miva Script users,
>
> The behavior described so far actually isn't a math bug. It's just that
> there is more to the issue of how computers calculate and store floating
> point numbers, and how they use integer operations in floating point
> arithmetic. Following is an explanation of this.
>
> Floating point arithmetic introduces an inherent amount of imprecision,
> and application writers need to be aware of the implications of using
> rounding and integer operations on calculated floating point values.
>
> The expression provided for discussion (100*(1-0.9)) creates a floating
> point number *very close to* (but not exactly) 10. The internal floating
> point representation when shown to 20 digits of precision is:
> 9.99999999999999822364e+00.
>
> The integer value of this number is 9. In other words, INT and FLOOR
> operations on numbers very close to a specific integer value may provide
> unexpected- but not incorrect- results. Whereas the integer value of
> this number *after* rounding it to two digits of precision (10.00) will
> be 10.
>
> The main points to keep in mind are as follows:
>
> 1. Miva Script handles floating point arithmetic in the same way as
> other programming languages including C, C++, PHP, and others...
>
> 2. After performing math operations such as price group adjustments,
> Miva Merchant rounds to two digits of precision, eliminating the
> floating point issue. So in any case, it will yield the correct result
> for handling currency.
>

It would be nice if there was a system command <MvPRECISION value="4">
which would automatically round the results of each calculation stage
(e.g. parenthesis) to the set value (about 2 digits more than the desired
end value precision would be optimal)
--
Richard Grevers
Between two evils always pick the one you haven't tried

mvinclude compilation problem...



Hi all,

I tried many times to use mvinclude and I never succeeded to compile the
file because the compiler close with general exception. Here what I found in
the debug mode: Unhandled exception at 0x0041da1d in mvc1.exe: 0xC0000005:
Access violation reading location 0x00000000. and when I look in the
disassembly mode I got the pointer to the following line:
0041DA1D mov edx,dword ptr [ecx]

Ok I'll admit that I tested it without any file specified ( <MvINCLUDE
file=""> ) but anyhow I get my compiler crushed..
My compiler version: 1.13. My OS: XP Pro French version.

Another small question.. does anybody know when the new compiler will be
available.. ?

Best regards,
Claudiu

RE: [mru] [MVM:BUG] fatal arithmetic bug still in v5.01



James,

When "eliminating the floating point issue" by rounding, MIVA VM
has a rotten tendency to turn what should be displayed as "0.00"
into "-0.00" which is stupid.

Can you please see if that issue can be addressed.

P.S. Congratulations on your new job, I hope it works out well
for you.

- Jeff Huber
President, 4TheBest eCommerce Solutions
http://4TheBest.com
[email protected]
Office: 760-742-1469
Cell: 760-445-8454
=20

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Harrell, James E.
Sent: Monday, April 25, 2005 4:55 PM
To: [email protected]; [email protected]
Subject: [meu] RE: [mru] [MVM:BUG] fatal arithmetic bug still in
v5.01


Greetings Merchant and Miva Script users,

The behavior described so far actually isn't a math bug. It's
just that
there is more to the issue of how computers calculate and store
floating
point numbers, and how they use integer operations in floating
point
arithmetic. Following is an explanation of this.

Floating point arithmetic introduces an inherent amount of
imprecision,
and application writers need to be aware of the implications of
using
rounding and integer operations on calculated floating point
values.

The expression provided for discussion (100*(1-0.9)) creates a
floating
point number *very close to* (but not exactly) 10. The internal
floating
point representation when shown to 20 digits of precision is:
9.99999999999999822364e+00. =20

The integer value of this number is 9. In other words, INT and
FLOOR
operations on numbers very close to a specific integer value may
provide
unexpected- but not incorrect- results. Whereas the integer value
of
this number *after* rounding it to two digits of precision
(10.00) will
be 10.

The main points to keep in mind are as follows:

1. Miva Script handles floating point arithmetic in the same way
as
other programming languages including C, C++, PHP, and others...=20

2. After performing math operations such as price group
adjustments,
Miva Merchant rounds to two digits of precision, eliminating the
floating point issue. So in any case, it will yield the correct
result
for handling currency.

James Harrell
Director of Software Development
Miva Corporation
<[email protected]>
858-731-4121 Direct
858-731-4200 Fax
858-735-1294 Cellular
=20

RE: [mru] [MVM:BUG] fatal arithmetic bug still in v5.01



Yes, I have also ran into a few issues where a very low neg. number (ie.
-.001) gets rounded to -0.00.

Bill M.

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Jeff
> Huber - Listmail
> Sent: Thursday, April 28, 2005 8:44 AM
> To: 'Harrell, James E.'; [email protected];
> [email protected]
> Cc: [email protected]
> Subject: RE: [meu] RE: [mru] [MVM:BUG] fatal arithmetic bug
> still in v5.01
>
>
> James,
>
> When "eliminating the floating point issue" by rounding, MIVA
> VM has a rotten tendency to turn what should be displayed as
> "0.00" into "-0.00" which is stupid.
>
> Can you please see if that issue can be addressed.
>
> P.S. Congratulations on your new job, I hope it works out
> well for you.
>
> - Jeff Huber
> President, 4TheBest eCommerce Solutions
> http://4TheBest.com
> [email protected]
> Office: 760-742-1469
> Cell: 760-445-8454
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Harrell, James E.
> Sent: Monday, April 25, 2005 4:55 PM
> To: [email protected]; [email protected]
> Subject: [meu] RE: [mru] [MVM:BUG] fatal arithmetic bug still in v5.01
>
>
> Greetings Merchant and Miva Script users,
>
> The behavior described so far actually isn't a math bug. It's
> just that there is more to the issue of how computers
> calculate and store floating point numbers, and how they use
> integer operations in floating point arithmetic. Following is
> an explanation of this.
>
> Floating point arithmetic introduces an inherent amount of
> imprecision, and application writers need to be aware of the
> implications of using rounding and integer operations on
> calculated floating point values.
>
> The expression provided for discussion (100*(1-0.9)) creates
> a floating point number *very close to* (but not exactly) 10.
> The internal floating point representation when shown to 20
> digits of precision is: 9.99999999999999822364e+00.
>
> The integer value of this number is 9. In other words, INT
> and FLOOR operations on numbers very close to a specific
> integer value may provide
> unexpected- but not incorrect- results. Whereas the integer
> value of this number *after* rounding it to two digits of precision
> (10.00) will
> be 10.
>
> The main points to keep in mind are as follows:
>
> 1. Miva Script handles floating point arithmetic in the same
> way as other programming languages including C, C++, PHP, and
> others...
>
> 2. After performing math operations such as price group
> adjustments, Miva Merchant rounds to two digits of precision,
> eliminating the floating point issue. So in any case, it will
> yield the correct result for handling currency.
>
> James Harrell
> Director of Software Development
> Miva Corporation
> <[email protected]>
> 858-731-4121 Direct
> 858-731-4200 Fax
> 858-735-1294 Cellular
>
>
>