Use copy instead of similar to respect sparsity structure?

[gdalle]

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

DifferentiationInterface.jl/DifferentiationInterface/ext/DifferentiationInterfaceSparseMatrixColoringsExt/jacobian.jl

Line 176 in 88c48c1

jac = similar(sparsity_pattern(prep), eltype(x))

DifferentiationInterface.jl/DifferentiationInterface/ext/DifferentiationInterfaceSparseMatrixColoringsExt/hessian.jl

Line 125 in 88c48c1

hess = similar(sparsity_pattern(prep), eltype(x))

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