What happens to value_and_gradient!! if the output is not a Float64?

[gdalle]

https://github.com/withbayes/Tapir.jl/blob/f5e2b90cd17fd3127dd0fd8dfa617bc112275626/src/interface.jl#L17-L24

[willtebbutt]

A non-ideal, but fairly decipherable, error. For example:

rule = build_rrule(identity, randn(5))
Tapir.value_and_gradient!!(rule, identity, randn(5))

yields

ERROR: AssertionError: _typeof(tangent(out)) == T
Stacktrace:
 [1] value_and_pullback!!(::Tapir.DerivedRule{…}, ::Float64, ::CoDual{…}, ::CoDual{…})
   @ Tapir ~/ml/ad_playground/Taped.jl/src/interface.jl:11
 [2] value_and_gradient!!(::Tapir.DerivedRule{…}, ::CoDual{…}, ::CoDual{…})
   @ Tapir ~/ml/ad_playground/Taped.jl/src/interface.jl:23
 [3] value_and_gradient!!(::Tapir.DerivedRule{…}, ::Function, ::Vector{…})
   @ Tapir ~/ml/ad_playground/Taped.jl/src/interface.jl:60
 [4] top-level scope
   @ REPL[38]:1
Some type information was truncated. Use `show(err)` to see complete types.

[gdalle]

Wouldn't it be possible to grab the type T of the output, assuming it's a scalar type, and use one(T) as the pullback seed?

[willtebbutt]

Provided you also constrain it to a known collection of "real-valued" types (Float16, Float32, BigFloat, etc), I agree that should work.

I'm not really testing on anything other than Float64 at the minute for the sake of expedience though, which is why I've gone with 1.0. When I widen the range of types that I'm confident we have decent support for, I'll widen the permissible types.

[gdalle]

Sounds good! I was mostly curious

[willtebbutt]

Cool. Please feel free to re-open if there's anything else to chat about on this point :)