Equality...

[ataru]

From the FAQ:

"Non-integer results should not normally be compared for equality."

Now, I understand why this ends up being true, but then what is the workaround
should one actually desire to see whether 1.015 * 5 == 5.075? I'm not saying
I have any desire to do this (I'd use C if I did, lol...), but really, it
seems like a cheap hack to me... unless I'm missing something...

 

[Richard Cornford]

From the FAQ:

"Non-integer results should not normally be compared for equality."

Now, I understand why this ends up being true, but then what is
the workaround should one actually desire to see whether
1.015 * 5 == 5.075? I'm not saying I have any desire to do this
(I'd use C if I did, lol...), but really, it seems like a cheap
hack to me... unless I'm missing something...

What seems like a cheap hack? If you want to know whether the IEEE
double precision floating point representation of 1.015 multiplied by
the IEEE double precision floating point representation of 5 equals the
IEEE double precision floating point representation of 5.075 then
JavaScript will tell you that, as specified. The result will be
"correct" it just may not be a useful question to ask.

Richard.

 

[ataru]

it just may not be a useful question to ask.

denseness alert! -> In what way is it not useful? I guess specifically, how
is it different from asking the same question in, say, C?

 

[Lasse Reichstein Nielsen]

denseness alert! -> In what way is it not useful?

If the answer to the question "5.0 * 1.015 == 5.075" is "false",
how much wiser are you?

As Richard Cornford said, you know that the result of using IEEE
double precission floating point multiplication on the IEEE double
precission floating point representations of 5.0 and 1.015, is not the
same as the IEEE yadda yadda representation of 5.075.

And then what?

I guess specifically, how is it different from asking the same
question in, say, C?

It's not. The problem is the same in any language using inexact
representation of numbers (i.e., all languages).

/L

 

[Richard Cornford]

Richard Cornford <[email protected]> broke the eternal silence and spoke thus:


denseness alert! -> In what way is it not useful? I guess
specifically, how is it different from asking the same
question in, say, C?

It is not useful in the sense that - (1.015 * 5 == 5.075) - is false
because all of the numbers involved are IEEE double precision
representations of the numbers in the code and as a result are usually
(close) approximations of those numbers. You could consider yourself
lucky if multiplying one approximation by another comes up with the same
number as a third approximation even when that would be the result of
performing the multiplication and comparison on the original numbers.
JavaScript numbers are so precise that they don't have to differ by much
to be not identical.

If you asked the *same* question in C (using IEEE double precision
floats) you would get the same answer, so the question is exactly as
useful.

It is not a problem unique to computer representations of floating point
numbers. Consider a decimal fraction representing one third - 0.3333 -,
does 0.3333 * 3 == 1 -? But in base 3 one third could be represented
precisely (0.1 * 10 == 1).

You still haven't said what precisely it is you consider a hack.

Richard.

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in
news:comp.lang.javascript, (e-mail address removed) posted at Wed, 20
Aug 2003 20:11:02 :-

From the FAQ:

"Non-integer results should not normally be compared for equality."

Now, I understand why this ends up being true, but then what is the workaround
should one actually desire to see whether 1.015 * 5 == 5.075?

1015 * 5 == 5075

Except when actually testing the properties of IEEE Double arithmetic,
any reasonable problem using the equality of non-integers can be
transformed into an equivalent problem using integers. Javascript
integers are exact up to 2^53 = 9,007,199,254,740,992.

 

[Grant Wagner]

From the FAQ:

"Non-integer results should not normally be compared for equality."

Now, I understand why this ends up being true, but then what is the workaround
should one actually desire to see whether 1.015 * 5 == 5.075? I'm not saying
I have any desire to do this (I'd use C if I did, lol...), but really, it
seems like a cheap hack to me... unless I'm missing something...

Design a BigDecimal (or similar) class which gives you exact precision to some
arbitrary number of decimal points. <url:
http://java.sun.com/j2se/1.4.2/docs/api/java/math/BigDecimal.html /> gives you
documentation for the types of API calls you'll need in such a class. Things like
..compareTo(BigDecimal val), .divide(BigDecimal val), .multiply(BigDecimal val)

The actual Java source code might be extremely valuable in implementing these
methods, although because it's inherited from java.lang.Number, it might be
slightly more difficult then copying and pasting the Java code into JavaScript and
modifying the syntax

Anyway, assuming you wrote or found a BigDecimal class somewhere, the answer to
your question would be (in Java, the JavaScript equivalent would be very similar):

double one = 1.015;
double two = 5.0;
double result = 5.075;

new BigDecimal(String.valueOf(one)).multiply(new
BigDecimal(String.valueOf(two))).compareTo(new BigDecimal(String.valueOf(result)))
== 0


There are times when you wish to perform exact arithmetic operations on floating
point values (such as financial calculations), however in those cases, its usually
best to store the values as longs (integer) values and simply convert the final
result:

var one = 10150;
var two = 50000;
var result = 50750;

function unpow() {
var power = arguments[arguments.length - 1];
var total = 1;

for (var i = arguments.length - 2; i >= 0; --i) {
total *= arguments;
}

return total / Math.pow(Math.pow(10, power), arguments.length - 1);
}

document.write(unpow(one, two, 4) == unpow(result, 4));

--
| Grant Wagner <[email protected]>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-developer/upgrade_2.html

 

[Jim Ley]

If you asked the *same* question in C (using IEEE double precision
floats) you would get the same answer, so the question is exactly as
useful.

Ed. 4 a long time ago back when the minutes of meetings etc. was
public were talking about switching to decimal arithmetic, if Ed. 4
comes out ever (some rumour about 1st qtr 2004) then we might see it.
That would unlikely be relevant to client-side code for years though.

Jim.

 

[Evertjan.]

Dr John Stockton wrote on 21 aug 2003 in comp.lang.javascript:

Javascript integers are exact up to 2^53 = 9,007,199,254,740,992.

Then there must also be inexact integers ?

9,007,199,254,740,992 + 1 ?

 

[Lasse Reichstein Nielsen]

Then there must also be inexact integers ?

9,007,199,254,740,992 + 1 ?

Yes
(9007199254740992 == 9007199254740993)
is true.
/L

 

[Jim Ley]

Does that mean a proposed change to the internal representation of the
existing Number type ("switching" would imply so), or an additional
number type?

I dunno, it was only minutes and they were somewhat cryptic, I think
there was certainly some discussion on it, I doubt very much it would
be a straight replacement.

It wouldn't necessarily remove the problem, - (((1/3) * 3) == 1) - would
still be false, just move it to a decimal representation of numbers

True, but it would allow us to do things like legal work in
calculating the sales tax in Euros (which requires decimal arithmetic
I believe to be legal - I don't the penalty!) There's no decimal
library in JS (there probably is actually, but nothing built in etc.)
unlike other major langs that do that sort of calculation so it's
important for JS to have it I believe.

Can current FPUs do maths with decimal representations as input/output?

Don't know, but I think there's lots of work on doing them efficiently
now, there's also http://www2.hursley.ibm.com/decimal/ which
specifically mentions ECMA 334 ( C# ) in the decimal standards - ECMA
334 is the same folk doing javascript... they obviously like it.

Jim.

 

[Richard Cornford]

I dunno, it was only minutes and they were somewhat cryptic, I
think there was certainly some discussion on it, I doubt very
much it would be a straight replacement.

Hmm. A new number type would be difficult, it would require changes to
type-converting rules. You wouldn't want numbers that would have
previously become IEEE floats unexpectedly becoming decimal types. Maybe
a new built in Object to represent decimal numbers, with C++ style
operator overloading behind the scenes so it could work with (some)
maths operators directly (and its own new DecimalNumber literal format).

... it would allow us to do things like legal work in
calculating the sales tax in Euros (which requires decimal
arithmetic I believe to be legal - I don't the penalty!) ...

<snip>

I bet a few people's hearts skipped a beat reading that.

Richard.

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in
Richard Cornford

Can current FPUs do maths with decimal representations as input/output?
The last time I had to directly program an FPU (10 years ago plus) they
used an 80 bit mantissa + 40 bit exponent format internally and only
accepted/produced input/output in IEEE 32 bit and 64 bit formats.

For an exponent, 40 bits is a lot.

What I recall is that they use the 80-bit IEEE format, available in
Pascal/Delphi as "extended" internally, though perhaps with a couple of
guard bits. Their I/O formats are 32-bit float (single), 64-bit float
(double), 80-bit float (extended), and 64-bit integer (comp).
Javascript uses IEEE double for Number/

Extended has Sign Bit, 15 Exponent Bits, and 64 Mantissa Bits with the
binary point following the first; my pas-type.htm#FF refers.

H'mmm - I'm referring to the FPU of the PC; you might not be.