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

81–90 of 101 posts

Re: Uncertain<T>

#81

Post by jjcob »

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…

In physics, you typically learn about error propagation quite early in your studies.

If you make some assumptions about your error (a popular one is to assume Gaussian distribution) then you can calculate the error of the result quite elegantly.

It's a nice excercise to write some custom C++ types that have (value, error) and automatically propagate them as you perform mathematical operations on them.

Unfortunately, in the real world only very few measurements have a gaussian error distribution, and the problem are systematic (non-random) errors, and reasoning about them is a lot harder.

So this means that automatically handling error propagation is in most cases pointless, since you need to manually analyze the situation anyway.

Re: Uncertain<T>

#82

Post by flaghacker »

boscillator wrote: post #3

Does this handle covariance between different variables? For example, the location of the object your measuring your distance to presumably also has some error in it's position, which may be correlated with your position (if, for example, if it comes from another GPS operating at a similar time). Certainly a univarient model in the type system could be useful, but it would be extra powerful (and more correct) if it c…

Using this sampling-based approach you get correct covariance modeling for free. You have to only sample leaf values that are used in multiple places once per evaluation, but it looks like they do just that: https://github.com/mattt/Uncertain/blob/962d4cc802a2b179685d...

Re: Uncertain<T>

#83

Post by thekoma »

We designed a processor microarchitecture [1] at the University of Cambridge, inspired by Uncertain (James Bornholt) and related work. In addition to assuming parametric distributions (e.g., Gaussian, Rayleigh), it lets you load arbitrary sets of samples into registers/memory so program values are carried and propagated as nonparametric distributions through ordinary arithmetic.

A spin-off, Signaloid, is taking this technology to market. I'm also researching using this in state estimation (e.g., particle filters).

[1]: https://dl.acm.org/doi/10.1145/3466752.3480131

Re: Uncertain<T>

#84

Post by mauvehaus »

mikepurvis wrote: post #17
AlotOfReading wrote: post #8

A small note, but GPS is only well-approximated by a circular uncertainty in specific conditions, usually open sky and long-time fixes. The full uncertainty model is much more complicated, hence the profusion of ways to measure error. This becomes important in many of the same situations that would lead you to stop treating the fix as a point location in the first place. To give a concrete example, autonomous vehicle…

Vehicle GPS is usually augmented by a lot of additional sensors and assumptions, notably the speedometer, compass, and knowledge the you'll be on one of the roads marked on its map. Not to mention a fast fix because you can assume you haven't changed position since you last powered on.

And yet, sometimes driving down a divided, limited access highway, Apple/Google/whatever maps will suddenly start giving directions from whatever parallel dirt road I happen to be driving next to. As though there's a situation where I left the highway at highway speed, crossing a ditch, crushing a fence, and possibly smashing through a guard rail, and am now traveling 65mph/100kph down a dirt road.

Re: Uncertain<T>

#85

Post by mauvehaus »

blauditore wrote: post #80
mikepurvis wrote: post #17

Earlier quoted context omitted.

Vehicle GPS is usually augmented by a lot of additional sensors and assumptions, notably the speedometer, compass, and knowledge the you'll be on one of the roads marked on its map. Not to mention a fast fix because you can assume you haven't changed position since you last powered on.

> assume you haven't changed position since you last powered on Sounds like a classic case of programmers ignoring corner cases: Towing, ferries, car trains, pushing the car because it broke down... It's when you find messages in the log like "this should never happen".

You can pretty clearly use it to correct errors up to a point though. If you have a 5km difference from when the GPS was turned off, you've probably hit a corner case. If you have a 25m difference, and it's converging on the last location as you pick up satellites, snapping to the prior location is almost certainly correct.

Re: Uncertain<T>

#86

Post by Davidbrcz »

btown wrote: post #56

Once one understands that a variable (in a programming context) can hold a specification for a variable (in a mathematical context), one opens up incredible doors that are at the foundation of modern AI. When you see y = m * x + b, your recollections of math class may note that you can easily solve for "m" or find a regression for "m" and "b" given various data points. But from a programming perspective, if these are…

Congrats, you have just reinvented the monad

Re: Uncertain<T>

#88

Post by esrauch »

rendaw wrote: post #70
kccqzy wrote: post #37

Earlier quoted context omitted.

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). I…

While it does sound like GP missed a distinction, I don't see how (-2.35, 2.35) would be sensible. The extremes can happen (or else they wouldn't be part of the input intervals) and the code has to sensibly deal with that event in order to be correct.

The reason is that the uniform distribution is very rare. Nearly no real world scenario were something is equally likely to be the values 2, 0 and -2, and where it's literally impossible to be -2.01. It exists but it's not the normal case.

In noisy sensors case there's some arbitrary low probability of them being actually super wrong, if you go by true 10^-10 outlier bounds they will be useless for any practical use, while the 99% confidence range is a relatively small rent.

More often you want some other distribution and say (-2, 2) and those are the 90th percentile interval not the absolute bounds, 0 is more likely than -2 and -3 is possible but rare. It's not bounds, you can ask you model for your 99th or 99.9th percentile value or whatever tolerance you want and get something outside of (-2,2).

Re: Uncertain<T>

#89

Post by kccqzy »

rendaw wrote: post #70
kccqzy wrote: post #37

Earlier quoted context omitted.

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). I…

While it does sound like GP missed a distinction, I don't see how (-2.35, 2.35) would be sensible. The extremes can happen (or else they wouldn't be part of the input intervals) and the code has to sensibly deal with that event in order to be correct.

Interval arithmetic isn't useful because it only tells you the extreme values, but not how likely these values are. So you have to interpret them as uniform random. Operations like multiplications change the shape of these distributions, so then uniform random isn't applicable any more. Therefore interval arithmetic basically has an undefined underlying distribution that can change easily without being tracked.

Re: Uncertain<T>

#90

Post by brabel »

mabster wrote: post #75
taneq wrote: post #44

Earlier quoted context omitted.

I don’t think I’ve ever seen mechanical drawings have “90% confidence” dimensions like this. If a part’s too big then it won’t fit, and it’s probably useless.

Yeah it's probably field specific and I guess Gaussian-based uncertainty would be more about statistical sampling rather than tolerances. I've noticed that if arithmetic is being done on it it's almost certainly Gaussian. I just mean whenever I see uncertainty like this, I don't know what is meant!

In Mechanical Engineering, tolerances ensure that when you put parts together, they will fit as long as the tolerances were respected.

It's not statistical. If the machinist makes a part that's not within the +/- bounds, they throw it away and start again. If you tried to fit multiple parts, all with only statistical respect for tolerances, you would run into trouble almost 100% of the time with just a few pieces.

Post reply on HN