IntervalArithmetic.jl
IntervalArithmetic.jl copied to clipboard
JuliaIntervals
Empty interval as [NaN, NaN]?
Is there anything to stop us using Interval(NaN, NaN) as the representation of the empty interval? I think this would remove the need for a lot of isempty checks, and hence may improve performance (although this would need to be checked).
As far as I can see, the standard mandates what inf and sup should return, but not the internal representation of the empty set.
Indeed in section 14.2, one possible representation is given as [NaN, NaN].
It is indeed worth trying it. I am not so sure if we can avoid checking if an interval is empty or not, though. Maybe we should inline isempty and stick to using it.
Julia should inline it automatically.
My idea is that e.g. for defining + of two intervals,
Interval(x.lo + y.lo, x.hi + y.hi)
should then work correctly even for empty intervals, without the explicit empty check.
Unfortunately not:
julia> add(x, y) = Interval(x.lo + y.lo, x.hi + y.hi)
add (generic function with 1 method)
julia> add(emptyinterval(Float64), entireinterval(Float64))
[NaN, NaN]
Yes it works for most intervals, but not for the example I posted, so you would still need the check.
Using NaNs should work for all cases, since the NaN "poisons" the calculation.
Yes I intend to -- I just wanted to see if there was a reason that I was missing why this is a priori a bad idea.
I think we used [NaN, NaN] at some point and then changed it!
I think it would be mostly fine, but this calls for some caution about how to access bounds, since x.lo and inf(x) would not be strictly equivalent anymore.
This is interesting; it does help performance a bit. One issue is that Rational is (on master) a supported bound type for Interval, yet there is no NaN equivalent for Rational (see also issue #462).
So implementing this would mean having two distinct implementations for Rational and AbstractFloat bound types. Perhaps this is worth the extra work.
