nextfloat behaviour near Inf

[DNF2]

I find this behaviour surprising:

>> nextfloat(Inf)
Inf
>> nextfloat(Inf, 2)
Inf
>> nextfloat(prevfloat(Inf))
Inf
>> nextfloat(prevfloat(Inf), 2)
NaN

I would expect the last call to return Inf as well.

The following code seems to do what I expected:

function nextfloat(x::Float64, i::Integer)
    if i == 0 || (isinf(x) && sign(x) == sign(i))
        return x
    end
    xint = float_lex_order(reinterpret(Int64,x), i)
    intmax = reinterpret(Int64, Inf64)
    int0 = reinterpret(Int64, -0.0)
    intmin = reinterpret(Int64, -Inf64)
    return (0 <= xint <= intmax || int0 <= xint <= intmin) ?
        reinterpret(Float64, xint) : flipsign(Inf, x)
end

[simonbyrne]

This is clearly an error. Even more worrying is:

julia> nextfloat(prevfloat(Inf),typemax(Int))
-2.2250738585072024e-308

[cyberbryce]

The manual states that nextfloat and prevfloat use lexicographic order, but to me this meant that NaN's would either be ordered by their bits, or not ordered at all. The previous routine appears to give you the next 'higher' NaN in the sense of bits. The proposed routine instead follows the second branch of the final conditional and returns a signed infinity:
Previous behavior:

julia> bits(NaN)
"0111111111111000000000000000000000000000000000000000000000000000"
julia> nextfloat(NaN,1)
NaN
julia> nextfloat(NaN,1)===NaN
false
julia> bits(nextfloat(NaN,1))
"0111111111111000000000000000000000000000000000000000000000000001"

Proposed behavior:

julia> nextfloat(NaN,1)
Inf
julia> bits(nextfloat(NaN,1))
"0111111111110000000000000000000000000000000000000000000000000000"

[cyberbryce]

Apologies -- Contrary to what I said, Simonbyrne's actual commit (rather than the proposed code above) treats all NaNs the same.

[simonbyrne]

Seems like the manual isn't quite right, since

julia> nextfloat(-0.0)
5.0e-324

julia> lexless(-0.0, 0.0)
true

nextfloat and prevfloat are supposed to correspond to the nextUp and nextDown functions in the IEEE754-2008 spec, which states:

sourceFormat nextUp(source)
sourceFormat nextDown(source)
nextUp(x) is the least floating-point number in the format of x that compares greater than x. If x is the negative number of least magnitude in x’s format, nextUp(x) is −0. nextUp(±0) is the positive number of least magnitude in x’s format. nextUp(+∞) is +∞, and nextUp(−∞) is the finite negative number largest in magnitude. When x is NaN, then the result is according to 6.2. nextUp(x) is quiet except for sNaNs.
The preferred exponent is the least possible.
nextDown(x) is −nextUp(−x).

I'm not really sure which part of 6.2 they're referring to, but there is there is this sentence:

6.2.3 NaN propagation
An operation that propagates a NaN operand to its result and has a single NaN as an input should produce a NaN with the payload of the input NaN if representable in the destination format.

which would seem to indicate that for NaNs we should return the same payload.

[cyberbryce]

That makes sense. Thanks for fixing this. FYI: I found that when I static typed the arguments, the new routine introduces about six additional branches, which we might want to worry about. However, nonetheless, it is slightly more performant than the previous version.

[simonbyrne]

Thanks, that's good to know. Some of the additional branches are to correctly handle things like BigInts, but I intentionally wrote the code so that the JIT should be able to remove them in other cases. Please do let me know if you have other suggestions.

[nalimilan]

By the way, the two-argument form of nextfloat isn't documented.