[HN Gopher] Show HN: I made a calculator that works over disjoin...
___________________________________________________________________
Show HN: I made a calculator that works over disjoint sets of
intervals
I've been studying interval arithmetic for the past few weeks and
it's a really interesting field because while there is a ton of
super interesting research published over the past decades, it has
never really gotten the recognition that it deserves, IMO. 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.
Author : fouronnes3
Score : 286 points
Date : 2026-04-18 01:15 UTC (21 hours ago)
(HTM) web link (victorpoughon.github.io)
(TXT) w3m dump (victorpoughon.github.io)
| fouronnes3 wrote:
| 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]
|
| which is lovely, I think. Adding the union layer to it enables
| even cooler things, like the true inverse of the square function.
| Did you know it's not sqrt? Try 'sqinv(64)'.
|
| 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
| thekoma wrote:
| 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?
| fouronnes3 wrote:
| 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_interv
| al....
| noncovalence wrote:
| 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[2 _pi, 2_ pi] 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.
| iamwil wrote:
| This is great. You might be interested in Matt Keeter's work on
| Implicit surfaces, and using interval math for its optimization:
|
| https://youtu.be/UxGxsGnbyJ4?si=Oo6Lmc4ACaSr5Dk6&t=1006
| memalign wrote:
| You might be interested in this graphing calculator I made using
| interval arithmetic:
|
| https://memalign.github.io/m/formulagraph/index.html
|
| Some detail on how this works, including links to the relevant
| interval math code:
|
| https://memalign.github.io/p/formulagraph.html
| 0xml wrote:
| Looks like GrafEq?
|
| http://www.peda.com/grafeq/
| _Microft wrote:
| Very nice, thanks for sharing! Maybe show which upper or lower
| values are included in the intervals? A notation I am familiar
| with uses outward facing brackets if the value is not included in
| the interval. That always applies to infinity.
|
| 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.
| globular-toast wrote:
| I was also a bit confused by this. I thought the standard
| notation was round brackets, but maybe doesn't work well in
| ASCII?
| qbit42 wrote:
| Round brackets are standard in the US but that notation is
| used in France and some other places.
| meindnoch wrote:
| (0, 1)
|
| Is this an twice-open interval or a 2D vector?
|
| See, this is why Bourbaki introduced the ]0,1[ notation.
| streetfighter64 wrote:
| Is there any reasonable situation where you'd be confusing
| a vector with an interval? Having done mathematical writing
| and grading of tests using both styles of notation (simply
| adapting to what was used at the institution), I can't say
| that I ever noticed any practical difference between them.
| adito wrote:
| From reading the linked paper[0], It explains closed interval
| only. "An interval union is a set of _closed_ and disjoint
| intervals where the bounds of the extreme interval can be +-[?]
| ".
|
| [0]: https://www.ime.usp.br/~montanhe/unions.pdf
| fouronnes3 wrote:
| It's possible to support that but it makes the code very very
| much more complicated. I've decided early on to not support it.
| Would be a cool addition though!
| anematode wrote:
| Excellent!! I love interval arithmetic and also wrote a TS
| implementation for a graphing calculator project. Agree that it's
| very underrated, and I wish that directed rounding was exposed in
| more languages.
| fouronnes3 wrote:
| Yeah it's super interesting. Like you said, I learned that the
| IEEE 754 spec actually requires that complete implementations
| of floating point numbers expose a way to programmatically
| choose the rounding mode. As far as I know only C allows you to
| do that, and even then it depends on hardware support. For JS I
| had to use ugly typedarray casts. Which kinda only accidentally
| work due to endianess. But technically there should be an API
| for it!
|
| There's other unused stuff in IEEE 754 like that: the inexact
| bit or signaling NaNs!
| JSR_FDED wrote:
| I just read up on interval arithmetic. I understand its desirable
| properties. Where in practice have you applied it? What's a real
| world application for interval arithmetic?
| ngruhn wrote:
| It can be used in static analysis or type checking. E.g.
| if (x >= 0) { x += 10 if (x =< 9) {
| // unreachable } }
|
| By maintaining an interval of possible values of x, you can
| detect the unreachable branch, because the interval becomes
| empty: initial: [-oo, oo] x >= 0 :
| [0, oo] x += 10: [10, oo] x =< 9 : [10, 9]
| (empty)
| thekoma wrote:
| We recently implemented this idea in an LLVM optimisation
| pass based on value-range information from sensor datasheets
| [1].
|
| [1]: https://dl.acm.org/doi/pdf/10.1145/3640537.3641576
| Oberdiah wrote:
| I'm working on a static analyser at the moment that does
| this, and the inferences that can be made just from the
| information of intervals is quite impressive. One thing you
| run into pretty quickly though in a lot of languages is
| integer overflow ruining your day - in your example above the
| commented section is reachable for signed ints that support
| overflow and that adds a whole other layer of complexity to
| things.
| nicolodev wrote:
| It's astonishing how nobody hasn't mentioned abstract
| interpretation yet. Under classical static analysis, if you can
| "prove" that a variable does not have values in some unsound
| zones, you can e.g. "prove" soundness or apply further
| optimizations.
|
| 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 :)
| nickcw wrote:
| In physics, whenever you make a measurement it has a precision.
| Usually you represent this as a normal distribution, but for
| calculations it can be easier to represent this as an interval.
|
| 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.
| ttoinou wrote:
| And one might want to approximate error distribution calculus
| with a method that will look like the one here
| boobsbr wrote:
| Neat.
| petters wrote:
| You could add a feature where it will compute the global optimum
| of any function of a small number of variables. Branch and bound
| with interval arithmetic works well for a small number of
| variables.
|
| Disjoint unions of intervals seems like a nice thing to have
| teiferer wrote:
| The last point in your intro description can't be stressed
| enough: this allows for safe handling of rounding errors in
| floating point operations.
|
| Though you are inherently losing precision: there are values in
| the output interval which don't have a corresponding input that
| causes this output.
| dnnddidiej wrote:
| Interals can be used to model errors and uncertainty and this
| lets you see how they conpound in calculations like speed =
| distance over time.
| akst wrote:
| Very cool! I don't entirely understand some of the operations,
| but for what I do understand its pretty neat.
|
| 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.
| ttoinou wrote:
| Why not use disks / exterior disks in the complex numbers plane
| instead of intervals ? It might make the mental model easier to
| reason about
| dfgtu wrote:
| Very nice work. I was wondering if it might be useful to combine
| this with a library for arbitrary precision arithmetic. How
| difficult do you think that might be?
| fouronnes3 wrote:
| Thanks! Arbitrary precision arithmetic is definitely something
| I'd like to learn more about, yeah. Haven't had time to study
| it so much yet unfortunately.
| mike-the-mikado wrote:
| I recently implemented something somewhat similar, but from the
| perspective of set membership.
|
| 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.
| adaptit wrote:
| This interval calculator is surprisingly robust. The way it
| handles boundary conditions and asymmetric intervals is clean and
| efficient.
| i_love_retros wrote:
| Thank you for creating and sharing something that feels authentic
| and human made. No sign of AI vibe coded slop at all. It's
| beautiful.
| malcolmjuxt wrote:
| I wish I had known about interval arithmetic when I first wrote
| tick, a time interval library in Clojure, which includes a.
| implementation of Allen's Interval Algebra. It also embraces the
| notion of sets of discrete intervals which are useful for
| practical work calculations, like determining the set of
| intervals of your vacations that are in a particular year (for HR
| calculations). I accidentally stumbled on benefits of these sets
| without knowing much beyond Allen's work.
|
| https://github.com/juxt/tick
|
| https://en.wikipedia.org/wiki/Allen's_interval_algebra
| SkiFire13 wrote:
| Expanding the logic to union of intervals looks cool, but what is
| the complexity of that? Since you introduce the the possibility
| of an operation on an interval producing two intervals I suspect
| executing N operations might have an exponential complexity,
| which unfortunately makes this unfeasible to use for some common
| intervals applciations like abstract interpretation, unless you
| start introducing approximations once you have enough intervals.
| lou1306 wrote:
| Yes, this is well-known (eg. in abstract interpretation). As
| you said, usually you can set a "cap" to the size of these
| objects, and start merging intervals when you hit the cap. But
| at least in abstract interpretation it seems that they simply
| consider more sophisticated domains than intervals.
| mbo wrote:
| Could this support a native datetime type? I shipped a much worse
| of this for managing repeated events and schedules.
| zamadatix wrote:
| Naively, what breaks by doing datetime -> epoch -> interval ->
| datetime over some other form of implementation?
|
| I tend to avoid datetimes as much as working with printers
| because the answer is always "more annoying than you'd first
| think" :D.
| lou1306 wrote:
| Sorry to be a party pooper, the Web app is neat, but I have some
| reservations about the paper.
|
| 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 File 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
| wvlia5 wrote:
| Hey, what about this idea? redefine interval representation, such
| that [a, b] means the same if a<b; but if b<a, it means [-[?],
| b]U[a, +[?]]. Then your example would become 1/[-1,2]=[0.5,-1]
| fouronnes3 wrote:
| That's a very cool idea :) It was proposed as far back as 1968
| (!) in a paper by none other than the legend of floating point
| himself: Wiliam Kahan
| https://interval.louisiana.edu/historical-preprints/1968-Kah...
| Eric_Xua wrote:
| Really cool project--turning interval unions into a usable,
| polished calculator makes the math feel practical.
| jakeinspace wrote:
| This is great
| roger_ wrote:
| I can see valid uses of this but I also feel like a probabilistic
| calculator would be more useful.
|
| 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).
| Falimonda wrote:
| Random example generator would be nice
| oncallthrow wrote:
| have you considered implementing a +- operator?
|
| For example a +- b would be [a - b, a + b]
| librasteve wrote:
| That's neat ... I wrote a simple Math::Interval library in Raku
| https://github.com/librasteve/raku-Math-Interval
|
| This is based Raku's built-in Junction and Range classes and was
| an interesting experiment.
___________________________________________________________________
(page generated 2026-04-18 23:01 UTC)