One reason for this is that standard interval arithmetic has really poor handling of division by intervals containing zero. If you compute 1 / [-1, 2] in regular interval arithmetic, you get either [-∞, +∞], or you have to say that the operation is undefined. Both solutions are virtually useless. The real answer of course is [-∞, -1] U [0.5, +∞]: i.e. a union of two disjoint intervals.
This is useful because you can confidently exclude a non empty set of the real numbers ([-1, 0.5]) from the set of possible values that you can get by dividing 1 by a number between -1 and 2.
But this definition of interval division yields a value that is not an interval. This is a problem if you want to define a closed arithmetic system, where you can build and evaluate arbitrary expression over interval values.
(This behavior extends to any non continuous function like tan() for example, which is implemented in my project - not without difficulties!)
Well the obvious solution is to define your arithmetic over disjoint unions of intervals. This is the subject of a 2017 paper called "Interval Unions" by by Schichl, H., Domes, F., Montanher, T. and Kofler, K..
This open-source project I made implements interval union arithmetic in TypeScript in the form of a simple interactive calculator, so you can try it out for yourself! The underlying TypeScript library is dependency free and implements interval union arithmetic over IEEE 754 double precision floats (JS native number type) with outward rounding. This guarantees accuracy of interval results in the presence of rounding issue inherent to floating point.
This is based Raku’s built-in Junction and Range classes and was an interesting experiment.
https://memalign.github.io/m/formulagraph/index.html
Some detail on how this works, including links to the relevant interval math code:
Applied to the cases here:
]-∞, -1] U [0.5, +∞[
The excluded interval in between becomes ]-1, 0.5[ then.
That’s how min (and analogously max) works, right? min(A, B) = [lo(A,B), lo (hi(A), hi(B))].
Edit: idea: copy a formula from the results section to the input field if the user clicks/taps on it.
(0, 1)
See, this is why Bourbaki introduced the ]0,1[ notation.
I wish in classes we were introduced to a notion of arithmetic on intervals as it comes up. Like in basic statistics with confidence intervals there's ±, as well as in the quadratic equation. It found some what dissatisfying we couldn't chain the resulting a series of operations and instead repeat the operations for the 2 seperate values of the ±. I get a teacher would rather not get hung up on this because they want to bring it back to the application generally, like solving a more complicated equation or hypothesis testing in basic stats. I just wish they hinted at the idea we can do arithmetic on these kinds of things more generally.
I realise what you've got here is well beyond this, but seeing this was some level of validation that treating the interval as a piece of data with its own behaviour of certain operations does make some sense.
e.g. the result for the 1 / [-1, 2] example doesn’t tell you how likely each value is and it clearly won’t be uniformly distributed (assuming the inputs are).
I therefore needed to include a complement operation, so that I could do full Boolean analysis of interval membership.
Your intervals are all closed sets, consequently the complements are open intervals. I chose not to distinguish between open and closed intervals, since for my practical purposes whether the end points are members of the set is unimportant.
Of course, with inexact arithmetic, the question of whether the set is open of closed probably not well-defined.
There's other unused stuff in IEEE 754 like that: the inexact bit or signaling NaNs!
if (x >= 0) {
x += 10
if (x =< 9) {
// unreachable
}
}
initial: [-oo, oo]
x >= 0 : [0, oo]
x += 10: [10, oo]
x =< 9 : [10, 9] (empty)The police measure the distance my car travelled [ 99.9, 100.1 ] m and the time it took [ 3.3, 3.4 ] s - how fast was my car going? [29.38, 30.33] m/s according to the interval calculator.
Physics students learn exactly this method before they move on to more sophisticated analysis with error distributions.
The interval abstract domain works under interval analysis with an algebra that’s the same of this calculator. It’s funny to implement something like that on source/binary level :)
For example a +- b would be [a - b, a + b]
Though you are inherently losing precision: there are values in the output interval which don't have a corresponding input that causes this output.
Disjoint unions of intervals seems like a nice thing to have
Namely, the "powerset of intervals" domain has been known since the '70s [1], and powerset domains have been generalised to arbitrary base domains decades ago [2]. A paper from the mid-2010s on these topics that lacks any engagement with the abstract interpretation literature is a bit disappointing.
As for the interpretation of division suggested here, it makes, say, 1 / S non-distinguishable from 1 / ([0, 0] U S) for any set of intervals S, which sounds suspicious.
[1] Patrick Cousot and Radhia Cousot. 1979. Systematic Design of Program Analysis Frameworks. In 6th ACM Symposium on Principles of Programming Languages (POPL), January 1979. ACM Press, San Antonio, TX, USA, 269–282. https://doi.org/10.1145/567752.567778
[2] Gilberto Filé and Francesco Ranzato. 1999. The Powerset Operator on Abstract Interpretations. Theor. Comput. Sci. 222, 1–2 (1999), 77–111. https://doi.org/10.1016/S0304-3975(98)00007-3
I made interval calculator actually mostly as a way to test my implementation of interval union arithmetic [0], which I needed for another project: a backwards updating spreadsheet [1][2].
[0] https://github.com/victorpoughon/not-so-float
[1] https://victorpoughon.github.io/bidicalc/
[2] https://news.ycombinator.com/item?id=46234734
[0] https://github.com/victorpoughon/not-so-float/blob/main/src/...
[1] https://fab.cba.mit.edu/classes/S62.12/docs/Hickey_interval....
- How difficult would it be to add many-valued functions to this? It would be really nice to be able to get the full set of [pi/2, pi/2] + n[2pi, 2pi] from asin(1) without needing to break out Mathematica.
- And:
> Numbers input by the user are interpreted as the smallest interval that contains the IEEE 754 value closest to the input decimal representation but where neither bounds are equal to it
Am I missing something obvious, or should this be the other way round, i.e. the output bounds are the closest two IEEE 754 numbers that contain the input number?
The way it's written I'd interpret the smallest interval to be IEEE754(input)+[-epsilon, epsilon] for infinitesimally small epsilon.