When is an Interval infinite? [ definition of isinf() ]

[gwater]

The current definition of isinf() has raised questions here and here. We should settle these discussions here and find a meaningful (and useful) definition for isinf() or remove the method if we cannot.

For reference, the current definition:

isentire(x::Interval) = x.lo == -Inf && x.hi == Inf
isinf(x::Interval) = isentire(x)

[lbenet]

Thanks for opening this issue (rather than moving this elsewhere in IntervalRootFinding).

Just to state what I already proposed, in my opinion isinf(x::Interval) should be defined as isinf(x::Interval) = !isfinite(x).

[dpsanders]

isinf in Julia means very specifically that the "value is infinite".

I don't think there is a useful version of this for intervals, so the method should probably be removed.

[gwater]

There are only two valid cases in my opinion:

• an interval contains only finite numbers
• an interval contains both one or more infinities and finite numbers

In the first case I think it's clear that isinf() should return false. In the second case I think no meaningful value can be returned because the specific number which is described by the interval could be either infinite or not. Returning true would be misleading.

Therefore I think isinf() should not be defined at all for intervals, or better yet, it should raise an error.

[lbenet]

Since isinf(a) has a method in Base foe a::Real, probably the best way out is to throw an error.

[gwater]

If it is not defined; isinf() will fall back to the definition in Base which is

isinf(x::Real) = !isnan(x) & !isfinite(x)

[dpsanders]

OK, let's throw an error.

[gwater]

Tricky question: Do we always throw an error or only when the interval contains an infinity?

[dpsanders]

I was wondering that. I have a feeling it will be more useful to always throw an error, so that you find out fast if an algorithm is or not suitable for using with intervals.

[gwater]

On the other hand it might break algorithms which are working fine at the moment (as long as you don't throw infinities at them).

[dpsanders]

Right, but that might break if an infinity gets in there in an inconvenient moment. Tricky one.

[gwater]

I think as a user I would prefer an algorithm to work until it hits an actual problem. And then I could catch the error and deal with it in some way.

[dpsanders]

Yes that's a good point. It seems weird to throw an error from the isinf function precisely when the interval is of infinite length (which, as above, is not the same as "being infinite"), but maybe that's actually what we should do then.

[gwater]

Now, as I think through this: Doesn't all of this apply to isfinite(), too? And more generally to the question of comparisons raised in #165? It might be feasible to raise errors in many undecidable cases and prevent algorithms silently failing (while allowing them to run in decidable cases).

[gwater]

To me isinf(), isfinite(), iszero(), etc. are all questions about numbers not intervals but sometimes we can say something about the numbers contained in the intervals. So I would propose the following principle: reduce questions about numbers contained in intervals to questions about the intervals themselves.

To illustrate, consider these definitions:

function isfinite(x::Interval)
    isbounded(x) && return true
    throw(InexactError())
end

isinf(x::Interval) = !isfinite(x)

function iszero{T}(x::Interval{T})
    x.lo == x.hi == zero(T) && return true
    throw(InexactError())
end

(Sidenote: isbounded() doesn't exist yet but it should because !isunbounded() does not catch NaNs.)

[lbenet]

I like the idea!

It would be a good idea to catch cases that include NaIs ([NaN,NaN]).

[OlivierHnt]

On master branch we chose to be very conservative with boolean functions to prevent silent errors. Using Interval as a drop-in replacement of a Number in a code should yield an error.
In this regard, the functions isinf, etc. are no longer intended to be supported.