ANN: Unum 4.0 beta

[Pierre Denis]

Unum 4.0 beta is now available on http://home.tiscali.be/be052320/Unum.html.

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

 

[John Benson]

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" <[email protected]>
To: <[email protected]>
Sent: Sunday, November 16, 2003 12:18 PM
Subject: ANN: Unum 4.0 beta

Unum 4.0 beta is now available on http://home.tiscali.be/be052320/Unum.html.

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

 

[Pierre Denis]

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.

Pierre

 

[Tim Roberts]

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!

Right. Algebra would have told you this:

(a-1)**2 + (a+1)**2 = a**2 - 2a + 1 + a**2 + 2a + 1 = 2a**2 + 2

Divide that by two, and you get a**2 + 1.

But what about the discrepancy between 100 and 101?

The discrepancy is that you chose to take the center of the range as the
"most representative value". There is no mathematical basis for that
decision.

What you're talking about here is interval arithmetic. Although it is
useful for working with approximate measurements, it actually increases the
precision of your knowledge. For example, we KNOW that the actual area is
in the interval [81,121]. We do NOT know what the exact area is, or even
what the best estimate is, and there is no analytical method for extracting
that information from the interval.