Compatibility with NaNMath.jl?

[kapple19]

Having written some of my functions with NaNMath.jl versions of mathematical functions, feeding them Intervals results in a StackOverflowError.

E.g.

julia> ntv = interval(0, 1)
[0.0, 1.0]_com

julia> NaNMath.sin(ntv)
ERROR: StackOverflowError:
Stacktrace:
  [1] bareinterval(x::Interval{Float64})
    @ IntervalArithmetic C:\Users\Aaron\.julia\packages\IntervalArithmetic\7FL3g\src\intervals\construction.jl:298
  [2] float
    @ C:\Users\Aaron\.julia\packages\IntervalArithmetic\7FL3g\src\intervals\real_interface.jl:27 [inlined]   
  [3] sin(x::Interval{Float64}) (repeats 43500 times)
    @ NaNMath C:\Users\Aaron\.julia\packages\NaNMath\ceWIc\src\NaNMath.jl:11
  [4] eval
    @ .\boot.jl:385 [inlined]
  [5] eval
    @ .\Base.jl:88 [inlined]
  [6] repleval(m::Module, code::Expr, ::String)
    @ VSCodeServer c:\Users\Aaron\.vscode\extensions\julialang.language-julia-1.66.2\scripts\packages\VSCodeServer\src\repl.jl:229
  [7] (::VSCodeServer.var"#110#112"{Module, Expr, REPL.LineEditREPL, REPL.LineEdit.Prompt})()
    @ VSCodeServer c:\Users\Aaron\.vscode\extensions\julialang.language-julia-1.66.2\scripts\packages\VSCodeServer\src\repl.jl:192
  [8] with_logstate(f::Function, logstate::Any)
    @ Base.CoreLogging .\logging.jl:515
  [9] with_logger
    @ .\logging.jl:627 [inlined]
 [10] (::VSCodeServer.var"#109#111"{Module, Expr, REPL.LineEditREPL, REPL.LineEdit.Prompt})()
    @ VSCodeServer c:\Users\Aaron\.vscode\extensions\julialang.language-julia-1.66.2\scripts\packages\VSCodeServer\src\repl.jl:193
 [11] #invokelatest#2
    @ Base .\essentials.jl:887 [inlined]
 [12] invokelatest(::Any)
    @ Base .\essentials.jl:884
 [13] (::VSCodeServer.var"#62#63")()
    @ VSCodeServer c:\Users\Aaron\.vscode\extensions\julialang.language-julia-1.66.2\scripts\packages\VSCodeServer\src\eval.jl:34

Any possibility of future compatibility?

Not sure if this is an issue to raise in NaNMath.jl or here.

My first guess would be to overload NaNMath functions with Interval arguments as a package extension? Maybe such an overload would call the regular Julia functions back.

[Kolaru]

There are two things here

• NaNMath assumes that a Real converted with float becomes either a Float64 or a Float32. That is not currently the case for Intervals and causes the stack overflow.
• NaNMath doesn't use functions from Base internally, so it currently can not reuse anything we have defined here for intervals. I don't know why it is so, but as long as it is, making them compatible would indeed require a package extension.

[kapple19]

I'm imagining an Interval Arithmetic extension that loops through all the NaNMath.jl functions, giving them methods that fallback to Base (or other, e.g. SpecialFunctions.jl) on Interval inputs?

I'm happy to look into this in more detail soon.

I'm also thinking of applying this to Symbolics.jl for Num inputs.

[lbenet]

I'm imagining an Interval Arithmetic extension that loops through all the NaNMath.jl functions, giving them methods that fallback to Base (or other, e.g. SpecialFunctions.jl) on Interval inputs?

I'm happy to look into this in more detail soon.

I'm also thinking of applying this to Symbolics.jl for Num inputs.

That would be a nice addition; I like the proposal of having it as an extension.

[kapple19]

I've added fallbacks for NaNMath.jl functions that have equivalents in Base.
But only for Interval inputs.
Will next start looking at more specific input types, e.g. Complex{<:Interval}.

Are you guys fine with adding NaNMath.jl to the test environment? Or is there an alternative test procedure you prefer?

[OlivierHnt]

Yes if we do end up supporting NaNMath.jl as an extension, we would want to have some tests as well.
You could imitate how this was done for ForwardDiff.jl.

[kapple19]

So apparently there's already some headway on falling back NaNMath functions to Base.
JuliaMath/NaNMath.jl#66
This would enable not just IntervalArithmetic but also Symbolics and other people's custom Number/Real/AbstractFloat types to work with NaNMath.
Shall I close this then?

It's not completed in NaNMath so I might divert my energies there for this feature.

[OlivierHnt]

If there is a more general solution which does not require an explicit package extension, then yes that sounds pretty great!

Feel free to close this issue of course; in any case, you can re-open it at any time 🙂