question about precision of arithmetic involving empirical, measured quantities Re: Unum 4.0 beta

Pierre Denis Pierre-et-Liliane.DENIS at
Tue Nov 18 21:53:55 CET 2003

This issue of approximate quantities, as you describe it, is not addressed by Unum.

I fully agree that this is an important, under-estimated -or even ignored- problem. I think it is not, in essence, a problem
specific to quantities or units; it happens for any operation on any numbers (or other mathematical entities) with uncertainties,
for instance if you square PI, approximated in a floating-point variable. Unum focus on unit consistency, not on uncertainty
calculation or error propagation, which deserves deeper mathematical analysis.

Of course, your example is disturbing. Actually, I am not sure about what should be the most sensible answer. I have the feeling
that it is neither 100 [m2] nor 101 [m2]. It firstly depends on how you model the error probability distribution. Is it a uniform
distribution from 9 [m] to 11 [m] or, most likely, a Gaussian function centered on 10 [m] ? Even, if you take the simpler uniform
distribution, the problem is not obvious : if you represent your possible input values on two-axis system, the 'input space' is a
square (9[m],9[m])-> (11[m],11[m]), with each point representing equiprobable input value couple (x,y). Then each possible solution
S, from 81 [m2] to 121 [m2], corresponds to a hyporbola curve having the equation x.y = S. From here, I think the most sensible
result S° should be the one such that there is 50% of the input points x.y > S° and 50 % such that x.y < S° (strict equality is
negligible for continouous variables). This requires some integral calculation and I don't dare to go further here... I presume that
mathematicians have already calculate the answer to this.

In any case, in this specific case, the uncertainty of the results decreases as the uncertainties of the input decrease. Such
'numerical stablity' is assumed (maybe wrongly) in most calculations so people usually do not care.


John Benson <jsbenson at> a écrit dans le message : mailman.806.1069094367.702.python-list at
> Will this package handle approximate quantities, too?
> Here's some background for the question:
> Let's say you have measured the side of a square area to be 10 meters, +/- 1
> meter. We want to compute the area of the square.
> We are squaring a range of 9 to 11 meters, and get a resulting area range of
> 81 to 121 square meters. If we take the midpoint of this range as the most
> representative value, we end up with (81 + 121)/2 or 101 square meters,
> plus-or-minus 20 square meters! I seem to recall some rule that in a
> multiplication, the total uncertainty is the sum of the quotients
> (multiplicand/uncertainty of multiplicand) over all multiplicands. By this
> rule, the total uncertainty then would compute as (10/1) * (10/1) or twenty
> square meters, as we reckoned by explicit range calculation. But what about
> the discrepancy between 100 and 101?
> Whenever arithmetic is done involving things like volts and m/sec (as
> opposed to apples, bananas and people), you necessarily end up with problems
> like this. However, I got through a few years of college physics and
> chemistry without anyone ever worrying about the real uncertainties, beyond
> the simple "significant figures" approach for multiplication and the
> comparative precision approach for addition.
> ----- Original Message -----
> From: "Pierre Denis" <Pierre-et-Liliane.DENIS at>
> To: <python-list at>
> Sent: Sunday, November 16, 2003 12:18 PM
> Subject: ANN: Unum 4.0 beta
> > Unum 4.0 beta is now available on
> >
> > This Python module allows you to work with units like volts, hours,
> meter-per-second or dollars-per-spam. So you can play with true
> > quantities (called 'unums') instead of simple numbers. Consistency between
> units is checked at each expression evaluation and an
> > exception is raised when something is wrong, for instance, when trying to
> add apples to bananas. Unit conversion and unit output
> > formatting are performed automatically when needed. The main goals are to
> avoid unit errors in your calculations and to make unit
> > output formatting easy and uniform.
> >
> > This new version encompasses all the SI units and allows you to define
> your own libraries of units, with specific names and symbols.
> > Other improvements makes this version more solid : compatibility with
> NumPy, packages, misc optimizations, true exceptions,
> > new-style class, static methods, etc. The installation also should be
> easier and more standard through installation files. The site
> > and tutorial page have been updated to give more accurate information.
> >
> > This 4.0-beta version is stable, fairly. The term 'beta' essentially means
> that problems may potentially occur at installation on
> > specific OS. I made successful installation tests on Windows 98, XP and
> Red Hat Linux 7.2. Besides this, the choices I made for unit
> > names and symbols are subject to change if I receive more sensible
> suggestions. Of course, any other ideas, comments or criticisms
> > are welcome before releasing the official Unum 4.0 (no planning yet).
> >
> > This version requires Python 2.2 (at least).
> >
> > The license is GPL.
> >
> > Thanks for your interest,
> >
> > Pierre Denis
> >
> >
> >
> >
> >
> >

More information about the Python-list mailing list