Error margins

[raprism]

(11-09-2024 09:05 PM)c3d Wrote:  Interesting. A related idea is "inverval arithmetic". The basic idea is to have arithmetic on intervals Low...High, where you do computations on Low rounding down, and on High rounding up.

Getting this right is quite difficult. Consider something as simple as the sin() function. Internally, this is implemented with a number of alternating additions and subtractions, and depending on the sign, figuring out how you need to setup your rounding is not a trivial problem. Also, since these functions are periodic, as soon as the input interval is wider than 2π, the only valid output is -1...1 which is not super useful. Digit cancellation is problematic. And so on.

There is a reason error analysis in real life is hard ;-)

Packages for RPN x42 (uprop, see above), Python (uncertainties), Julia (Measurements.jl) are using same assumptions and simplifications as described in "Guide to the Expression of Uncertainty in Measurement" (GUM) and shortly summarized in https://en.wikipedia.org/wiki/Propagatio...lification.

Your comment on sin function is true. Some comments in uncertainties/umath_core.py are insightful:

Quote:########################################
# Wrapping of math functions:

# Fixed formulas for the derivatives of some functions from the math
# module (some functions might not be present in all version of
# Python). Singular points are not taken into account. The user
# should never give "large" uncertainties: problems could only appear
# if this assumption does not hold.

# Functions not mentioned in _fixed_derivatives have their derivatives
# calculated numerically.

# Functions that have singularities (possibly at infinity) benefit
# from analytical calculations (instead of the default numerical
# calculation) because their derivatives generally change very fast.
# Even slowly varying functions (e.g., abs()) yield more precise
# results when differentiated analytically, because of the loss of
# precision in numerical calculations.

(btw: sin is key of fixed_derivatives dictionary)

Because db48x supports derivation and different datatypes, it would be a question how to define a custom data type, if 'uprop' needs to be programmed with RPL.