More problems regarding round

[SouthEndMusic]

I did a quick test with the current main and I still have a problem with the function round where I want the return type to be an integer (and thus not depend smoothly on the input). f(x) = Int(round(x)) doesn't work:

MethodError: no method matching Int64(::SparseConnectivityTracer.Dual{Float64, SparseConnectivityTracer.GradientTracer{…}})

Is that something you plan to support? Or should I resolve this in a different way? Still in the context of DataInterpolations by the way.

[SouthEndMusic]

This is the same problem as mentioned in #152 (comment)

[adrhill]

I'll take a look! Could you check whether round(Int, x) works?

[adrhill]

The problem in #152 is now part of our test suite, so I'd be surprised if it doesn't work:

SparseConnectivityTracer.jl/test/test_gradient.jl

Lines 222 to 223 in 199899d

	@test J(x -> round(Int, x), 1.1) ≈ [0;;]
	@test J(x -> round(Bool, x), 1.1) ≈ [0;;]

[adrhill]

If you want an explicit conversation for some reason, convert(Int, round(x)) should work as well.

EDIT: Should work with TracerLocalSparsityDetector after #166 is merged, sorry about that!

[SouthEndMusic]

Thanks. I'm running the unreleased master of DataInterpolations In which there are changes to the relevant code.

[SouthEndMusic]

The problem seems to be that SparseConnectivityTracer.Dual{Int} <: Integer doesn't hold, but that's probably by design

[SouthEndMusic]

Why is the instance of SparseConnectivityTracer.Dual{Int} created in the first place? Doesn't that indicate no connectivity anyway? Can't it just be an Int?

[adrhill]

The problem seems to be that SparseConnectivityTracer.Dual{Int} <: Integer doesn't hold, but that's probably by design

If this was possible, it would indeed simplify things a lot. Unfortunately, Julia's type system doesn't allow it.
Dual numbers are Reals and a thin wrapper around a primal number (in your case an Int) and a tracer which does the bookkeeping for the sparsity pattern:

SparseConnectivityTracer.jl/src/tracers.jl

Lines 103 to 105 in 199899d

	struct Dual{P<:Real,T<:AbstractTracer} <: Real
	primal::P
	tracer::T

Why is the instance of SparseConnectivityTracer.Dual{Int} created in the first place? Doesn't that indicate no connectivity anyway? Can't it just be an Int?

In this specific instance, we could (and I guess should?) indeed return an Int, since round gets rid of all first- and second-order derivative information.
EDIT: opened #167 to track.

More generally speaking, for things like Int(mydual) or convert(Int, mydual), we are forced to return a Dual instead of an Int. This isn't optimal, since returning unexpected types leads to method invalidations and therefore increased compile times. But if we didn't do this, these type conversions would strip all derivative information by essentially removing the tracer part of the Dual.

This is somewhat of a design dilemma for us: do we (a) make the code work on most user-provided functions at the cost of invalidating some code or do we (b) throw a lot of errors and require users to rewrite their code such that it is compatible with SCT? For now, we aim for (a).
Out of curiosity, I took a look at ForwardDiff's approach to Int(x). It is more conservative and throws an InexactError if its derivative information is nonzero. Only if it is zero, it returns the primal value as an Int:

julia> using ForwardDiff

julia> ForwardDiff.derivative(x -> convert(Int, x), 1)
ERROR: InexactError: Int(Int64, Dual{ForwardDiff.Tag{var"#3#4", Int64}}(1,1))
Stacktrace:
 [1] Int64
   @ ~/.julia/packages/ForwardDiff/PcZ48/src/dual.jl:364 [inlined]
 [2] convert
   @ ./number.jl:7 [inlined]
 [3] #3
   @ ./REPL[3]:1 [inlined]
 [4] derivative(f::var"#3#4", x::Int64)
   @ ForwardDiff ~/.julia/packages/ForwardDiff/PcZ48/src/derivative.jl:14
 [5] top-level scope
   @ REPL[3]:1

Whether we stick with approach (a) and the invalidations or whether we move to approach (b) is something we should revisit before we tag a v1.0.0 release. CC @gdalle.

[gdalle]

More generally speaking, for things like Int(mydual) or convert(Int, mydual), we are forced to return a Dual instead of an Int. This isn't optimal, since returning unexpected types leads to method invalidations and therefore increased compile times. But if we didn't do this, these type conversions would strip all derivative information by essentially removing the tracer part of the Dual.

That's not true for Int, as discussed in #167, because Int conversion obliterates derivatives. However it is true e.g. for convert(Float64, mydual).

[adrhill]

Let's discuss this in #167!

[adrhill]

To come back to the initial issue @SouthEndMusic:
I'll add a conservative Int(x::Dual) overload à la ForwardDiff and return an Int iff the tracer is empty.

[gdalle]

Wait why? We can return an int in every case. And what you suggest sounds type unstable.

[adrhill]

Once again, let's discuss this in #167, it deserves its own issue outside of one on round.

ForwardDiff's approach I linked above is not type unstable: an InexactError is thrown when the derivative information would be lost.