Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add error message for integers that represent reals #201

Open
mzgubic opened this issue Jul 30, 2021 · 2 comments
Open

add error message for integers that represent reals #201

mzgubic opened this issue Jul 30, 2021 · 2 comments

Comments

@mzgubic
Copy link
Member

mzgubic commented Jul 30, 2021

e.g. example by @SomTambe

julia> f(x) = 8x + 10*sin(x)
f (generic function with 1 method)
julia> function ChainRulesCore.rrule(::typeof(f), x)
           y = f(x)
           function ∇f(Δ)
               ∇ = 8 + 10*cos(x)
               @show ∇ Δ
               return ChainRulesCore.NoTangent(), Δ *end
           return y, ∇f
       end
julia> test_rrule(f, 2);
∇ = 3.838531634528576
Δ = 2.31= 3.838531634528576
Δ = 2.31
test_rrule: f on Int64: Test Failed at /home/somvt/.julia/packages/ChainRulesTestUtils/AX7fv/src/testers.jl:278
  Expression: ad_cotangent isa NoTangent
   Evaluated: 8.86700807576101 isa NoTangent
...
Test Summary:          | Pass  Fail  Total
test_rrule: f on Int64 |    4     1      5
ERROR: Some tests did not pass: 4 passed, 1 failed, 0 errored, 0 broken.

the error message is confusing, we could special case it for actual::AbstractFloat, expected::NoTangent as suggested by @oxinabox

@SomTambe
Copy link

thanks for the issue!

@oxinabox
Copy link
Member

oxinabox commented Oct 1, 2021

Similar there are some other cases like AbstractVector{<:Interger} that really represent AbstractVector{<:AbstractFloat}.

We can check the primal type and see if it is one we automatically generated a NoTangent() from and then tell the user that if the are using this type then we can not be sure if they mean to use it as a non-differentiabled quantity like an index (our default assumption) or if they are using it to represent a continuous differentiable quantity.

For the particular case of integers we mike want to suggest rather than but just plain testing on floating point values, since finite differencing is going to end up testing your primal function on floating point values anyway once you perturb it.
Though you might have a AD special case rule. (I don't think anyone really should)
JuliaDiff/FiniteDifferences.jl#188 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants