RE: [Axiom-developer] Unit package question

[Bill Page]

Here are few initial ideas about how I think units might
be implemented in Axiom.

On August 19, 2005 4:56 PM C Y wrote:

> Hi all.  I have a rather odd question, and I don't know if
> this is something Axiom even will permit, but it would be
> useful to know, so...
>
> I want to be able to teach Axiom how to use units.

For scientific applications of Axiom, I think units might be
very useful. My first reaction however is to try to imagine
what part of Axiom might be most suitable to represent the
concept of units.

> There are a number of surprisingly annoying features to handle
> based on my experience with Maxima, and one of the worst is
> the following:
>
> If I enter an expression, Axiom automatically formats it and
> orders it according to internal rules.  See
http://www.axiom-developer.org/zope/mathaction/SandBox#msg20050819154916
address@hidden

> for an example of this.  Normally, this is what one wants to do.

I think what you are doing here is ok in Maxima, Maple and
Mathematica but it does not fit well in Axiom. I think it might
be quite awkward to treat units as expressions of this kind in
Axiom.

> What I'm not sure of is how to instruct Axiom to display things
> that are Units at the end of an expression, e.g.
>
>         kg*m
> a*b*z  ------
>           2
>          s

What makes Axiom different is it's strong type system and it's
object-orientation. To me this suggests that units in Axiom
might be best implemented as extensions of the Float domain.
By this I mean we should be able to write something like this:

(1) ->  (2.0::kg + 1.0::lb)::ton

   (1)  0.0027
                      Type: ton

where kg, lb and ton are Axiom domains. Given the right
definitions of these domains we should expect that Axiom would
perform the necessary coercion/conversion from the domains
kg and lb to ton, the same as if we had written:

(2) -> (2.0::Float + 1.0::INT)::SF

   (2)  3.0
                      Type: DoubleFloat

To implement something like:

(3) -> 2.0::m * 3.1::kg

          6.1
                      Type: m*kg

Axiom will have to be told how to multiply meters by kilograms.
This is easily done given Axiom function overloading. Add of
course Axiom needs to know how to construct new units (types)
from old ones. Since types are first order objects in Axiom,
this is also quite easy.

> In Maxima it requires some rather alarming hackery with the
> display code to avoid the same default behavior Maxima exhibits.
> In one sense Axiom is an ideal place for certain types of unit
> operations, since I can presumably do things like assign both
> inches and meters the type Length, and assign simplification
> rules accordingly :-).

Perhaps you are confusing the notion of 'dimension' and 'unit'
here but still I think these ideas both map quite well to
Axiom's type system. For example

(4) -> 1.0::m + 2.0::s

would constitue a type error.

> but I don't know how to impliment the display logic above.
> Based on the Maxima experience, I'm guessing the infastructure
> might not be in place to support something like this, given
> it is rather non-standard in normal mathematical environments.

The display of units as types, e.g.

                      Type: m*kg

should be possible, although I think there my currently be
some built-in assumptions about type expressions that might
currently preclude this nice infix notation. But a type such
as

                      Type: Prod(m,kg)

is certainly possible.

> Is there anybody who knows what the correct approach to this
> would be?

Maple has an elaborate Scientific units and dimension system
that even takes advantage of overloading operations like + * /
such as I suggested above, although Maple does not really have
the notion of strong typing. If you have the opportunity to study
how this was done in Maple perhaps it will suggest a possible
approach in Axiom.

These are just some rough initial ideas. I am not sure how
well this concept of "units as types" will work out in
detail.

Regards,
Bill Page.