IntervalArithmetic.jl
IntervalArithmetic.jl copied to clipboard
JuliaIntervals
Don't export ∞
InfiniteArrays.jl has ∞ as a special type, which conflicts with the exporting of ∞ from this package. I think the best solution is to not export ∞ from here, as there already exists Inf and the definition is not directly related to interval arithmetic.
Thanks for the report. That's a good point.
I guess we should unexport then. Is there a simple way of importing it again? I guess we could just make a submodule called IntervalArithmetic.SpecialSymbols or similar.
Isn't there also a clash of .. with one of your packages? It also clashes with IntervalSets, which is used e.g. in Makie. I'm not sure what the general solution for such situations is.
I use IntervalSets.jl, so yes that would also be good to coordinate. I don't know a good solution other than type piracy, which maybe is OK.
I think a solution to this is to make a submodule IntervalArithmetic.Symbols or IntervalArithmetic.Special (or whatever) that exports ∞ and .., and not export them by default, even though that will be a pain.
Any thoughts @lbenet ?
I think that ∞ can be moved to a submodule of symbols for IntervalArithmetic.jl.
A true solution to that would be to have a common ∞ that is more special that Inf currently is, such that it means different things depending on the context. In particular it should be usable as an index for InfiniteArrays.jl and be considered a Float in IntervalArithmetic.jl (I don't know if there are other use cases). However I'm not sure about the feasibility of this.
IntervalSets.jl and IntervalArithmetic.jl seem to be mutually exclusive, so users should probably use explicit import statement rather than using. A possibility to still have it is to allow setting ENV["IA_EXPORT_SYMBOLS"] to false before building the package and not exporting additional symbols like ∞ or .. in that case.
I think we can simply have ∞ unexported; speaking for myself, this is a symbol I don't use too often.
However, we should have .. at disposition, because it is incredibly handy; same for ±. So at the moment, I wouldn't do anything on them. As @dlfivefifty says, and is encouraged here, for the time being we could live with some type piracy.
IntervalSets.jl README is actually suggesting that a..b still return an IntervalSets.ClosedInterval, and that IntervalArithmetic.jl does type piracy by overloading +, -, sin, etc.
