Use `copy` instead of `similar` to respect sparsity structure?

[gdalle]

In these two spots, I use similar to preallocate a structured Jacobian / Hessian.

https://github.com/gdalle/DifferentiationInterface.jl/blob/88c48c1a66709bd1af84a378de06091092fbafd5/DifferentiationInterface/ext/DifferentiationInterfaceSparseMatrixColoringsExt/jacobian.jl#L176

https://github.com/gdalle/DifferentiationInterface.jl/blob/88c48c1a66709bd1af84a378de06091092fbafd5/DifferentiationInterface/ext/DifferentiationInterfaceSparseMatrixColoringsExt/hessian.jl#L125

Pros:

• No need to fill the values
• Allows specifying the eltype
• Guarantees that we get a mutable object

Cons:

• As discussed with @ChrisRackauckas and @avik-pal, this means that some wrappers get lost

I think it's still worth using similar because of the mutability argument. If the semantics of similar are broken for e.g. banded matrices, that's where they should be fixed.

---

Related:

• New Jacobian cache causes copy bug SciML/NonlinearSolve.jl#473
• fix: don't use similar on prototype SciML/NonlinearSolve.jl#474

[ChrisRackauckas]

copy cannot change the eltype, but you can do one(eltype(x)) .* sparsity_pattern(prep) to effectively generate a copy.

[gdalle]

It's kinda meh performance-wise though:

julia> using BenchmarkTools

julia> A = ones(Bool, 100, 100);

julia> f(A) = similar(A, Float64)
f (generic function with 1 method)

julia> g(A) = 1.0 .* A
g (generic function with 1 method)

julia> @btime f($A);
  342.742 ns (2 allocations: 78.17 KiB)

julia> @btime g($A);
  13.408 μs (2 allocations: 78.17 KiB)

[gdalle]

Closing this because it's not worth the performance hit. Better get the guilty packages to fix their similar dispatches