Hacker News Reader

Comment by benjaminjackman | Hacker News Reader

As for your point wrt to options in Scala, there were some libraries that used marker values for none (e.g. NaN for double) that then used value classes to basically provide a zero alloc option type. I’ve done my own internal versions for similar purposes. They work well with the caveats of value classes in Scala having their own set of issues.

View on HN

For doubles you don't even need to take over NaN. There is a huge range of unused bit patterns in IEEE floats that could be used instead.

I don't think the JVM guarantees the bit pattern will be preserved when passing it around. I know this is the case for NaNs where I have experienced the bit pattern change [0].

0 - https://stackoverflow.com/questions/43129365/javas-math-rint...

It would be really depressing if java normalized NaNs, but i wouldn't put it past some author thinking it was a good idea.

It's not that they normalize them per se, it's just that NaN bit patterns are mostly undefined behavior. I think the JVM spec (or JLS, I forget) implies that you can't really rely on the NaN bit patterns being retained. Double.longBitsToDouble mentions that some processors might not return a double in the same bit pattern as passed.

Such as?

Reading up on the format [1] it seems that every value is defined, which includes a ton of possible NaN values [2].

[1] https://en.wikipedia.org/wiki/Double-precision_floating-poin...

[2] If you read the actual IEEE 754 spec, one suggested use for a NaN value is the address of the offending instruction(s); otherwise there is no defined pattern for NaNs in IEEE-754.

> it seems that every value is defined,

> there is no defined pattern for NaNs

I was referring to using a NaN value without a zeroed mantissa.

A NaN is defined as the maximum exponent (all ones) and a non-zero mantissa. By "no defined pattern for NaNs" I meant there was no fixed value for a single NaN.

Reply on news.ycombinator.com