Can't multiply a `BareInterval` by a scalar

[dpsanders]

julia> bareinterval(3, 4) * 5
ERROR: MethodError: no method matching *(::BareInterval{Float64}, ::Int64)

[dpsanders]

I believe this is due to a missing promote_rule here.

I think there should be a common supertype for Interval and BareInterval.

[OlivierHnt]

This is intentional and was one of the major point of the 0.22 release (and presumably the next 1.0 release). See eg some of the merged PR on bare intervals.

For now I am closing this issue, but of course feel free to re-open it if you cannot find a satisfactory answer and want to re-discuss this decision.

[dpsanders]

I'm re-opening this for the following reason:

Every interval constraint propagation computation involves an intersection of intervals, which always reduces the decoration to trv. It is thus pointless to work with decorations at all -- or, rather, worse than pointless, since I still have to pay the cost of the decoration storage and computation. It thus makes sense to use BareInterval, but I still need all of the standard interval operations to work properly.

[OlivierHnt]

Oh of course. Note that the standard interval operations for bare intervals are provided, as described by the IEEE Std 1788-2015. In particular you cannot mix numbers and intervals.

Did you run into this issue because you have some generic code where literals are involved?

Recently we introduced ExactReal and the macro @exact to allow operations involving Interval and Number. To illustrate

julia> @exact interval(3, 4) * 5
[15.0, 20.0]_com

julia> @exact foo(x) = (1+x)^2
foo (generic function with 1 method)

julia> foo(1)
4

julia> foo(interval(1))
[4.0, 4.0]_com

Making this compatible with BareInterval would be nice and could address this issue.

[lbenet]

This problem (intersection and trv) was somewhat discussed in #624; if I recall correctly, this behavior follows the standard. Among other, some functionality was introduced to change decorations easily with setdecoration, and this can be done by the user.

The design was thoroughly discussed: We must not overload all possible BareInterval operations, specially those mixing numerical values and bare intervals, precisely to be sure that the results are always correct. (Put simply, the numerical value can be exact, or include some complicate operations that make impossible to define a simple interval to compute the correct bounds.) The user can still internally change this behavior, and change the resulting decorations in the specific application, taking all responsability for correctness.

This is indeed not the most comfortable approach, but a rather small price to be paid for correctness.