> There are already Strawmans for Number.MAX_INTEGER and Number.EPSILON:
http://wiki.ecmascript.org/doku.php?id=strawman:number_max_integer
That page has MAX_INTEGER as 2^53. While strictly correct in floating-point,
it is conventional to have (2^n)-1 for a n-bit integer. IEEE binary64 numbers
have 53 bits of precision (including the "hidden" bit), so I prefer MAX_INTEGER
= 2^53-1 = 9007199254740991.
(As a power-of-two 2^53 has a "funny" representation -- its significand is all
0s except for the unstored hidden bit. Whereas 2^53-1 has a representation
that looks very similar to almost all other integers.)
> Regarding Math.sign versus Math.signum
> In (written) mathematics "sgn" is often used. But I think Math.sign is fine
> as well.
> In my opinion sign and sine aren't similar enough to be confused.
Doesn't Java use signum? JavaScript seems to follow Java's philosophy in many
ways. Another vote for "signum" in addition to my previous points IMHO.
> There might be other use cases for Number.EPSILON, but comparing numbers with
> a tolerance of Number.EPSILON isn't working that good. Number.EPSILON is in
> many cases to small. Right now I'm using 3e-15.
Comparing numbers with a tolerance is not what EPSILON is for. For that see
the bible: D.Knuth "The Art of Computer Programming : Seminumerical Algorithms"
section 4.2.2 "Accuracy of Floating Point Arithmetic". When comparing any
number x>=2, EPSILON is effectively 0.
3e15 is approx 2^-48 thus discriminates the lower 6 bits of numbers in the
range [1,2); (all significands are in this range). 3e15 is effectively 0 when
trying to discriminate numbers >=2^6.
An exact mathematical value lies between floating-point number x and x+EPSILON
or x-EPSILON when scaled to the exponent (i.e. normalised). EPSILON bounds the
rounding error in the significand.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
