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.
Uncertain
41–50 of 101 posts
Re: Uncertain<T>
#42This 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…
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.
Re: Uncertain<T>
#43oh man i had forgotten about this blog from when i orbited the swift ecosystem a bit... it's clearly as great as always! fun post!
Re: Uncertain<T>
#44for 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"
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.
Re: Uncertain<T>
#45Seems more proper to call it a `ProbabilityDistribution` type. It's a more general and intuitive way to handle the concept.
Re: Uncertain<T>
#46Earlier quoted context omitted.
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"
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.
If a test procedure is verifying all dimensional accuracy, it can be assumed to be bounding tolerance. If it's a mass production line with less than 100% testing of parts, you'd have to expect that some outliers get by and the tolerance is something like 3-sigma on a Gaussian.
Re: Uncertain<T>
#47This 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.
Re: Uncertain<T>
#48Seems more proper to call it a `ProbabilityDistribution` type. It's a more general and intuitive way to handle the concept.
Yeah but the shorter name wins
Re: Uncertain<T>
#49IS there the complete C# available for this? I looked over the original paper and it's just snippets.
Re: Uncertain<T>
#50This 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.