Remove Interval <: Real ?

[dpsanders]

Since ForwardDiff now no longer requires types to be <: Real (JuliaDiff/ForwardDiff.jl#369, although not yet in a released version), maybe it is time to make Intervals no longer be subtypes of Real.

cc @gwater

[gwater]

As discussed earlier, I would strongly support that. (So far I have not been able to resolve the constructor issues in #181; I think for now it is a dead end.)

[Kolaru]

I am currently looking into that issue and complex numbers appear to be problematic. Complex{T} requires T <: Real, which means our current definition of complex intervals (Complex{Interval{Float64}}) would no longer be valid.

Even if the requirement to have Real components was removed from Base, it would kind of be awkward to have (0.1..0.5) not be a Real while (0.1..0.5) * im is a Complex (which is inavoidable to reuse the definitions from Base).

So I think we will have to keep Interval as Real.

[gwater]

it would kind of be awkward to have (0.1..0.5) not be a Real while (0.1..0.5) * im is a Complex (which is inavoidable to reuse the definitions from Base).

I'm not exactly sure how Complex{Interval} currently behaves. In mathematical terms it should be equivalent to a 2-dimensional IntervalBox, no? Or is it more like a straight line on the complex plane? In either case, it raises the same questions as the real case: Are complex intervals sets of numbers or do they each represent one specific (but uncertain) number? In the latter case subtyping makes sense; in the former it's problematic.

[Kolaru]

I'm not exactly sure how Complex{Interval} currently behaves.

A Complex{Interval} is simply an object A + B*im with A and B intervals, so it is like an 2-dimensional IntervalBox.

Are complex intervals sets of numbers or do they each represent one specific (but uncertain) number? In the latter case subtyping makes sense; in the former it's problematic.

While I agree with this analysis (and prefer the former interpretation), it lefts out the following practical concern: all Base complex functions for a complex number a + b*im are defined in term of operation on a and b and as a consequence, the current definition of complex interval can reuse all the definitions from Base (with the exception of some functions doing branching as in #245 ). Not subtyping complex interval to Complex implies to either redefine all these functions, or to remove the requirement for Complex to have Real components and have Complex{T} not always be a subtype of Complex. Both solution require a lot of work that I am not sure is worth for the sake of mathematical purity.

[gwater]

the current definition of complex interval can reuse all the definitions from Base (with the exception of some functions doing branching as in #245 ). […] Both solution require a lot of work that I am not sure is worth for the sake of mathematical purity.

I disagree with your premise: The subtyping question is not about mathematical purity but about very practical concerns. The implementations in Base all assume that they are handling objects representing specific numbers and that operations on their real components behave like operations on real numbers. However, real Intervals in IntervalArithmetic.jl don't behave like numbers; they behave like sets. (That is why this issue exists.) Therefore, which implmeentation is used is not a question of convenience but of meaningful results. Currently it is impossible to predict when a complex interval does what it's supposed to and when it silently breaks.

The problem isn't that Intervals are a subtype of Real; it's that they are a subtype of Number (either via Real or via Complex) while at the same time behaving like sets in many operations.

[Kolaru]

I think I get your point (and mainly agree with it). However I feel like it may be kind of tangential to the question of keeping or not Interval <: Real: in both cases we have to to handle ambiguous situations with intervals, by choosing if the process should error or not. As far as I can see, removing Interval <: Real does not help from a programming point of view (it would definitively be less confusing for the user in many case though).

[gwater]

As far as I can see, removing Interval <: Real does not help from a programming point of view

I think it would be helpful because it would a) prevent silent failures when people try to use set-like intervals as drop-ins for numbers and b) open up the way to actually implementing a number-like interval which could be used like that. The current subtyping is an anti-feature: It suggests compatibility where there actually isn't any and introduces catastrophic bugs like JuliaIntervals/IntervalRootFinding.jl#86

[Kolaru]

I think it would be helpful because it would a) prevent silent failures when people try to use set-like intervals as drop-ins for numbers

That is where I get confused by your reasonning. All basic functions are redefined in this package for intervals (otherwise Julia would not know how to handle the new type, even if it is a subtype of Real, and it would error).

Therefore if a method silently fails it is because it has been defined to do so in this package and having Real as a supertype does not seems to have any influence here.

[lbenet]

I am coming too late to the party, though I've spent some fair amount of time thinking about this. In my opinion, the discussion here reflects the discussion of the Interval community itself: is an Interval a set of numbers or a number? I think the usual opinion (with many disadvantages!) is to think it as an unknown number which lies inside a given set; there are other approaches that take it as the set of those possibilities. Both options have advantages and disadvantages.

In my specific case, I do need that Interval{T} is a subtype of something below Number, so being a subtype of Real is fine. The reason is that Taylor1{U} or TaylorN{U} (both subtypes of Number) require U<:Number. My interest is building rigorous Taylor expansions of a given function, which then requires interval coefficients for the expansion and for the remainder. Clearly, I am in favor of keeping Interval{T} at least as a subtype of Real. Yet, there are good arguments not to have it as a subtype of Real.

My proposal here is then pragmatical: let's provide another (new!) struct which is not a subtype of Real. In terms of the jargon of the IEEE standard, this amounts to define another flavor.

[gwater]

I have to admit I'm a little frustrated with this topic because I know we have discussed all of this before (eg. in #168 and #165): I completely understand that it seems practical to use Intervals with packages that expect Numbers. The problem is that currently methods like iszero() and isinfinite() as well as all comparisons are defined based on the IEEE standard which decidedly treats intervals as sets. Please look at these methods, look at the standard, and look at JuliaArrays/StaticArrays.jl#450 to see it all explodes. What we actually need for the Julian convenience drop-in Interval is a flavor which does not follow IEEE in its definitions (but builds on the IEEE methods internally). Since it was made clear in #181 that the Interval implementation in this package is meant to follow IEEE removing the Number supertype or splitting set-like and number-like Intervals is the only way to resolve this.

I will not draw this fruitless discussion out further. If you want, close this bug report and move on. I guess, if you redefine ldiv() internally you can even avoid JuliaArrays/StaticArrays.jl#450 . But you can be sure that bugs like that one will keep popping up, as long as you define set-like behaviors on a Number subtype.

[dpsanders]

I have to say that I have come round to @gwater's arguments here. I suggest we make a branch where we remove <: Real and see how much actually breaks.

As regards the knock-on effects of this, there is already a type called Compl defined, I think in IntervalRootFinding.jl, which redoes some of Complex; it should not be too hard to flesh out the rest. ForwardDiff.jl already allows types that are not <: Real.

Also, @Kolaru has a very interesting PR for defining these different "flavours", if I remember correctly.

[Kolaru]

I have to admit I'm a little frustrated with this topic because I know we have discussed all of this before (eg. in #168 and #165)

Sorry to hear that and to have appeared stubborn (well I may even actually be stubborn, as the next sentence may indicate x_x). I precisely think that the discussion here is different to #165 and #168, but won't draw this further either.

As regards the knock-on effects of this, there is already a type called Compl defined, I think in IntervalRootFinding.jl, which redoes some of Complex; it should not be too hard to flesh out the rest.

My main concern here is that base/complex.jl is about 1000 lines long, so it is definitely a serious amount of work (highlighting that I am getting closer and closer to have written 1000 lines in the different issues relating to this problem would be a valid point though). Quite a big amount of the file however seems to be about having the most precise implementation which may be adressed at a latter time.

Also I realised that if we ever want to support complex number in polar form rho * exp(im*arg), redefining everything will be pretty much inavoidable.

Also, @Kolaru has a very interesting PR for defining these different "flavours", if I remember correctly.

You probably refer to this comment in @gwater PR. It is not directly applicable to a situation with one flavour being subtype of Real (let name this PseudoNumberInterval) and not the other (say SetInterval), because they will not be able to have a common supertype.

A possible workaround is to have something like

abstract type IntervalMode end
struct Strict <: IntervalMode end
struct Silent <: IntervalMode end

struct ConcreteInterval{T, M <: IntervalMode}
    lo::T
    hi::T
end

struct PseudoNumberInterval{T, M} <: Real
    interval::ConcreteInterval{T, M}
end

struct SetInterval{T}
    interval::ConcreteInterval{T, Strict}
end

AnyInterval{T, M} = Union{PseudoNumberInterval{T, M}, SetInterval{T}}

and to define most functions for ConcreteInterval{T, M} and make functions for AnyInterval{T, M} refer to it (may be done at once using some some macro magic).

Strict mode should error in ambiguous cases (e.g. 0 > (-1..1)), while Silent returns false silently. There are 3 possibilities at the end as SetInterval are always Strict (they will error anyway on any function defined on Real having them Strict simply allows to provide more helpful error messages), while PseudoNumberInterval may have both modes.

There should be no performance penalty as long as struct avoid having AnyInterval as member variables. However which one to use should in general be clear for example, @lbenet needs one flavour of PseudoNumberInterval while IntervalRootFinding should probably use SetInterval in its Root object.

Finally, note that different flavour will need to be able to interact, as for example you search the roots of a TaylorSeries from @lbenet you will work with at least two flavours (I have a use case which is actually conceptually similar to that problem).

[Kolaru]

Since most problems seem to come from functions returning booleans, ConcreteInterval in the draft proposition above could use correct three way logic (true/false/unconclusive) and the wrapper is responsible for deciding what to do with the unconclusive value. Silent intervals would turn it into either true or false (currently it is always false I think) while Strict intervals should raise an error.

(Silent is a terrible name by the way, the point of this mode is not being Silent it is returning true only if the test is true for all element in the interval.)