Missing `basis` method

[ameligrana]

Tests in this PR (https://github.com/mlange-42/Ark.jl/actions/runs/20252583191/job/58147727078?pr=426) are failing using AutoMooncakeForward backend throwing this error:

Compute gradients through Mooncake.jl: Error During Test at /home/runner/work/Ark.jl/Ark.jl/test/ext/test_mooncake_interop.jl:6
  Got exception outside of a @test
  MethodError: no method matching basis(::Tuple{Float64, Float64})
  
  Closest candidates are:
    basis(::GPUArraysCore.AbstractGPUArray{T}, ::Any) where T
     @ DifferentiationInterfaceGPUArraysCoreExt ~/.julia/packages/DifferentiationInterface/4n6vR/ext/DifferentiationInterfaceGPUArraysCoreExt/DifferentiationInterfaceGPUArraysCoreExt.jl:6
    basis(::AbstractArray)
     @ DifferentiationInterface ~/.julia/packages/DifferentiationInterface/4n6vR/src/utils/basis.jl:23
    basis(::AbstractArray, ::Any)
     @ DifferentiationInterface ~/.julia/packages/DifferentiationInterface/4n6vR/src/utils/basis.jl:16
  
  Stacktrace:
    [1] _prepare_pullback_aux(::Val{true}, ::DifferentiationInterface.PullbackSlow, ::var"#run_world#360", ::AutoMooncakeForward{Nothing}, ::Tuple{Float64, Float64}, ::Tuple{Float64})
      @ DifferentiationInterface ~/.julia/packages/DifferentiationInterface/4n6vR/src/first_order/pullback.jl:291
    [2] prepare_pullback_nokwarg(::Val{true}, ::var"#run_world#360", ::AutoMooncakeForward{Nothing}, ::Tuple{Float64, Float64}, ::Tuple{Float64})
      @ DifferentiationInterface ~/.julia/packages/DifferentiationInterface/4n6vR/src/first_order/pullback.jl:259
    [3] prepare_gradient_nokwarg(::Val{true}, ::var"#run_world#360", ::AutoMooncakeForward{Nothing}, ::Tuple{Float64, Float64})
      @ DifferentiationInterface ~/.julia/packages/DifferentiationInterface/4n6vR/src/first_order/gradient.jl:93
    [4] gradient(::var"#run_world#360", ::AutoMooncakeForward{Nothing}, ::Tuple{Float64, Float64})
      @ DifferentiationInterface ~/.julia/packages/DifferentiationInterface/4n6vR/src/first_order/gradient.jl:62
    [5] macro expansion
      @ ~/work/Ark.jl/Ark.jl/test/ext/test_mooncake_interop.jl:41 [inlined]
    [6] macro expansion
      @ /opt/hostedtoolcache/julia/1.10.10/x64/share/julia/stdlib/v1.10/Test/src/Test.jl:1577 [inlined]
    [7] top-level scope
      @ ~/work/Ark.jl/Ark.jl/test/ext/test_mooncake_interop.jl:7
    [8] include(fname::String)
      @ Base.MainInclude ./client.jl:494
    [9] top-level scope
      @ ~/work/Ark.jl/Ark.jl/test/ext/runtests.jl:5
   [10] include(fname::String)
      @ Base.MainInclude ./client.jl:494
   [11] top-level scope
      @ ~/work/Ark.jl/Ark.jl/test/runtests.jl:45
   [12] include(fname::String)
      @ Base.MainInclude ./client.jl:494
   [13] top-level scope
      @ none:6
   [14] eval
      @ ./boot.jl:385 [inlined]
   [15] exec_options(opts::Base.JLOptions)
      @ Base ./client.jl:296
   [16] _start()
      @ Base ./client.jl:557

seems like the method at https://github.com/JuliaDiff/DifferentiationInterface.jl/blob/main/DifferentiationInterface/src/first_order/pullback.jl#L291 is missing

[ameligrana]

Ah okay actually fixed using [0.1, 0.5] instead of (0.1, 0.5) for the arguments to gradient. Though Mooncake reverse mode worked with the tuple version, maybe worth adding basis method anyway?

[gdalle]

You stumbled upon a deeper phenomenon: while reverse-mode backends can accommodate arbitrary structures when computing gradients, forward-mode backends need to enumerate input dimensions in order to construct the corresponding vector componentwise. That's why ForwardDiff, FiniteDiff and forward Mooncake will error when you pass something that is not an array: enumerating dimensions becomes cumbersome and subjective for arbitrary structs. DI tries to make it clear by saying that only arrays are well-tested. Other types may work, especially with reverse mode, but that is not guaranteed across backends.
In a nutshell, I won't add the basis method for tuples, because if I did, I'd probably have to add it for named tuples too, and then for arbitrarily complex structs, for which I'd also have to define an enumeration mechanism. In your case, if the tuples are conceptually vectors, you're probably better off using StaticArrays.jl?

[ameligrana]

ok thank you for the nice explanation. I can also use normal vector in any case, just didn't realize that this was the problem. In any case, supporting arbitrarily complex structs would be nice because in some cases it would reduces the friction in using the lib since it wouldn't require to produce the mapping from the structs to the arrays and back to the user

[gdalle]

If you need gradients for arbitrary structs, pick any reverse mode backend and it should work :)