AbstractInterval

[lucaferranti]

Currently on master we have Interval <: AbstractInterval <: Real but DecoratedInterval doesn't have a supertype. On 1.0-dev AbstractInterval was completely removed (probably by accident). I think we should have both Interval and DecoratedInterval as subtypes of AbstractInterval. This would allow to write generic code that works for both, while atm TaylorModels, IntervalLinearAlgebra etc. don't work with decorated intervals. To write generic code, there are two options

Options 1

struct Interval <: AbstractInterval
  lo
  hi
end

struct DecoratedInterval <: AbstractInterval
  interval
  dec
end

and then don't access lower bounds of intervals as a.lo, a.hi but use getters inf, sup everywhere in IntervalArithmetic.jl

Options 2

store a decorated interval as

struct DecoratedInterval <: AbstractInterval
  lo
  hi
  dec
end

this allows to access lower and upper bound directly.

[lbenet]

This issue actually has two parts:

• With respect to AbstractInterval{T}, I agree that there should be a common abstract supertype! While such a change may not matter for IA, other libraries could benefit from that (e.g., IntervalContractors).
• Regarding changing the internal structure of DecoratedInterval, I think I prefer to have the one we currently have, extending inf and sup to DecoratedIntervals, and use those functions thoroughly and consistently thoughout all IA-packages. I think this was partially addressed by @Kolaru in Implement systems for flavor, pointwise extensions, default bound and rounding mode #271, but we still have some places in 1.0-dev where this has to be fixed...

[lucaferranti]

based on yesterday discussion, option 1 is probably better

[Kolaru]

I also agree that option 1 is best.

Then there is still two possibilities about the defined interface:

• Require using inf and sup for generic code (works well also if we ever support center-radius intervals).
• Require subtype to have x.lo and x.hi defined. This would require hacking into getproperty for DecoratedInterval, but allow to keep most of the current code as-is. I don't think it is a particularly good choice, but may be useful to consider for the transition.

[lbenet]

I'm on the tedious translation on using thoroughly inf and sup... As far as I have checked, there is only one instance where things have to be more carefully done.

[OlivierHnt]

Closing this issue since it seems that everything has been addressed in current master. Specifically,

• we use inf, sup and bounds throughout the code
• we decided to preserve Interval <: Real (previously called DecoratedInterval) while having the BareInterval (previously called Interval) struct not a subtype of Real. This implies that we cannot have a common supertype for both interval types

Please re-open it if I overlooked something.