Empty interval as [NaN, NaN]?

[dpsanders]

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).

[dpsanders]

As far as I can see, the standard mandates what inf and sup should return, but not the internal representation of the empty set.

[dpsanders]

Indeed in section 14.2, one possible representation is given as [NaN, NaN].

[lbenet]

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.

[dpsanders]

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.

[lbenet]

Isn't the same true with Infs?

[dpsanders]

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]

[lbenet]

But...

julia> add(emptyinterval(Float64), 1..1)
∅

[dpsanders]

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.

[lbenet]

You are right... Why don't you simply test your proposal?

[dpsanders]

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!

[Kolaru]

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.

[dpsanders]

Yes agreed. Basically we should avoid directly accessing x.lo.

[OlivierHnt]

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.