Uncertain<T>

Arguably Uncertain should be the default, and you should have to annotate a type as certain T when you are really certain. ;)

A complement to Optional.

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.

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

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.

have you ever tried working computationally with money? Forget money, have you worked with floating points? There really isn't anything certain.

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.

Typos seem like a different type of error from physical tolerances, and one that would be really hard to reason about mathematically.

> For things like money, you should be pretty certain, often down to exact fractional cents.

That's one way to look at it.

Another is that Money is certain only at the point of exchange.

> It appears that a similar approach is implemented in some modern Fortran libraries.

I'd be curious about that. Do you have a link?