Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uncertain

nshipster.com

Post reply on HN
Print view View original

31–40 of 101 posts

Re: Uncertain<T>

#31

Post by rictic »

nine_k wrote: post #21
layer8 wrote: post #10

Arguably Uncertain should be the default, and you should have to annotate a type as certain T when you are really certain. ;)

Only for physical measurements. For things like money, you should be pretty certain, often down to exact fractional cents. It appears that a similar approach is implemented in some modern Fortran libraries.

A person might have mistyped a price, a barcode may have been misread, the unit prices might be correct but the quantity could be mistaken. Modeling uncertainty well isn't just about measurement error from sensors.

I wonder what it'd look like to propagate this kind of uncertainty around. You might want to check the user's input against a representative distribution to see if it's unusual and, depending on the cost of an error vs the friction of asking, double-check the input.

Re: Uncertain<T>

#32

Post by random3 »

nine_k wrote: post #21
layer8 wrote: post #10

Arguably Uncertain should be the default, and you should have to annotate a type as certain T when you are really certain. ;)

Only for physical measurements. For things like money, you should be pretty certain, often down to exact fractional cents. It appears that a similar approach is implemented in some modern Fortran libraries.

have you ever tried working computationally with money? Forget money, have you worked with floating points? There really isn't anything certain.

Re: Uncertain<T>

#33

Post by pklausler »

j2kun wrote: post #25

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…

Interval arithmetic makes good intuitive sense when the endpoints of the intervals can be represented exactly. Figuring out how to do that, however, is not obvious.

Re: Uncertain<T>

#34

Post by nine_k »

random3 wrote: post #32
nine_k wrote: post #21

Earlier quoted context omitted.

Only for physical measurements. For things like money, you should be pretty certain, often down to exact fractional cents. It appears that a similar approach is implemented in some modern Fortran libraries.

have you ever tried working computationally with money? Forget money, have you worked with floating points? There really isn't anything certain.

Yes, I worked in a billing department. No, floats are emphatically not suitable for representing money, except the very rounded values in presentations.

Floats try to keep the relative error at bay, so their absolute precision varies greatly. You need to sum them starting with the smallest magnitude, and do many other subtle tricks, to limit rounding errors.

Re: Uncertain<T>

#35

Post by [deleted] »

nicois wrote: post #27

Is there a risk that this will underemphasise some values when the source of error is not independent? For example, the ROI on financial instruments may be inversely correlated to the risk of losing your job. If you associate errors with each, then combine them in a way which loses this relationship, there will be problems.

[deleted]

Re: Uncertain<T>

#36

Post by bee_rider »

Tarean wrote: post #26
j2kun wrote: post #25

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…

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 ca…

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.”

Re: Uncertain<T>

#37

Post by kccqzy »

j2kun wrote: post #25

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…

The article says,

> Under the hood, Uncertain models GPS uncertainty using a Rayleigh distribution.

And the Rayleigh distribution is clearly not just an interval with a uniformly random distribution in between. Normal interval arithmetic isn't useful because that uniform random distribution isn't at all a good model for the real world.

Take for example that Boost library you linked. Ask it to compute (-2,2)*(-2,2). It will give (-4,4). A more sensible result might be something like (-2.35, 2.35). The -4 lower bound is only attainable when you have -2 and 2 as the multiplicands which are at the extremes of the interval; probabilistically if we assume these are independent random variables then two of them achieving this extreme value simultaneously should have an even lower probability.

Re: Uncertain<T>

#40

Post by mabster »

8note wrote: post #20

for mechanical engineering drawings to communicate with machinists and the like, we use tolerances eg. 10cm +8mm/-3mm for what the acceptable range is, both bigger and smaller. id expect something like "are we there yet" referencing GPS should understand the direction of the error and what directions of uncertainty are better or worse

Something that's bugged me about this notation though is that sometimes it means "cannot exceed the bounds" and sometimes it means "only exceeds the bounds 10% of the time"
Post reply on HN