Exponentiation yields a MethodError

[wesselb]

∇(x -> 2x)(1) works, whereas ∇(x -> x^2)(1) yields

ERROR: MethodError: ^(::Nabla.Leaf{Int64}, ::Int64) is ambiguous. Candidates:
  ^(x, p::Integer) in Base at intfuncs.jl:196
  ^(721::Nabla.Node{#s5} where #s5<:Real, 722::Real) in Nabla
Possible fix, define
  ^(::Nabla.Node{#s5} where #s5<:Real, ::Integer)
Stacktrace:
 [1] (::##3#4)(::Nabla.Leaf{Int64}) at ./REPL[7]:1
 [2] (::Nabla.##5#7{##3#4,Bool})(::Int64, ::Vararg{Int64,N} where N) at ~/.julia/v0.6/Nabla/src/core.jl:175

[iamed2]

Defining that method should be enough to fix it, long term I think Base should remove that generic method.

[wesselb]

Isn't a sensitivity for ^ already implemented at src/sensitivities/scalar.jl:16?

[iamed2]

Yes, the problem here is a method ambiguity. In the error:

ERROR: MethodError: ^(::Nabla.Leaf{Int64}, ::Int64) is ambiguous. 

Candidates:
  ^(x, p::Integer) in Base at intfuncs.jl:196
  ^(721::Nabla.Node{#s5} where #s5<:Real, 722::Real) in Nabla

These method signatures both match the calling arguments.
Julia normally decides which method to call based on sorting by specificity.
These methods are deemed to be equally specific, so rather than picking one arbitrarily, it gives an error.

Possible fix, define
  ^(::Nabla.Node{#s5} where #s5<:Real, ::Integer)

Defining this method would disambiguate the situation.

However, ^(x, p::Integer) is an overly-general signature and should be removed from Julia IMO.

[iamed2]

Ref: JuliaLang/julia#23332