Numeric dimensions, units ,etc. Was: Re: I had a thought ... (I know, call the newspapers).

Bengt Richter bokr at accessone.com
Wed Jun 6 12:24:35 EDT 2001


On Wed, 06 Jun 2001 17:47:07 +1200, Greg Ewing
<greg at cosc.canterbury.ac.nz> wrote:

>David LeBlanc wrote:
>> 
>> Currency might be a comfortable metaphor for people,
>> especially accounting types who probably think a number is naked without
>> a currency symbol.
>
>But you need *some* numbers other than currency.
>If I buy 3 widgets at $1.23 each I'm spending
>3 * $1.23, not $3 * $1.23, which would give a
>result in square dollars.
>
>I don't know what square dollars look like,
>but I'm sure my bank wouldn't accept them...
>
You put your finger on an interesting aspect of numeric
quantity representation and computing. Here's a questing
and a few thoughts OTTOMH:

Has anyone built a class to deal systematically with this
and related issues? I have in mind a kind of quantity class
with an abstract value as a pure number, plus associated
dimension and unit ids (e.g., 'distance' and 'meters', or
'currency' and 'USD'), and some kind of precision/accurancy
representation specification and control mechanism that
could support a q.IsAccurate(srep) boolean-returning method
that could be used in assertions.

The idea would be to be able to assert that a string representation
of the class instance value was accurate within the criteria
specified when quantity instances were created. I am thinking this
could support writing a validate test for a program meant to deal
with defined ranges of legal values and output formats for same.

I would guess that you might need interval arithmetic of some kind to
represent the guaranteed value ranges of the abstract pure number
values, and for operations on them, to do this is a bullet proof way.

I suppose dimensions and units could be carried as tuples, e.g.,
( ('distance' 'meters' 1) ('time' 'seconds' -2) ) for acceleration.

If you ordered the tuple elements in a canonical way, you should
then potentially be able to write space-probe-saving assertions ;-)





More information about the Python-list mailing list