Interval comparisons may make other packages functions behave unexpectedly

[Kolaru]

Comparisons (==, >, <, etc.) between intervals or comparisons between intervals and numbers are possible, and run smoothly and silently, but they may behave in ways that may not make sense for the algorithm used.

As a simple illustration, a decent implementation of sinus cardinal (sin(x)/x) may be

function sinc(x)
    if x == 0
        return one(x)
    else
        return sin(x)/x
    end
end

But

julia> X = -0.001..0.001
[-0.00100001, 0.00100001]

julia> sin(X)/X
[-∞, ∞]

because X != 0 (correct result is [0.999998355066745, 1]).

In particular this makes many functions of SpecialFunctions.jl behave incorrectly, and it may be the reason behind this issue.

A possible way to mitigate it, beyond documenting it, may be to implement a debug mode that raise a warning whenever such comparison is performed.

[dpsanders]

I believe that the problem is not the comparisons, but rather using an if.
Conditionals should be avoided with intervals exactly for this reason.

In general, "standard" algorithms will not work correctly for intervals.
Writing interval versions of special functions is, unfortunately, often rather tricky.

[dpsanders]

In the particular case of sinc, you could e.g. use a separate Taylor expansion for the region near 0.

[dpsanders]

(And note that you should use one(x) instead of 1 for type stability.)

[gwater]

I'd like to propose the same solution I described here: Comparisons are inherently questions about numbers, not intervals. Therefore they cannot be decided in some cases. For example 1..2 < 3 can be decided but 1..3 < 2 has no meaningful answer.

So what do you think of this?

function <{T}(x::Interval{T}, y::T)
    x.hi < y && return true
    x.lo > y && return false
    throw(InexactError())
end

or, for two intervals:

function <{T}(x::Interval{T}, y::Interval{T})
    isbefore(x, y) && return true
    isafter(x, y) && return false
    throw(InexactError())
end

(Here I use isbefore() and isafter() in the sense of IEEE 1788-2015, Table 10.7.)

[lbenet]

I think questions like these, namely 1..2 < 3 or 1..3 < 2, are formulated considering intervals as sets. So, if the inequality holds for all members of the interval, you get true, otherwise false.

Note that there exist already the functions precedes, strictprecedes, islessprime, which I think are required by the standard.

[Kolaru]

I think questions like these, namely 1..2 < 3 or 1..3 < 2, are formulated considering intervals as sets. So, if the inequality holds for all members of the interval, you get true, otherwise false.

This interpretation is perfectly reasonable. Indeed, intervals are not numbers, therefore the fact that for example 1..3 < 2 and 1..3 >= 2 are both false is fine, even if it would never be the case for numbers.

However, one of the great things about intervals is that in most cases intervals behave as numbers. An awesome thing about this package is that it actually allows the user to use intervals in place of numbers without further modification, immediately giving correct results.

This is very convenient, but implies that Interval is a subtype of Number, i.e.

julia> isa(1..3, Number)
true

This suggests that with the current implementation intervals actually behave as numbers (which in general they don't).

Therefore, in my opinion, when it is not in contradiction with the standard, we should prefer the "convenient for user way" of having intervals that behave as numbers whenever it makes sense and otherwise throw an error. This is what the proposition of @gwater would enforce, and this overall strategy would guarantee that using intervals in place of numbers always yields correct results. (Note that correct does not implies useful, for example dividing by -1..1 actually yields a correct and in most cases useless result)

[oschulz]

How about making comparisons return an interval? If the result of the comparison is true for all possible values left and right of the comparison operator, the result would be something like Interval{Bool}(true, true). If false for all values, Interval{Bool}(false, false). Otherwise, the result would be Interval{Bool}(false, true).

This would automatically cause errors for if-statements on interval comparisons. And we could add a method to ifelse that supports Interval{Bool}, and depending on the boolean interval returns the result for true, or the result for false, or the minimum interval covering the both possible outcomes.

[gwater]

I've implemented an interval type based on IntervalArithmetic's intervals which behaves more predictable and cautious in comparisons. Feel free to upstream some methods. https://github.com/gwater/NumberIntervals.jl

[oschulz]

@gwater, I like that approach - are you planning to register NumberIntervals?

[oschulz]

Alternatively - maybe that new interval type could be integrated into IntervalArithmetic? @dpsanders, @gwater, what do you think?

[gwater]

@gwater, I like that approach - are you planning to register NumberIntervals?

After some testing interoperatibility with other packages a bit more, yes. Safe interoperatbility is really the main goal – are we able to use NumberIntervals safely with algorithms designed for Reals without the kind of silent failures IntervalArithmetic currently produces?

Alternatively - maybe that new interval type could be integrated into IntervalArithmetic? @dpsanders, @gwater, what do you think?

I think it's ok to have two separate packages for now: One for strict IEEE conform intervals (IntervalArithmetic), and one for Number-like intervals based on the former (NumberIntervals). Nevertheless, I would also welcome upstreaming NumberIntervals; or perhaps #271 will one day make NumberIntervals obsolete.