What aspect of portable floating point did Java back down on?

Question

Java was released under the slogan 'write once, run anywhere'; while its adoption was probably more about 'now we have a language that provides garbage collection in a familiar workflow and with a good standard library', as far as Sun's management was concerned, it was an anti-Microsoft weapon, and to this end, it tried to pave over differences between platforms.

One category of differences was in floating-point arithmetic. IEEE 754 made some progress towards reproducible floating point, but still left a great deal of variation. Java tried to nail it down. This was a controversial move. William Kahan wrote an impassioned rant about it; as it happens, I mostly agree with the Java designers and mostly disagree with Kahan, but his writing is always thought-provoking.

Now I vaguely remember the Java decision mostly held up, and to this day floating point in Java is mostly reproducible, but there was one issue, one small aspect of floating-point arithmetic, on which they backed down, one edge case in which platform differences in floating-point hardware can still manifest. But I cannot for the life of me remember what that was.

What was the aspect of floating point on which a later version of Java backed down?

Answer 1

The range of intermediate results.

The Java Language Specification, 2nd Ed. relaxed the evaluation rules for floating-point expressions by introducing the notion of an ‘FP-strict’ expression, defined as follows (§15.4, p. 319):

Within an FP-strict expression, all intermediate values must be elements of the float value set or the double value set, implying that the results of all FP-strict expressions must be those predicted by IEEE 754 arithmetic on operands represented using single and double formats. Within an expression that is not FP-strict, some leeway is granted for an implementation to use an extended exponent range to represent intermediate results; the net effect, roughly speaking, is that a calculation might produce “the correct answer” in situations where exclusive use of the float value set or double value set might result in overflow or underflow.

The actual semantics are detailed in §5.1.8 ‘Value Set Conversion’; the two sections are then referred to in other sections that specify what the specification considers ‘intermediate’ floating-point results (which is basically boils down to all arithmetic operations, but not variable assignment or argument passing).

The FP-strict mode can be enabled by the strictfp keyword, which may be applied to classes (JLS 2nd Ed., §8.1.1.3), methods (§8.4.3.5) and interfaces (§9.1.1.2).

This definition has remained unchanged in the specification as late as in Java 15 (JLS 15, §15.4 and §5.1.13 respectively). In the first edition, no such ‘strictness’ notion is present and thus all floating-point expressions are implicitly strict.

This is basically the same issue that the C language has (see GCC’s infamous bug 323 and the ‘Disappointments’ section of the GCC manual); though in Java’s case, the effects of this are considerably less wild as the specification only allows the JVM implementation to extend the exponent range and mandates that values be rounded strictly to their nominal type at variable assignment (JLS 2nd Ed. §5.2) and argument passing (§5.3).

The other answers (@gnasher729’s and @supercat’s) go into more detail as to the motivation; the latter also made me realise I have misread the specification slightly.

Answer 2

From what I understand, unless things have changed, I think that even in non-strict mode, Java required that floating-point values be rounded to the appropriate length in the mantissa. Leeway was allowed, however, with values that were smaller the smallest normalized float value. Most float values should have 24 bits of precision, but values whose magnitude is between 0.5 and 1.0 times the smallest normalized value should have 23 bits, those whose magnitude is between 0.25 and 0.5 times the smallest normalized value should have 22 bits, etc. Many hardware platforms had ways of quickly rounding a mantissa to 24 bits, but couldn't efficiently force the magnitude-dependent rounding except by actually storing a value to memory as a float and then reading it back.

A lot of the controversy surrounding such issues could be avoided if languages were to provide different floating-point types which had matching representations but different semantics, and a way of specifying which particular type should be represented by keywords like float or double. If general-purpose implementations are expected to provide modes to explicitly select the language-default behaviors, as well as modes which use whichever behaviors are most efficient, then someone who wishes to write code which works efficiently but correctly on a wide range of platforms could test their code using both the mode that would run more efficiently on their platform, and a mode that would run much less efficiently on their platform but would mimic the behavior of other platforms. Unfortunately, the normal tendency has been to try to push for all implementations to process everything the same way, despite the fact that different behaviors will be more useful for different platforms and purposes.

Answer 3

The biggest problem was that on Intel CPUs with external floating point unit (80387 IIRC) all operations were done in extended precision, while Java required double precision. And due to “double rounding”, you can’t use an extended precision operation and round to double precision, in rare situations this would change the result.

So this would have been a total performance disaster. But fortunately that FPU can be set into a “64 bit rounding” mode, where all results have their mantissa rounded to double precision. There was a problem left that wasn’t quite as bad: Even with 64 bit rounding, the exponent range was the full extended precision range. So calculating (a * b) / c should produce an infinity if a, b and c are very large, but gave the correct result instead. Workarounds would have been expensive.

As a result, Java allowed operations to have temporary results calculated at higher than double precision. This still required rounding when a result was assigned to a variable, but that was just about bearable. The problem is gone with SSE floating point.