Not sure how possible this is, but a #![no_std] option seems potentially useful. Could allow you to make more accurate sensor readings in IoT networks by taking into account local variances to decide measurement tolerances (like reading pressure or temp to determine the accuracy of other readings the device could do).

That way your receiver that processes off the info doesn't have to do an educated guess on the tolerances per device (because you might have different sensors with different tolerances), it'd instead be encoded in the data stream for it to parse.

Blog post on the technique: https://www.possiblerust.com/pattern/3-things-to-try-when-you-can-t-make-a-trait-object

pros:

• get back the pr_with method

cons:

• need to do more dynamic dispatch which is potential expensive

It might be interesting to offer evaluation of expectations for uncertain values which are floating point values.

There are a few questions around how to best do that:

• Should sample count be fixed?
• Should the variance be reported?
• Fixed sample count or convergence measure to stop sampling early?
• Restrict to Float, or also allow integers(?), or maybe go completely different route with Into<f64>
• Can we make the evaluation cheap enough such that it can be used e.g. in async contexts without worrying about blocking (like you can pr)?
• Built in multi threading? (Probably not, most Uncertain values are Send, but they are not sync, also I think it's better to give control over threading to user: can send value to other thread if they want to)

Proposed API

fn get_value() -> impl Uncertain<Value = f64>;
let x = get_value();
let expected_value = x.expectation(); // should ideally be cheap to run (!)
// or maybe
let expected_value = x.expect();
let expected_value = x.e(); // short like `pr`? probably not -> it's more expensive, so should not be easy to miss the call

The contract for epoch caching is confusing, and most values that are e.g. returned from sensors should probably implement Clone.

Implementing Distribution is easier, more compatible with other crates, and allows us to guarantee that computations are always correct, even if foreign types are used.

Apparently, the wyhash RNG is a lot faster than PCG. It might be worth to add some benchmarks and see if using this algorithm improves performance.