←back to thread

Uncertain<T>

(nshipster.com)
444 points samtheprogram | 2 comments | | HN request time: 0.001s | source
Show context
j2kun ◴[] No.45056827[source]
This concept has been done many times in the past, under the name "interval arithmetic." Boost has it [1] as does flint [2]

What is really curious is why, after being reinvented so many times, it is not more mainstream. I would love to talk to people who have tried using it in production and then decided it was a bad idea (if they exist).

[1]: https://www.boost.org/doc/libs/1_89_0/libs/numeric/interval/... [2]: https://arblib.org/

replies(8): >>45056929 #>>45057194 #>>45057366 #>>45057865 #>>45058239 #>>45058375 #>>45058723 #>>45062336 #
Tarean ◴[] No.45056929[source]
Interval arithmetic is only a constant factor slower but may simplify at every step. For every operation over numbers there is a unique most precise equivalent op over intervals, because there's a Galois connection. But just because there is a most precise way to represent a set of numbers as an interval doesn't mean the representation is precise.

A computation graph which gets sampled like here is much slower but can be accurate. You don't need an abstract domain which loses precision at every step.

replies(1): >>45057275 #
1. bee_rider ◴[] No.45057275[source]
It would have been sort of interesting if we’d gone down the road of often using interval arithmetic. Constant factor slower, but also the operations are independent. So if it was the conventional way of handling non-integer numbers, I guess we’d have hardware acceleration by now to do it in parallel “for free.”
replies(1): >>45059122 #
2. eru ◴[] No.45059122[source]
You can probably get the parallelism for interval arithmetic today? Though it would probably require a bit of effort and not be completely free.

On the CPU you probably get implicit parallel execution with pipelines and re-ordering etc, and on the GPU you can set up something similar.