IS there the complete C# available for this? I looked over the original paper and it's just snippets.
https://github.com/klipto/uncertainty
10 years since commit and no attached documents besides a tiny readme. Pass.
Uncertain
51–60 of 101 posts
Re: Uncertain<T>
#52This 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…
Not sure why this is being upvoted as the article is not describing interval arithmetic. It supports all kinds of uncertainty distributions.
Re: Uncertain<T>
#53Earlier 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.
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 o…
Typos seem like a different type of error from physical tolerances, and one that would be really hard to reason about mathematically.
Re: Uncertain<T>
#54Seems more proper to call it a `ProbabilityDistribution` type. It's a more general and intuitive way to handle the concept.
But the pun, uncertainty.
Re: Uncertain<T>
#55This 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…
Several years ago when I discovered some of the historical work on interval arithmetic, I was astounded to find that there was a notable contingent in the 60s that was urging hardware developers to make interval arithmetic be the basic design of new CPUs, and saying quite forcefully that if we simply went with "normal" integers and floating point, we'd be unable to correctly model the world.
I think as another commenter pointed out, interval arithmetic’s problem is that while it acknowledges the reality of uncertainty, its model of uncertainty is so simplistic, in many applications it is unusable. So making it the standard primitive, could potentially result in the situation where apps that don’t need to explicitly model uncertainty at all have to pay the price of being forced to do so; meanwhile, apps which need a more realistic model of uncertainty are being forced to do so while being hamstrung by its interactions with another overly simple model. It is one of those ideas which sounds great in theory, but there are good reasons it never succeeded in practice-the space of use cases where explicitly modelling uncertainty is desirable, but where the simplistic model of interval arithmetic is entirely adequate, is rather small-a standard primitive which only addresses the needs of a narrow subset of use cases is not a good architecture
Re: Uncertain<T>
#56Once 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 all literal values, all this is is a "render" function. How can you reverse an arbitrary render function?
There are various approaches, depending on how Bayesian you want to be, but they boil down to: if your language supports redefining operators based on the types of the variables, and you have your variables contain a full specification of the subgraphs of computations that lead to them... you can create systems that can simultaneously do "forward passes" by rendering the relationships, and "backward passes" where the system can automatically calculate a gradient/derivative and thus allow a training system to "nudge" the likeliest values of variables in the right direction. By sampling these outputs, in a mathematically sound way, you get the weights that form a model.
Every layer in a deep neural network is specified in this way. Because of the composability of these operations, systems like PyTorch can compile incredibly optimal instructions for any combination of layers you can think of, just by specifying the forward-pass relationships.
So Uncertain is just the tip of the iceberg. I'd recommend that everyone experiment with the idea that a numeric variable might be defined by metadata about its potential values at any given time, and that you can manipulate that metadata as easily as adding `a + b` in your favorite programming language.
Re: Uncertain<T>
#57This 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…
Using simple types (booleans etc) is very simple and easy to reason about, and any shortcomings are obvious. Trying to model physical uncertainty is difficult and requires different models for different domains. Once you have committed to needing to do that, it would be much better to use a purpose built model instead of a library which put some bell curves behind a pretty API.
I agree that different application strictly speaking need different models of uncertainty.
But I'm not so sure in your conclusion: a good enough model could be universally useful. See how everyone uses IEEE 754 floats, despite them giving effectively one very specific model of uncertainty. Most of the time this just works, and sometimes people have to explicitly work around floats' weirdnesses (whether that's because they carefully planned ahead because they know what they are doing, or whether they got a nasty surprise first). But overall they are still useful enough to be used almost universally.
Re: Uncertain<T>
#58Earlier quoted context omitted.
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.”
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.
Re: Uncertain<T>
#59This 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.
Also not all uncertainties are modeled well by uniform distributions over an interval.
Re: Uncertain<T>
#60for 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
Or for something likely relevant to many here - 3 point time estimates for project planning.
Probability distributions (even very simple ones) provide a much clearer view across any domain where there’s inherent uncertainty.