nan(Dual{T}) has type T

[oxinabox]

 nan(Dual{Float32})
 > NaN32

But a Dual NaN does exist, kinda:

convert(Dual{Float32},NaN)
>NaN32 + 0.0f0du

The definition of nan(f)

Base.nan(f)

Returns NaN (not-a-number) of the floating point type "f" or of the same floating point type as "f"

There are two options for what could be done.

Either nan{Dual{T}} should a NaN in the real part and zero in the du part -- it makes sense to match the behavior of convert, and for the nan operator to apply to the real part.

Or it should do as nan(Complex{Float32}) does and throw an error:

`nan` has no method matching nan(::Type{Complex{Float32}}) while loading In[1], in expression starting on line 1

My code assumes that nan{T<:Number} gives me a NaN of type T. Or at very least makes it clear that it can't be done.

[mlubin]

How are you using nan in your code?

[oxinabox]

I'm not sure that this will help you, but I use it when creating a lightweight version of one of my composite types. (to save on network transmission, in my parallel code). I want to set one of the fields to NaN so that if it is ever accesses (which on the lightweight version it shouldn't be), it becomes immediately apparent. I further have a version of the lightweight type that support converting, as part of me using it with ForwardDiff.jl

Yes there are other ways to do it, eg Nullable, which may be better. But because I was using NaN as a quick hack, I came across the aforementioned unexpected behavior.

EDIT: I've removed the code I posted cos that code is full of bugs and typos (clearly I need to sleep). Point being it doesn't seem logical that nan(Dual{Float32}) should produce a Float32. If it has to for implementation reasons, then that should be documented (if it isn't already)

[oxinabox]

It was added in commit https://github.com/JuliaDiff/DualNumbers.jl/commit/336b003af020e44e30064e9f1061f1a3b7de1a81 , if that helps you remember why you made it that way. I'm sure you had a good reason at the time.

[mlubin]

Since we overload the comparison operators, I think it's safe to make this change. Will need some testing though.

[tomasaschan]

Now, inf(T) and nan(T) are deprecated in favor of convert(T, Inf) and convert(T, NaN), so I think these should simply be removed (after ample deprecation).

[mlubin]

Resolved by #27