i just played arround with the parseFloat routine and discovered an error. e.g. parseFloat("5.1" * 100) in mozilla is: 509.99999999999994 ähmmm , it should be 510 ... i also tested netscape 6.x, and internet explorer 5.5 the result was the same... i also wrote a little script, the result was -> ahhhhh can someone explain why ???? testcase with script attached

The main point here is not parseFloat(). The point is raw arithmetic on floating point numbers: 5.1 * 10 51 5.1 * 100 509.99999999999994 5.1 * 1000 5100 5.1 * 10000 51000 5.1 * 100000 509999.99999999994 5.1 * 1000000 5100000 5.1 * 10000000 51000000 5.1 * 100000000 509999999.99999994 5.1 * 1000000000 5100000000 5.1 * 10000000000 51000000000 5.1 * 100000000000 509999999999.99994 5.1 * 1000000000000 5100000000000 5.1 * 10000000000000 51000000000000

From the ECMA-262 Edition 3 Final spec for ECMAScript (at http://www.mozilla.org/js/language/) 11.5.1 Applying the * Operator The * operator performs multiplication, producing the product of its operands. Multiplication is commutative. Multiplication is not always associative in ECMAScript, because of finite precision. The result of a floating-point multiplication is governed by the rules of IEEE 754 double-precision arithmetic: • If either operand is NaN, the result is NaN. • The sign of the result is positive if both operands have the same sign, negative if the operands have different signs. • Multiplication of an infinity by a zero results in NaN. • Multiplication of an infinity by an infinity results in an infinity. The sign is determined by the rule already stated above. • Multiplication of an infinity by a finite non-zero value results in a signed infinity. The sign is determined by the rule already stated above. • In the remaining cases, where neither an infinity or NaN is involved, the product is computed and rounded to the nearest representable value using IEEE 754 round-to-nearest mode. If the magnitude is too large to represent, the result is then an infinity of appropriate sign. If the magnitude is too small to represent, the result is then a zero of appropriate sign. The ECMAScript language requires support of gradual underflow as defined by IEEE 754.

Also see: 8.5 The Number Type The Number type has exactly 18437736874454810627 (that is, 264−253+3) values, representing the doubleprecision 64-bit format IEEE 754 values as specified in the IEEE Standard for Binary Floating-Point Arithmetic, except that the 9007199254740990 (that is, 253−2) distinct “Not-a-Number” values of the IEEE Standard are represented in ECMAScript as a single special NaN value. Here is a reference for IEEE 754: ANSI/IEEE Std 754-1985: IEEE Standard for Binary Floating-Point Arithmetic. Institute of Electrical and Electronic Engineers, New York (1985).

Note the exponential notation from the ECMA spec in Comment #4 got mangled in the copy/paste here; please see the original spec. The point of all this is the following: computers do arithmetic in base 2, not base 10. Certain numbers which have finite decimal expansions in base 10 have infinite decimal expansions in base 2. That, plus the fact that the computer must round off infinite expansions to finite ones, produces the results above. Have to mark this one invalid; this is the way floating-point arithmetic works in any computer language (e.g c/c++) that adheres to the IEEE 754 standard. Compare these bugs, where the same issue was raised: http://bugzilla.mozilla.org/show_bug.cgi?id=20140 "Rounding Error?" http://bugzilla.mozilla.org/show_bug.cgi?id=42134 "JavaScript should be more lenient comparing (==) floats"

Marking Verified. Thank you for this report; this is certainly an unexpected behavior the first time you see it -