Arithmetic with big constants should not promote

[dpsanders]

Probably we would prefer the following to return an Interval{Float64}. This is happening due to the automatic promotion rules:

julia> interval(1.0) / factorial(big(100))
Interval(1.071510288125466923183546759519191522011540649292709804836865813095970266876232e-158, 1.071510288125466923183546759519191522011540649292709804836865813095970266876248e-158)

julia> typeof(ans)
Interval{BigFloat}

We can get around it by an explicit conversion:

julia> interval(1.0) / convert(Interval{Float64}, factorial(big(100)))
Interval(1.0715102881254667e-158, 1.0715102881254671e-158)

Note also that Interval{Float64}(factorial(big(100))) does not give an enclosure, which is a bug:

julia> Interval{Float64}(factorial(big(100)))
Interval(9.332621544394415e157, 9.332621544394415e157)

[lbenet]

I think promotion rules are ok, simply because following them is consistent with Base; then, one has to rely on the explicit conversion if Interval{Float64} is the goal.

You are right that the result of Interval{Float64}(factorial(big(100))) is wrong. A simple solution, I think, is by using the following methods (instead of the current one): Interval{T}(x) where {T} = atomic(Interval{T}, x). Then,

julia> IntervalArithmetic.atomic(Interval{Float64}, factorial(big(100)))
Interval(9.332621544394415e157, 9.332621544394416e157)

[dpsanders]

We are free to define our own promotion rules. I think the fact that we are working with Interval{Float64} should take priority over the fact that there's a BigInt number, and if you want Interval{BigFloat} then you should say so explicitly.

[lbenet]

I agree with you that we are free to define the promotion behavior. Yet, as pointed out above, the default behavior should be consistency with Base.

In my opinion, in the example with factorial(100), the user needs factorial(big(100)) to avoid an OverflowError. If the user forces an exception going to BigInt, in order to get back to Float64 the user should convert explicitly to Interval{Float64}.