Explicitly define an Inf64 and NaN64

[dphildebrandt]

Currently we have 32-bit version of Inf and NaN (Inf32 and NaN32) but regular Inf and NaN are assumed 64-bit. This fix creates an explicit NaN64 and Inf64 with NaN and Inf being set to the appropriate type, in the style of Int etc.

[jiahao]

There is no such thing as a "native" bit depth affinity for floating point like there are for integers.

[tkelman]

Int === typeof(1), whereas floating-point literals are always Float64 regardless of architecture. There are past (closed, most likely) issues for a Float typealias. There's no reason to do this only for Inf and NaN.

[dphildebrandt]

Then why are Inf16, Inf32, NaN16 and NaN32 defined at all? It seems inconsistent. I was thinking either also introduce the Inf64/NaN64 definition as well or remove the others? Or define Inf64/NaN64 but always have Inf set to it; ie. remove the if-statement is check in this commit.

[tkelman]

Introducing Inf64 and NaN64 sounds reasonable to me for consistency's sake. Others should chime in.

[StefanKarpinski]

Yes, it seems reasonable to me too. In particular, it would be pathological for those names to mean anything else, so why not have them? They should also be exported here.

[ScottPJones]

Is there anything to show the quiet or signaling bit, sign bit, and payload of a NaN?
Also, if you are going to have these, you may also need Inf, -Inf NaN etc. for decimal floating point,
possibly defined for different sizes (important for NaN, where the payload size is different).
Also, I don't understand why Inf16, Inf32, and now Inf64 are defined... I would have thought that those should be identical, across all sizes of Float. NaN16, etc. does make sense to me...

[ScottPJones]

Does Inf16 not === Inf?

[StefanKarpinski]

That seems like a fairly easy question to get an answer to...

[StefanKarpinski]

Can you squash this into one commit?

[ScottPJones]

I keep forgetting, tone is lost on the Internet! I really meant, "shouldn't they be identical?"
Anyway, I've seen that Float16(0) also is not viewed as identical to 0.0, so I guess it's consistent.

[tkelman]

lgtm, should merge as long as travis is green. AppVeyor has a backlog in the queue, and is likely to fail right now anyway due to #11818, so not 100% necessary to wait for it here.

[StefanKarpinski]

Two values are === if and only if you can cannot write a program that distinguishes them:

julia> typeof(Inf)
Float64

julia> typeof(Inf16)
Float16

[ScottPJones]

OK... another fun thing: why does julia give different bitpatterns than C/C++ for NaNs?
In C/C++, I get:
f = 7ff8000000000000, g = 7ff8000000000000
for both -0.0/0.0 and 0.0/0.0.
In Julia, I get a negative NaN for both: 0xfff8000000000000

[StefanKarpinski]

Not sure what C/C++ is doing, but we're just calling the divsd instruction.