alt Hacker NewsAuthor 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
Replies
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.
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?