When it comes to numerical accuracy, there is some variation in the level of
specification in ECMAScript, sometimes the numerical requirements are specified, and sometimes not, for example,
(1) The +, -, *, / operators are defined as in IEEE 754-2008.
(2) Comparing numbers are defined as in IEEE 754-2008.
(3) Constants are correctly rounded.
(4) The % operator has its own definition, different than remainder in
IEEE 754-2008.
(5) Functions inside Math are implementation defined, with a recommendation
that you should use fdlibm (www.netlib.org/fdlibm).
(1)-(4) are well defined, reasonable, etc.
But (5) does not make sense, leaving all the functions inside of Math
implementation defined with a recommendation is a bit weird. There should be
some limit on how wrong a result can be (should sin(x) -> 12.0 for almost all
x) be allowed?
Most (all?) implementations of ES5 provide reasonable implementations of the
Math object, it to some extent is a non-issue, but specififying the
requirements would mean that you could be sure that all ES6 conforming
implementations provide accurate results.
As I see it, there are three reasonable levels of specification,
(I) Follow IEEE 754-2008 and provide correctly rounded functions.
(II) Follow fdlibm (as current recommendation) and provide functions that give
at most 1ulp worth of error.
(III) Follow OpenCL (Table 7.2, page 319 in the OpenCL 1.2 specification) and
provide more generous limits for the maximum errors. (All current ES5
implementations could probably pass the OpenCL 1.2 limitations, unless they
have some bugs that I am unaware of)
(I) would be significantly slower and more difficult to implement than (II) or
(III). (II) and (III) are essentially the same in speed and usability, but (II)
has stricter requirements.
Or is there any good reason why the Math object is implementation defined?
// Jens Nockert
When it comes to numerical accuracy, there is some variation in the level of
specification in ECMAScript, sometimes the numerical requirements are specified, and sometimes not, for example,
(1) The `+`, `-`, `*`, `/` operators are defined as in IEEE 754-2008.
(2) Comparing numbers are defined as in IEEE 754-2008.
(3) Constants are correctly rounded.
(4) The `%` operator has its own definition, different than `remainder` in
IEEE 754-2008.
(5) Functions inside `Math` are implementation defined, with a recommendation
that you should use fdlibm (http://www.netlib.org/fdlibm/).
(1)-(4) are well defined, reasonable, etc.
But (5) does not make sense, leaving all the functions inside of `Math`
implementation defined with a recommendation is a bit weird. There should be
some limit on how wrong a result can be (should sin(x) -> 12.0 for almost all
x) be allowed?
Most (all?) implementations of ES5 provide reasonable implementations of the
Math object, it to some extent is a non-issue, but specififying the
requirements would mean that you could be sure that all ES6 conforming
implementations provide accurate results.
As I see it, there are three reasonable levels of specification,
(I) Follow IEEE 754-2008 and provide correctly rounded functions.
(II) Follow fdlibm (as current recommendation) and provide functions that give
at most 1ulp worth of error.
(III) Follow OpenCL (Table 7.2, page 319 in the OpenCL 1.2 specification) and
provide more generous limits for the maximum errors. (All current ES5
implementations could probably pass the OpenCL 1.2 limitations, unless they
have some bugs that I am unaware of)
(I) would be significantly slower and more difficult to implement than (II) or
(III). (II) and (III) are essentially the same in speed and usability, but (II)
has stricter requirements.
Or is there any good reason why the Math object is implementation defined?
// Jens Nockert
When it comes to numerical accuracy, there is some variation in the level of specification in ECMAScript, sometimes the numerical requirements are specified, and sometimes not, for example,
(1) The
+,-,*,/operators are defined as in IEEE 754-2008. (2) Comparing numbers are defined as in IEEE 754-2008. (3) Constants are correctly rounded. (4) The%operator has its own definition, different thanremainderin IEEE 754-2008. (5) Functions insideMathare implementation defined, with a recommendation that you should use fdlibm (www.netlib.org/fdlibm).(1)-(4) are well defined, reasonable, etc.
But (5) does not make sense, leaving all the functions inside of
Mathimplementation defined with a recommendation is a bit weird. There should be some limit on how wrong a result can be (should sin(x) -> 12.0 for almost allx) be allowed?
Most (all?) implementations of ES5 provide reasonable implementations of the Math object, it to some extent is a non-issue, but specififying the requirements would mean that you could be sure that all ES6 conforming implementations provide accurate results.
As I see it, there are three reasonable levels of specification,
(I) Follow IEEE 754-2008 and provide correctly rounded functions. (II) Follow fdlibm (as current recommendation) and provide functions that give at most 1ulp worth of error. (III) Follow OpenCL (Table 7.2, page 319 in the OpenCL 1.2 specification) and provide more generous limits for the maximum errors. (All current ES5 implementations could probably pass the OpenCL 1.2 limitations, unless they have some bugs that I am unaware of)
(I) would be significantly slower and more difficult to implement than (II) or (III). (II) and (III) are essentially the same in speed and usability, but (II) has stricter requirements.
Or is there any good reason why the Math object is implementation defined?
// Jens Nockert