Switching on float/double/long

[Brian Goetz]

A target of opportunity for the new switch JEP is to fill out the set of 
types that traditional switches can operate on -- specifically float, 
double, and long.  The reason that we don't support these now is mostly 
an accident of history; the `tableswitch` and `lookupswitch` opcodes are 
int-based, so the compiler doesn't have a convenient target for 
translating these. As you've seen from the recent notes on switch 
translation, we're working towards using indy more broadly as a 
translation target for most switch constructs.  This makes it far easier 
to bust the limitations on switch argument types, and so this has been 
listed as a target of opportunity in the JEP (for both statement and 
expression switches.)

Our resident floating-point expert, Joe Darcy, offers the following 
additional thoughts on the subject:

-- Begin forwarded message

Per a recent request from Brian, I've written a few thoughts about 
switching on floating-point values.

To address some common misunderstandings of floating-point, while it is 
often recommended to *not* compare floating-point values for equality, 
it is perfectly well-defined to do such comparisons, it just might not 
do what you want

For example, instead of

     // Infinite loop since sum stored in d never exactly equals 1.0, doh!
     while(d != 1.0)

         d += 0.1;

use either

     // Counted loop
     for(int i = 0; i < 10; i++)

         d += 0.1;

or

     // Stop when numerical threshold is met
     while(d <= 1.0)

         d += 0.1;

depending on the semantics the loop is trying to capture.

I've attached a slide from my JVMLS talk this year to help illustrate 
the semantic modeling going in in IEEE 754 floating-point. Each of the 
2^32 possible bit patterns of a float is some floating-point value, 
likewise for the 2^64 possible bit patterns of a double. However, from a 
Java language or JVM perspective, there are not 2^32 or 2^64 distinct 
values we need or want to distinguish in most cases. In particular, we 
almost always want to treat all bit patterns which encode a NaN as a 
single conceptual NaN. Another wrinkle concerns zero: IEEE 754 has both 
a positive zero and a negative zero. Why are there *two* zeros? Because 
there are two infinities.  The signed infinities and distinguished by 
divide (1.0/0.0 => +infinity, 1.0/-0.0 => -infinity) and by various 
library functions.

So we want to:

     * Allow every distinct finite nonzero floating-point value to be  
the case of a switch.
     * Allow -0.0 and +0.0 to be treated separately.
     * Allow -infinity and +infinity to be treated separately.
     * Collapse all NaN representation as a single value.

For the "Rounding" mapping in the diagram which goes from the extended 
real numbers to floating-point data, there is a nonempty segment of the 
real number line which maps to a given representable floating-point 
number. For example, besides the string "1.0" mapping exactly to the 
reprentable floating-point value 1.0, there is a region slightly small 
than 1 (0.99999999999999999999...) which will round up to 1.0 and a 
region slightly larger than 1 (1.000000000000000001...) which will round 
down to 1 from decimal -> binary conversion. This would need to be 
factored into any distinctiveness requirements for the different arms of 
the switch. In other words

     case 1.000000000000000001:
     ....
     case 0.99999999999999999999
     ...

would need to be rejected just as

     case 0:
     ....
     case 00:

is rejected.

In terms of JDK 9 structures and operations, the following 
transformation of a float switch has what I think are reasonable semantics:

     Replace each float case label y in the source with an int label 
resulting from floatToIntBits(y). Note that floatToIntBits is used for 
the mapping rather than floatToRawIntBits since we want NaNs to be 
grouped together.

     Instead of switching on float value x, switch on floatToIntBits(x).

HTH,

-Joe