Re: [Axiom-developer] Unit package question

[William Sit]

C Y wrote:
> 
> --- William Sit <address@hidden> wrote:
> 
> > 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/
> 
> Sounds good to me.  The only fly in the ointment is kilograms for mass,
> but this can be handled.  (It might not be an issue if we don't
> automate metric prefixes anyway.)
> 
> BTY, what is the actual difference between SI and MKS?

I have not researched the difference, but that is a minor point in terms of
implementation design. 

 
> > 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".
> 
> Is that a bad thing, necessarily?  I know there are a fair number of
> derived dimensions, but I think it's on the order of 10^1, not 10^2 or
> 10^3.  That way we can deal with any quirks on a per-dimension basis,
> which would be conceptually a good match with the "real world."  Are
> there reasons it's a bad idea to define large numbers of domains in
> Axiom?

Yes Axiom can handle lots of domains, but that does not mean we HAVE to use one
domain for every physical quantity. See the SI pages for all the quantities.
Also separating the physical quantities into its own domain will cause a lot of
unnecessary coercions and since derived dimensions are obtained with arithmetic
operations, a domain like Force may not support that.

> > 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.
> 
> I like this as a user option, but I'm wary of it as a fundamental
> structuring mechanism - what about the case where a user finds it
> convenient to adjust dimension to a custom default, say wanting Length
> to be displayed as nanometers by default instead of meters, but leave
> most SI units in place?  

That is no problem at all. A user can create his/her own unit system domain by
modifying the implemented code for SI or CGS, or whatever. The user unit system
can mix units if that is preferred. The only restriction is that in symbolic
computation, that is, in equations involving physical quantity, the actual unit
should NOT be part of the equation, and if it is dimensionally balanced (all
additive terms have the same physical dimension -- but this is not sufficient,
you should not add Work to Moment), then the units can be handled in the unit
domains by modifying the coercions to OutputForm. For example, if "us"
represents a value s with dimension "Force", and one wants to output "Force" in
lb cm/hr^2, then one can have (syntax of Axiom need not be correct):

   coerce(us:MyUnitSystemDomain)==
     ...
     (dimension(us) case "Force") => 
        factor := ...
        hconcat(value(us)*factor::OutputForm, "lb cm/hr^2"::OutputForm)
     ...

where factor is to be computed depending on the (input) units for mass, length
and time in this domain (which NEED NOT be lb, cm, hr respectively). It can also
be handled by the "lift" packages that provides similar coercions. In other
words, units for each physical quantity does not have to be (but CAN be) derived
from the units of the basic dimensions. Let the coerce function handle all the
conversions.
         

> (I do understand and agree with the appeal of
> this as a way to group definitions of units in terms of SI units - it
> does organize that well.)  Where do we put definitions for units not an
> official part of SI or one of the other systems?  What if (for whatever
> reason) someone wants to mix and match CGS and MKS over the various
> dimensions - what mechanism do we use?  I don't think we want to
> restrict that behavior - it might be unusual but can't really be called
> bad practice, since having whatever units happen to be intuitive
> available is perfectly legit, especially when the tools exist (or will
> exist ;-) to automatically standardize all units for publication :-).

See above example.

> > 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.
> 
> Hmm.  So instead of domains, we specify the existance of dimensions in
> the category definition, and then create domains based around standard
> measurement systems which must provide unit definitions for all defined
> domains in their category?

Yes. A unit system should be coherent (even though this proposed set up will
allow unconventional systems) and Axiom should provide the common ones like CGS,
MKS, FPS (foot-lb-sec). Users can then modify one closest to their liking and
customize it. Other users can then write other domains in categorical terms if
dimensions are involved by referring to UnitSystem category.

> > 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.
> 
> Yes, I hadn't gotten to physical constants yet - I figured Units should
> be in place first :-).

Physical constants are an integral part. Pi is a good example that appears in
many physical formulae.
 
> > 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.
> 
> Hmm.  Did you have an example in mind?  Sometimes that helps.

How about Weight = Mass * AccelerationDueGravity and
Circumference = Pi * Radius?

Both AccelerationDueGravity and Pi are considered constants (which is correct
only when each is converted to a numerical value after chosing a unit system):
but the first has a dimension of "Acceleration" and the second is dimensionless
(Dimension domain should include "None" in the Union("Mass", etc)).

Another example is specific heat c, defined by the equation: Q = c m dT, giving
c a dimension of energy/(mass * temp). The only way to find the dimension of
such a quantity in general is by "solving" (dimension analysis) but that only
provides the answer in terms of basic dimensions.
 
> Are you referring to the problem that some combinations of units that
> will occurr will not map to a derived dimension?  We must allow for
> expressions which are composed of the product of base and derived
> dimensions - that's inevitable.  Does that pose a problem?

There is no one-to-one conversion from rational expressions of basic dimensions
to physical quantities. When possible, the physical name of the dimension should
be retained (so moment cannot be confused with work; this also remind me that we
should separate scalar quantites from vector quantities).

> If you're looking to determine dimensional equality, the best way I
> know is to reduce everything to the seven base dimensions and simplify.
>  That might be a bit more CPU intensive than taking shortcuts in the
> case of complex expressions, but it is the most general way I know of
> and has the best chance of succeeding in general.
 
Agreed, but see above.
 
> > 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).
> 
> I guess I'm not understanding the difficulty of maintaining domains -
> unless there would be problems setting it up, wouldn't it be a one time
> effort to create the domains and then occasional additions and unit
> definition updates?

The reason against separate domains for each physical quantity (dimension in
this sense) is not just because there are lots of them, but because it would be
difficult to spell out the interrelationships and to create new ones. Yes,
everything is a one time effort, except when it comes to being used.

I suppose if there is no consensus, then we would have to implement with
different designs. Axiom can support that with no problem.
 
> > 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).
> 
> This works for things contained in systems, but what about
> piecemeal/custom setups?

I don't follow your question. I already explained above how anyone can design
his/her own unit system in the setup proposed.

> > These are just some beginning thoughts, which certainly need serious
> > critique from all.
> 
> I like a lot of these ideas, I guess I'm just confused by your
> adversion to domains - or rather, I don't fully understand the
> difficulties associated with them.  What do we gain by defining
> dimensions in the Category, instead of doing the dimensions as domains
> and defining the unit systems in terms of specific unit choices for
> available dimensions?

I don't know the difficulties about many domains either, since I have not tried
to implement them. I only have a hunch. It may turn out that having many domains
(one for each dimensional quantity) is easier (to use and to implement). Neither
do I have a clear picture of what I proposed, but at this point, I like it
better (until convinced otherwise). I like it because, as you asked, one can
design one's own unit system once, and then doesn't have to worry about it. I
also like it because it separates the symbolic expression from the units. The
functions of the form unitXXX can be used in assignment statements that carry
out a sequence of computations, verifying the dimensions and they stay in the
same domain (no need to load tons of domains and perform domain-to-domain
conversions (even if that is possible and meaningful). An example of such a
sequence of computation can be (assuming the domain S is FRAC POLY INT and we
use FPS(S) and we have implemented the arithmetic operations in FPS(S), as
inherited from S; the output units are put in brackets to separate them from the
expressions):

ux0:=unitLength('x0)

    x0 [ft]

uv0:=unitVelocity('v0)

    v0 [ft/s]

ut:=unitTime('t)

    t [s]

ua:=unitAcceleration('a)

    a [ft/s^2]


us:=ux0 + uv0*ut + ua * ut^2/2

    x0 + v0*t + a*t^2/2 [ft]

us::MYUnitSystem(S)

    (x0 + v0*t + a*t^2/2)*factor [yd/hr^2]

where factor is a number or an undefined symbolic convertion factor. One can
also input values in other system than the one used:

ux0:=unitLength(50)$MYUnitSystem(S)::FPS(S)

    150 [ft]

would take the input 50 [yd] (yd being the unit of length in MYUNitSystem(S))
and convert it to FPS(S). It is much easier to remember the name of a unit
system than to remember all the units of various dimensional quantities. Using
the Rep proposed in the previous message:

   Rep:=[value:S, dim:Dimension]

the last instruction first creates

   [50, "Length"] in MYUNitSystem(S)

and then converts it to 

   [150, "Length"] in FPS(S).

The conversion factor only arises when we change unit systems. If the conversion
factor is not coercible to S, we can leave it symbolic and undefined, like:

   [50 yd2ft, "Length"] in FPS(S)

and then one can evaluate:

subst(value(ux0), yd2ft, 3.0)

or better:

ux0::FPS(Float) 

   150.0 [ft]

will do the conversion without the user knowing how it is done.
 
> Just curious - lord knows I'm not informed enough to critique :-).

To quote Martin: "Don't say that"! Every question or idea contributes to the
eventual product. 

More critiques are welcome!

In another post, CY wrote:

> are Work and Moment in some sense the
> same thing? If not, how can the difference be expressed?

The two are different. Moment (in physics) is a measure of tendency to produce
motion especially about a point or axis and is computed by the product of
quantity (as a force) and the distance to a particular axis or point. Work is
the transference of energy that is produced by the motion of the point of
application of a force and is measured by multiplying the force and the
displacement of its point of application in the line of action. (Both taken from
Merriam-Webster On-line).

> > So the way to handle mixed unit expression should be to first
> > convert say 5 feet to meter before addition. I would not
> > worry about such expressions since that is not "scientific" (Axiom:
> > The Scientific Computation System).
> 
> Do you mean worry about preserving them interally or as output?  If so,
> I agree.  As input, they should be legal if dimensionally legal and
> converted internally to useful form.
> 
Yes, we CAN allow input like 3 meter + 5 feet, but the question is, how is the
system going to tell whether the user wants meter or feet in the answer? In my
scenario, the user would be forced to do something like

(unitLength(3)$MKS(S) + unitLength(5)$FPS(S))::MKS(S)

    3 + 5*ft2m [meter]

which may not be that bad, because it forces the user to think carefully and
spell out explicitly the units used. (This certainly would have prevented the
crash on Mars). 
In the domain-preferred scenario, this would be:

   (3 meter + 5 feet)::meter

The disadvantage of the former is it is long-winded, but the user does not have
to know the actual units in the systems and there is no new syntax to be
learned. The disadvantage of the latter is that the user needs to know the
units, and the units takes up name space (meter and feet would have to be
reserved words) and either a new syntax has to be constructed or the domains
"meter", etc needs to know about arithmetic. It is certainly more intuitive, for
simple units at least (can anyone name the unit for viscosity or thermal
diffusivity offhand?) Given the number of unit systems and the number of
physical quantities, I would opt for not having to know them except the system
names, or just MYUnitSystem.

William