I have used interval arithmetic in a couple of projects, though I wouldnât call myself an expert, and here are my 2 cents: when you look at the problem more closely, the âintervalsâ from interval arithmetic are *not* the right tool to represent domains. They are meant to represent uncertainty on quantities; the two concepts are orthogonal.

Illuminating example: you wish to solve the optimization problem

\min_{x\in [\sqrt2, \sqrt3]} x^2.

Neither \sqrt2 nor \sqrt3 are exact `Float64`

numbers, and should be represented themselves by an interval if you want a rigorous result; for instance, `1.4141..14142`

. So passing this domain to an optimization function becomes impossible if you want to use an interval type for that. You can do the following

```
using IntervalArithmetic
a = sqrt(@interval(2))
b = sqrt(@interval(3))
D = hull(a, b) # this returns the interval [a.lo, b.hi]
y = minimise(x -> x^2, D) # this will return an interval containing (D.lo)^2
```

but it is a subtly different thing: for instance, the length of your domain is the uncertain quantity `b-a`

, i.e., [`b.lo-a.hi`

, `b.hi-a.lo`

], which is not `diam(D)`

and is in fact impossible to retrieve from `D`

, since information about `a.hi`

and `b.lo`

has disappeared. And the call in the last line returns an interval containing `a.lo^2`

; this is not guaranteed to contain the exact solution to your problem, `2.0`

.

In my humble opinion, when doing rigorous computations with interval arithmetic the notation `a..b`

should be used to represent *a single real number* whose value is not known exactly as a `Float64`

, and not the thing that you call âintervalsâ in a calculus course. Do not let the name mislead you. I have done that mistake before, and can advise against it.

Maybe you want a parametric type for this job

```
struct Domain{T}
a::T
b::T
end
```

but at this point the benefits over a tuple are unclear.