Open tpapp opened 7 years ago
Thanks for bringing this up!
I isolated the problem and would be willing to make a PR, but I am unsure what an elegant fix would be.
The most elegant fix, IMO, would be to implement Base.prevfloat(n::Dual) = prevfloat(value(n))
and open a PR in Base to change the type restriction here to Real
. I haven't tried it yet, but I believe it should work after that.
Otherwise, ForwardDiff (or Base) could implement a generic normalize
which does the naive thing (x ./ norm(x)
), but then Dual
numbers wouldn't get the benefit of Base's special implementation that tries to avoid overflow/underflow for floating point numbers.
On a related note, I don't understand why Dual does not restrict T to AbstractFloat (I see little practical utility for AD using other types), but I am new to AD so perhaps I need to study the library more.
One example is composing interval types with AD, which are also (I believe) usually subtyped to Real
.
example:
fails with
I isolated the problem and would be willing to make a PR, but I am unsure what an elegant fix would be. Possibly a method
__normalize!{N, T <: AbstractFloat}(v::AbstractVector, nrm::ForwardDiff.Dual{N,T})
that does the same thing, branching on the size ofnrm
, but usingtypemax(T)
instead here?On a related note, I don't understand why
Dual
does not restrictT
toAbstractFloat
(I see little practical utility for AD using other types), but I am new to AD so perhaps I need to study the library more.