IE and floating-point mathematics?

[Twey]

It just came to my attention that, according to IE's Javascript engine, 0.06 + 0.01 == 0.0699999999999999, but that 0.07 + 0.01 == 0.08.
Also, (element.filters["Alpha"].opacity = 0.58) == 0.57.
Eh?
Any way around this (yet another) apparent bug?

[jscheuer1]

Alpha opacity is from 0 to 100.

[Twey]

Ack, I could have sworn I edited this. Sorry. Yes, I did figure that out. Though how 0.06 + 0.01 comes to be 0.06999999999999999, I've still to figure out. This actually appears in every browser; it's only in IE that it breaks the script (due to alpha opacity not working with decimals). I've sorted it with a parseInt in the right place, but still curious as to why it happened.

[jscheuer1]

Hmm, the easy way around would be to make the script more IEcentric, this also would probably make for simpler math all the way around. Set and compute your numbers as whole numbers, only dividing by 100 for other browsers.

[mwinter]

It just came to my attention that, according to IE's Javascript engine, 0.06 + 0.01 == 0.0699999999999999, but that 0.07 + 0.01 == 0.08.

That's expected.

Also, (element.filters["Alpha"].opacity = 0.58) == 0.57.

A little more curious, but there's a golden rule that applies to such a case.

Eh?
Any way around this (yet another) apparent bug?

It's not a bug, but the inherent inaccuracy of floating-point number formats, and isn't limited to ECMAScript. Not all numbers can be represented exactly, so they may occasionly need to be approximated. Due to this problem, floating-point values shouldn't be compared for equality under most circumstances. A certain amount of error should be factored in, and a relational comparison should be used instead.

If you want exact arithmetic, use integers, preferably using string manipulation to perform the transformation (you've seen my toCurrency function before, right?)

The comp.lang.javascript FAQ has a brief description of this, with more discussion in the group itself.

Mike

[Twey]

The comp.lang.javascript FAQ has a brief description of this

Aha, now I see. I was vaguely aware of the "precision vs. accuracy" problem, but didn't see how it applied; I hadn't considered the problem of intermediates. That's cleared it up for me, and will indubitably be very useful in the future; thanks.

you've seen my toCurrency function before, right?

Indeed. However, the only difficulty here is in deciding in which direction to round; I'm sure no-one's going to notice a 0.00000000001 difference in every opacity step out of fifty.

[jscheuer1]

Switch to integers, you can see examples of this in several DD scripts.

[techno_race]

Literally, 0.06 + 0.01 = 0.07, NOT 0.06999999999999...

[jscheuer1]

Since we seem to be resurrecting this old thread, I thought I might just throw in here that, for many years 'Calculator', which has shipped with Widows (misspelling intentional) from the very beginning, was inaccurate with these or some other basic types of math problems. They finally fixed this late in the reign of 3.01 or, actually I think, 98.

[Bob90]

But isn't the fix to actually calculate the expression to 14 decimal places then round the display to 12 decimal places.
If the 14 decimal places are 0.69999999999999 then to 12 places this is 0.7 ?!?