nan(Dual{T}) has type T

[juliadiff]

nan(Dual{T}) has type T

[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 336b003 , 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