Author here. Outward rounding to combat precision issues is what interval arithmetic is most known for (try 0.1+0.2 with "full precision mode" enabled), but that's really a shame in my opinion. Outward rounding is cool, but the "inclusion property", as it's known in research papers, works at every scale! This is what enables things like:
50 * (10 + [-1, 1])
[450, 550]
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
Nice! I am interested in how the arithmetic you implemented differs from the IEEE 1788 Standard for Interval Arithmetic (and how the two linked papers relate to it). To address the challenges you mention, did you have to start from scratch or was it something that can build on top of the IEEE standard?
Interesting! I'm not familiar with IEEE 1788. The TypeScript library (not-so-float) that I wrote which powers the calculator uses the JS Number type which is double precision IEEE 754. Outward rounding is not supported by JS so I used a bit level manipulation hack by casting to TypedArray [0] to implement the equivalent of C's nextafter() function. Otherwise I mostly followed Hickey & van Emden paper which is really delightful [1]. The real hard work is actually generating all the test cases. Good luck getting 100% test coverage on interval division!
[0] https://github.com/victorpoughon/not-so-float/blob/main/src/...
[1] https://fab.cba.mit.edu/classes/S62.12/docs/Hickey_interval....
Very cool, I'll definitely be playing around with this some more! Two questions:
- 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.