Re: [Axiom-developer] Unit package question

[William Sit]

Very interesting topic, which I have been following.

I like the idea for a "pivotal unit". What better one to use than the
international system of units (SI)? 

http://physics.nist.gov/cuu/Units/

Different schemes for implementation have been proposed, some even coded. I
don't like the idea of having one domain for each dimension (there are 7 base
units listed in SI) because we would then have to have new domains for derived
dimensions like "force".  Axiom has a way to handle number systems and I think
the unit systems can follow this number system model which has an
IntegerNumberSystem category with four domains: Integer, RomanNumeral,
MachineInteger, and SingleInteger. So we can have one category UnitSystem, with
domains like CGSSystem, MKSSystem, InternationalSystem, etc, where
InternationalSystem would be the default, and the other systems convert to and
from this. In the UnitSystem category, we specify dimensions, beginning with the
seven basic dimensions (length, mass, time, electric current, thermodynamic
temperature, amount of substance, and luminous intensity) and expanded to
include other derived dimensions. The UnitSystem category should allow a
parameter S:SetCategory. In principal, units are input/output "decorations"
attached to expressions from any set S. 

The complications of units come from the conversion factors, which are generally
floating point numbers (and dimensionless). This would be ok if we only deal
with numerical quantities. For symbolic quantities, it is the dimensions that
are more important and conversion factors (not to be confused with universal
physical constants) are seldom used, and universal physical constants are often
denoted by a symbol (such as "g" for acceleration due to gravity) without units.
Thus we should leave symbolic computed expressions alone (that is, in the set S,
even though it is actually in some domain of UnitSystem(S), see below). The
verification of dimension on the two sides of a symbolic equation is not a
simple matter since in the applied sciences, one often "balance" dimension with
a constant of proportionality, for which there is no a priori assignment of
dimension in general. However, we can enforce some degree of verification by our
implementation of dimensions (see below). Acutal units are needed once we pass
from symbolic to numerical computation. Thus we should design the UnitSystem
domains to facilitate such passage. We should have a discussion on what
functionalities are to be included in the UnitSystem category. Here are a few
that comes to mind:

unitMass
unitLength
unitTime
unitCurrent
unitTemp
unitAmount
unitLight

All of the above, and below, functions have signatures similar to:

unitMass:S -> %

and

unitMass(s:S) would declare that the expression s has dimension Mass and unit of
Mass for the domain %: UnitSystem(S). I think this is better than the syntax
s::Mass or s::Kg because it avoids the need for many domains (which would be
difficult to maintain).

A representation for any of the domains of unitMass(s:S) would be
 
   Rep:= Record(value:S, dim:Dimension)

where Dimension would be 

  Dimension:=Union("Mass", "Length", ...)

and we can provide queries for any expression in % as to its Dimension. (The
Dimension domain can also be expanded than just this mere text implementation,
if there are functions that are needed).

We can add as many as we like for the derived dimensions:

unitArea
unitVolume
unitForce
unitPressure

etc.

As an (conceptual) example of implementation (forgive me for Axiom syntax
errors, I did not bother to look them up), we can have:

if S has Ring then
  unitArea(s1:%, s2:%):% ==
    if and(s1.dim = "Length", s2.dim = "Length") then 
      [s1.value * s2.value , "Area"]$Rep
    error "Invalid Dimension"

We can have a "pure" declaration:

unitPressure(s:S):% == [s, "Pressure"]$Rep

or a "derived" declaration:

if S has Field then
  unitPressure(f:%, a:%):% ==
    if and(f.dim = "Force", a.dim = "Area") then
      [f/a, "Pressure"]$Rep

We would need to handle outputs of domains of category UnitSystem(S) to make
sure that the units are displayed at the rightmost location, but this is trivial
given the Rep for the domains in this category (see OutputForm for all the
functionality to handle outputs). Notice that all the dimension verifications
can be done by default in UnitSystem category implementations and the actual
domains only need to handle the units for the particular system.

We need a way to include universal constants, the notation of which depends on
the set S.

if S has Field then
  unitAcceleration(dv:%, t:%):% == [dv/t, "Acceleration"]$Rep
  if S has RetractableTo(Symbol) then
    accelerationDueGravity == ['g:Symbol::S, "Acceleration"]$Rep

If S does not have RetractableTo(Symbol), for example S is Float, then we can
use a specific constant such as 9.81 depending on the domain %:UnitSystem
instead of a symbol g.

So far, the above discussion concentrates on the symbolic side. It also
separates conceptually the notions of dimensions vs units. To handle the
numerical side as well as conversion between different unit systems, one can 
have a "lift" (functor) category that performs this (much like the coercions
between different types of polynomial domains when the coefficient domains are
mapped):

   UnitSystemLifting(US:UnitSystem(S), UT:UnitSystem(T))

would take elements of say, US=CGS(S) to UT=CGS(Float), or to UT=MKS(S). The
exports of this category would contain something like:

convertMass(us:US):UT
convertLength(us:US):UT

The unit conversion factors would be included in such packages and the domain S
should have RetractableTo(Float), or whatever (such as coerced to EXPR FLOAT) to
make sense.

Note that this proposed design allows mixed symbolic-numeric domains for S, such
as POLY FLOAT.

These are just some beginning thoughts, which certainly need serious critique
from all.


William


-- 
William Sit
Department of Mathematics....Email: address@hidden
City College of New York................Tel: 212-650-5179
Convent Ave at West 138th Street........Fax: 212-862-0004
New York, NY 10031..Axiom, A Scientific Computation Sytem
USA............... http://www.nongnu.org/axiom/index.html