--- Bill Page <address@hidden> wrote:
Here are few initial ideas about how I think units might
be implemented in Axiom.
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.
It's most likely non-trivial - I've got some digging to do into Axiom
programming philosophy. I'll try to describe what I had envisioned in
my mind's eye, and perhaps it will emerge what it would take to teach
Axiom to work with the new concepts.
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.
Possibly - I'm not really sure myself yet. But as I'll explain below
there are reasons for this approach.
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.
The logic of units certainly has some similarities, but one needs to be
careful because there are a fair number of unique options one would
want to have with units. I'm not sure, on closer analysis, that Floats
are really all that good a match. I'll try to give a couple examples
below.
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
The problem with this is there would have to be one type/domain for
EVERY SINGLE UNIT we wished to define. When one includes the metric
prefix system, this can include a LOT of types/domains. Conceptually, I
think it would be more elegant to have Axiom recognize a) a unit is in
an expression b) determine the dimension of each unit and confirm the
expression is dimensionally legal and c) depending on options return
either i) the unsimplified combination of legal terms ii) the
simplified expression according to a global set of user chosen standard
units (MKS by default) or iii) if non-basic dimensions like Force are
enabled, and an expression simplifies to such a dimensional type or a
combination of higher order types, simplify to the most compact form
available. Of course, this might not be at all elegant in Axiom as it
currently exists, but here's a mockup session of what I'd like to see:
(1) -> (2.0::kg + 1.0::lb)::kg
Error - incompatible dimensions for Add operation
(1) -> (2.0::kg + 1.0::slugs)::kg
(1) 3.45939 kg
Type: Mass
(2) -> (2.0::kg + 1.0::slugs)::slugs
(2) 2.3704355929 53220181 slugs
Type: Mass
Ideally I'd also like Axiom to be able to deal with (2.0*kg +
1.0*slugs)::kg as well, but I don't know if that would be legal or not.
Conceptually at least, 2.0*kg and 2.0::kg are the same thing. I'll
add more mockups below as they seem relevant.
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.
I would like to see this feature handle things as follows (I don't know
enough about the type system to know if it could do this yet)
(3) -> (4.0::kg * 3.0::m / 6::s**-2)
kg m
(3) 2.0 ----
2
s
Type: Mass*Length/Time^2
(4) -> ActivateExtendedUnitTypes(MKS)
(4) True (not sure what the "standard" way to do this is)
Type: Bool
(5) -> (4.0::kg * 3.0::m / 6::s**-2)
(5) 2 N
Type: Force
(6) -> (4.0::kg * 3.0::m / 6::s**-2)::dyn
(6) 200000 dyn
Type: Force
(7) -> (a::N)::dyn
(7) 100000 a dyn
Type: VariableForce
There are many other variations on what a user might want - for
example, after doing some calculations in N or dyne they may want to
render their forces in base units, but cm*g/minute^2 rather than MKS.
Options to set defaults for and override locally all of these
simplifications are needed. Assignment checking is also needed - for
example, in the last example above a should only be assigned quantities
of type Force. However, any Force type is legal and should be accepted
and converted as controlled by settings.
Perhaps you are confusing the notion of 'dimension' and 'unit'
here
Possibly - I get a bit loose with my terminology sometimes, which won't
do in the Axiom world :-). To be clear - each unit is associated with
a dimension, and I would like to see the rules governing unit
interactions work on the dimension level, while handling the conversion
between different units with the same dimension automatically based on
circumstances as determined by either default settings or the user's
preferences.
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 constitute a type error.
Right - essentially Axiom's strict typing gives us a chance to have
dimensional analysis as part of all calculations :-).
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.
Right, but as I showed in my examples above my preference is for the
units to remain as a displayed part of the expression, and the Type
information to report the dimension of the quantity in question. This
seems to me to be the most useful thing to do.
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.
I have looked at the Maple package, and indeed they use many similar
ideas to ones I had arrived at (after much trial and error) in the
Maxima design. (Boy was that embarassing - a real lesson to do my
homework before beating my head against the nearest wall!) How it's
ideas map into Axiom's strong typing system is, unfortunately, the real
nut to crack. Axiom's system offers some exciting possibilities, but
it looks like there might be some roadblocks to plow through too.
I should mention that Maple has the idea of things like (IIRC) unit
space where expressions are encapsulated in a Units() denotation, e.g.
4*z*Units(kg*m/s^2). This was rejected for the Maxima package - we
felt that the program should be able to handle the "textbook"
kg*m
formatting style of 4*z ---- since this is the convention used
2
s
almost universally in the sciences (who are most likely to be dealing
with units.) I have the same hope for Axiom - units, as multiplicative
factors, remaining part of the expression, and the Type information
working on the dimension level. (As in my examples above.)
These are just some rough initial ideas. I am not sure how
well this concept of "units as types" will work out in
detail.
It might be that that would be the best "mapping" of the idea onto
Axiom's system, although aesthetically I prefer the idea of working
with dimensions and units providing the multiplicative factors for
conversion between each other. Discussion welcome.
Cheers,
CY
P.S. - there's also the whole idea of error analysis which enters into
this equation - for example, when discussing physical quantities 2.0
has a significance - you are implying a greater measurement accuracy
than just stating 2. So there may be a collision in the future between
float and integer behavior in Axiom and the handling of accuracy. For
example, if I have a measurement of 10+-2 and I subtract the quantity
4.0007+-0.0005, the proper return (if I've got this right - it's been a
while) would be 6+-2, since error analysis combining the two errors
would result in 2 + <small amount>, and significant figure rules say to
chop off the <small amount>. Anyway, there are rules governing such
things and I suspect there might be a collision between those and
"normal" mathematical convention, where all things are exact. Then
there's the whole issue of errors introduced by the CAS itself, due to
precision limits and such. But that's for another day.