3

JavaScript represents numbers as IEEE 754 doubles, which are deterministic. Nether less, I've seen arguments that some compiler optimizations can change the order of floating point operations, bringing non-determinism across different runs. So, the question is: using no other source of non-determinism (Math.random, etc.), will a Number -> Number JavaScript function always produce the same result independent of platform and engine?

MaiaVictor
  • 51,090
  • 44
  • 144
  • 286
  • 1
    "Yes." JavaScript is specified to have IEEE 754-Double semantics for numbers, and it has a well-defined ordering of all math operations (from a language semantic viewpoint) where all intermediate values must be materialized at precision. If there is a platform/engine where is does not hold it is not conforming to the ECMAScript specification. – user2864740 Jun 01 '16 at 01:41
  • 1
    @user2864740: The specification presumably doesn't require that `Math.log`, `Math.sin`, `Math.cos`, etc. be correctly rounded? Any code using those is likely to fail to give identical results across platforms. – Mark Dickinson Jun 01 '16 at 13:17
  • @MarkDickinson could you elaborate and source your point in an answer? – MaiaVictor Jun 01 '16 at 15:10
  • @Viclib: I don't know enough about ECMAScript to give an authoritative answer, I'm afraid. But in the most recent version of the standard (6th edition), there's a note in section 20.2.2 that starts "The behaviour of the functions acos, acosh, asin, asinh, atan, atanh, atan2, cbrt, cos, cosh, exp, expm1, hypot, log,log1p, log2, log10, pow, random, sin, sinh, sqrt, tan, and tanh is not precisely specified here ...". Which isn't really surprising: efficient and guaranteed correct rounding for transcendental functions is a hard problem to solve, and it would be unreasonable to require it. – Mark Dickinson Jun 01 '16 at 15:41

2 Answers2

4

some compiler optimizations can change the order of floating point operations, bringing non-determinism across different runs

The ECMAScript specification does not discuss such optimizations. In general it is however expected (like it's explicitly noted for some TypedArray algorithms) that "optimization must not introduce any observable changes in the specified behaviour of the algorithm." And evaluation order for operators is quite strictly specified in ECMAScript.

So unless proven wrong by an implementation that does such stuff (and whose standard-compliance would yet need to be determined), we can assume that the answer is Yes.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
1

Taking a guess you are referring to language-specific non-determinisms, rather than anything IEEE-754 specific.

Many other languages, such as C have undefined or implementation-specific behavior which allows the compiler to emit very tight code for that processor, but at the cost of a good number of gotchas.

For instance, in the C language this expression:

(a++) + (++a)

can be evaluated in two different orders and you can get two valid answers.

EcmaScript 3 (and 5) however, specify the order of operations for expressions so any JavaScript platform should do things in exactly the same way.

There is a longer discussion here:

Javascript evaluation order for operators

Community
  • 1
  • 1
Jeremy J Starcher
  • 23,369
  • 6
  • 54
  • 74