_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Uncertain<T>
lxe wrote 24 min ago:
I really like that this leans on computing probabilities instead of
forcing everything into closed-form math or classical probability
exercises. Iâve always found it way more intuitive to simulate,
sample, and work directly with distributions. With a computer, it feels
much more natural to uh... compute: you just run the process, look at
the results, and reason from there.
contravariant wrote 43 min ago:
I feel like if you're worried about picking the right abstraction then
this is almost certainly the wrong one.
lloydatkinson wrote 1 hour 9 min ago:
IS there the complete C# available for this? I looked over the original
paper and it's just snippets.
tricky_theclown wrote 1 hour 54 min ago:
S
nicois wrote 1 hour 59 min ago:
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.
j2kun wrote 2 hours 15 min ago:
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]
URI [1]: https://www.boost.org/doc/libs/1_89_0/libs/numeric/interval/do...
URI [2]: https://arblib.org/
anal_reactor wrote 16 min ago:
Because reasoning about uncertain values / random variables /
intervals / fuzzy logic / whatever is difficult and the model where
things are certain is much easier to process while it models the
reality well enough.
kccqzy wrote 1 hour 18 min ago:
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.
pklausler wrote 1 hour 37 min ago:
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.
Tarean wrote 2 hours 5 min ago:
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.
bee_rider wrote 1 hour 28 min ago:
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.â
droideqa wrote 2 hours 24 min ago:
Could this be implemented in Rust or Clojure?
Does Anglican kind of do this?
black_knight wrote 2 hours 28 min ago:
This seems closely related to this classic Functional Pearl: [1] Itâs
so cool!
I always start my introductory course on Haskell with a demo of the
Monty Hall problem with the probability monad and using rationals to
get the exact probability of winning using the two strategies as a
fraction.
URI [1]: https://web.engr.oregonstate.edu/~erwig/papers/PFP_JFP06.pdf
cb321 wrote 2 hours 39 min ago:
If you are in an even more "approximate" mindset (as opposed to
propagating by simulation to get real world re-sampled skewed
distributions, as often happens in experimental physics labs, or at
least their undergraduate courses), there is an error propagation ( [1]
) simplification for "small" errors thing you can do. Then translating
"root" errors to "downstream errors" is just simple chain rule calculus
stuff. (There is a Nim library for that at [2] that I use at least
every week or two - whenever I'm timing anything.)
It usually takes some "finesse" to get your data / measurements into
territory where the errors are even small in the first place. So, I
think it is probably better to do things like this Uncertain for the
kinds of long/fat/heavy tailed and oddly shaped distributions that
occur in real world data { IF the expense doesn't get in your way some
other way, that is, as per Senior Engineer in the article }.
URI [1]: https://en.wikipedia.org/wiki/Propagation_of_uncertainty
URI [2]: https://github.com/SciNim/Measuremancer
8note wrote 2 hours 52 min ago:
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
mabster wrote 36 min ago:
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"
krukah wrote 3 hours 21 min ago:
Monads are really undefeated. This particular application feels to me
akin to wavefunction evolution? Density matrices as probability monads
over Hilbert space, with unitary evolution as bind,
measurement/collapse as pure/return. I guess everything just seems to
rhyme under a category theory lens.
valcron1000 wrote 3 hours 2 min ago:
Relevant (2006):
URI [1]: https://web.engr.oregonstate.edu/~erwig/pfp/
munchler wrote 3 hours 22 min ago:
Is this essentially a programmatic version of fuzzy logic?
URI [1]: https://en.wikipedia.org/wiki/Fuzzy_logic
esafak wrote 3 hours 11 min ago:
[1] more like. It is already a thing; see, for example,
URI [1]: https://en.wikipedia.org/wiki/Probabilistic_programming
URI [2]: https://pyro.ai/
layer8 wrote 3 hours 40 min ago:
Arguably Uncertain should be the default, and you should have to
annotate a type as certain T when you are really certain. ;)
nine_k wrote 2 hours 42 min ago:
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.
random3 wrote 1 hour 41 min ago:
have you ever tried working computationally with money? Forget
money, have you worked with floating points? There really isn't
anything certain.
nine_k wrote 1 hour 37 min ago:
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.
rictic wrote 1 hour 49 min ago:
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.
XorNot wrote 1 hour 57 min ago:
Money has the problem that no matter how clever you are someone
will punch all the values into Excel and then complain they don't
match.
Or specify they're paying X per day, but want hourly itemized
billing...but it should definitely come out to X per day (this was
one employer which meant I invoiced them with like 8 digits of
precision due to how it divided, and they refused to accept a line
item for mathematical uncertainty aggregates).
esafak wrote 3 hours 12 min ago:
A complement to Optional.
AlotOfReading wrote 3 hours 48 min ago:
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 vehicles will encounter situations where localization
uncertainty is dominated by non-circular multipath effects.
If you go down this road far enough you eventually end up reinventing
particle filters and similar.
mikepurvis wrote 3 hours 3 min ago:
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.
monocasa wrote 1 hour 50 min ago:
As well as a fast fix because you know what mobile cell or wifi
network you're on.
jakubmazanec wrote 4 hours 19 min ago:
[flagged]
muxl wrote 3 hours 47 min ago:
It was chosen to be implemented as a generic type in this design
because the way that uncertainty "pollutes" underlying values maps
well onto monads which were expressed through generics in this case.
geocar wrote 4 hours 2 min ago:
> What if I want Bayesian?
Bayes is mentioned on page 46.
> And why does it need to be part of the type system? It could be
just a library.
It is a library that defines a type.
It is not a new type system, or an extension to any particularly
complicated type system.
> Am I missing something?
Did you read it? [1]
URI [1]: https://www.microsoft.com/en-us/research/wp-content/uploads/...
URI [2]: https://github.com/klipto/Uncertainty/
jakubmazanec wrote 3 hours 36 min ago:
> Bayes is mentioned on page 46.
Bayes isn't mentioned in the linked article. But thanks for the
links.
frizlab wrote 4 hours 10 min ago:
> And why does it need to be part of the type system?
As presented in the article, it is indeed just a library.
cobbal wrote 4 hours 10 min ago:
I don't think inference is part of this at all, frequentist or
otherwise.
It's not part of the type system, it's just the giry monad as a
library.
boscillator wrote 4 hours 27 min ago:
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 could handle
covariance.
evanb wrote 2 hours 59 min ago:
If you need to track covariance you might want to play with gvar [1]
in python.
URI [1]: https://gvar.readthedocs.io/en/latest/
layer8 wrote 3 hours 35 min ago:
To properly model quantum mechanics, youâd have to associate a
complex-valued wave function with any set of entangled variables you
might have.
mackross wrote 4 hours 31 min ago:
Always enjoy matttâs work. Looks like a great library.
DIR <- back to front page