Re: [Axiom-developer] Unit package question - Reply to 1st half

[William Sit]

C Y wrote:
> 
> --- William Sit <address@hidden> wrote:
> 
> > 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.
> 
> That, at least, I would prefer to avoid.  If the user sets SI or CGS, I
> think we would prefer to avoid requiring them to program spad code to
> set up anything customized for a specific situation when a couple of
> local overrides would work.

It is easy to create functions to reset the units in any domain of UnitSystem
category. We just have to do this by providing functions like:

setUnitLength(nm)  -- assuming we use SI abbreviations.

However, for the package to provide such generality would require not only
updating an internal table (it will require one anyway, of all the units
corresponding to physical quantities (dimensions)) but also that the output
coercions figure out the factors before output. This does complicate the output
coercions because there can be many cases to deal with even if we restrict such
user settings to the seven basic dimensions. If a normal range of powers of 10
is from -30 to 30 (which includes nanoscale to astronomical scales, and enlarge
the range if you like), there would be about 20 cases to check for each basic
dimension (allowing one new prefix for every third value of the exponent). On
the other hand, a user custom unit system need only modify simple code for the
specific units. Generalities quickly expands the cases exponentially.

The set functions will also have to do error checking (that is, verify that nm
is indeed a unit of length, or at least among the units it knows). Again, this
would complicate the implementation of the domains for UnitSystem category.
Would you allow, for example, in SI(S), setUnitLength(ft)? (I would vote a
definite No).

Remember, a user can do such unit conversion by coercion if Axiom thinks that
nanoscale is a common unit system and provides one. We can also provide one for
astronomical units. The idea is to allow gradual growth to satisfy user needs,
but the first implementations do not have to be all-encompassing. The design has
to be.

> > The user unit system can mix units if that is preferred.
> 
> So you're envisioning a separate level of logic which handles user
> settings, and the underlying one organized as outlined below?

Yes, but that scenario is not encouraged (indeed discouraged), even though it
can be done. 
 
> > 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.
> 
> We can make it stronger by requiring all additive terms to have the
> same dimension, and not allow derived dimensions with the same units to
> be automatically merged.  (Really, if they could be merged all we would
> need to do is define a few more aliases for the original dimension, as
> opposed to making a separate one. If we make Work and Moment separate
> derived dimensions, they won't merge at the symbolic level. 

All I am saying is that even if an equation is dimensionally correct, it could
still be wrong (in terms of physics) because of this non-unique mapping. We
certainly cannot just use dimensional analysis (reducing to basic dimensions) to
discover that Work = Moment is wrong. 

> However,
> we will have to make a decision as to the mapping of a unit back to a
> variable with a dimension matching the unit's MKS base unit definition
> - do we assume if someone is assigning a variable with dimension Work a
> value with units compatible with Work, it is a Work quantity and not a
> Moment quantity?  

In my scheme, you do not assign a variable to its unit explicitly. You assign a
dimension to the value (which has no unit attached explicitly, and only
implicitly based on the domain the result of unitXXX function). This frees the
symbolic computation of units, the way it is usually done in science.

> The same problem holds for dimensional analysis - we
> should report something.  Do we report Work, Moment, or both?  If
> someone enters a purely unit based expression and wants dimensional
> analysis of it, what do we do?  Erroring out with something like
> "non-unique dimensional mapping - please specify dimension type for
> <error generating unit> - {Work, Moment}" would probably be the most
> correct way. 

I don't understand this question. There is NO unique way to decompose ANY
rational expression in basic dimensions and return it as a result of (rational
expression) in physical derived dimensions. Dimensional analysis is a one-way
method: reduce derived dimensions into its basic dimensions and match the
exponents for each basic dimension. 

> Maybe we could have a setting which was either strict
> (above behavior) or fuzzy (assumes in a case where there are multiple
> possibilities the user knew what they were doing, in order to avoid
> endless aggrevation when working on basic problems?  If a scientist
> knows Moment is not part of his system, he can use fuzzy matching for
> casual work and get strict about it for the final draft :-). And it
> would also be good to document the physical reasons behind such design
> decisions, so people who aren't physics gurus could figure out why the
> CAS is grumbling at them ;-)

Even a so-called "dimensionless" quantity can sometimes have "dimension":

  phase angle: unit radian, dimension m.m^(-1)
  solid angle: unit steradian, dimension m^2. m^(-2)

See: http://physics.nist.gov/cuu/Units/units.html

There is no hope to list all possibilities.  Another example taken from that
page:

  absorbed dose (specific energy imparted), unit gray, dimension m^2.s^(-2). 

The dimension is actually meaningless. Expressed in terms of derived 
dimensions, 
1 gray is 1 J/kg (makes perfect sense as energy/mass). But one can also say the
dimension is that of velocity^2 in other context.

> 
> > For example, if "us" represents a value s with dimension "Force",
> > and one wants to output "Force" in [slug] 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, "[slug]
> > 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.
> 
> Well, as long as we put an intuitive front end on everything for the
> end user, I'm OK.  A bit of context - for the Maxima units package I
> have a function setunits() which takes as an argument a list of
> variables, and sets those to be the default output units for each
> dimension.  It returns an error if there is more than one unit
> corresponding to a given dimension.  I would prefer to be able to do
> this in Axiom, as well.  Here's one scenario: I start up Axiom and have
> the default system load up in SI units.  I look at my data, and realize
> I'm working on a scale of nanometers.  SI is ideal for most everything
> I'm going to be doing, but I want Length output to be in nm so I don't
> have to visually sort through lots of powers of ten.  In Maxima, I
> could simply say setunits(nm) and from that point on, until I told it
> differently, all my lengths would be converted and rendered in output
> as nanometers.  I would like similar ease of use in Axiom, if it is
> compatible with how Axiom works - I'd rather not have to open up the
> text editor, whip out a new MyUnits domain, and define things
> accordingly - I'd rather that all be hidden.

Yes, as explained earlier, we CAN provide such functionality. I don't know how
you implemented that in Maxima, but I think it would be cumbersome if
restrictions are not set.

> > 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.
> 
> That's the part that worries me a little - as a user I want to just say
> "use MKS" and then "but render Mass in slugs" without ever worrying
> about domains, convert functions, or any details I don't have to.  At
> next axiom startup my "render Mass in slugs" preference is lost, which
> is find with me - it was a purely temporary condition.

I really don't think a scientific worker would use slugs with MKS. I would
emphatically discourage you from doing that! Making it very easy for a user to
"violate" a system of units is asking for trouble. Making it more difficult at
least ensures the user knows or thinks about what (s)he is doing. I don't
implement generality for generality's sake. Life is too short.

Don't mix unit systems! Convert first before you start the computations, and
convert back if you really have to.

> > Other users can then write other domains in categorical
> > terms if dimensions are involved by referring to UnitSystem
> > category.
> 
> Depending on how sophisticated the user is, yes.

Alright, other developers, not users.
 
> > Physical constants are an integral part. Pi is a good example that
> > appears in many physical formulae.
> 
> Pi (3.14... right) is a unitless number, and so (hopefully) isn't a
> worry from a units standpoint?  Am I missing something?

Let's see. A circle spans 2 pi radians at its center. So 2 pi radians = 360
degrees.
So pi has unit degree/radian (even though that is dimensionless) when it is
viewed as a unit conversion factor between radians and degrees.

> 
> Hmm, perhaps I should clarify - when I say physical constants I'm
> thinking things like speed of light, Plank's constant, mass of an
> electron, etc - i.e. things with units.  Am I using incorrect
> terminology?

That is correct. And there are physical constants and mathematical constants.
:-)
 
> > 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)).
> 
> Oh, got it (I think) - you're considering how to treat dimensionless
> objects in a dimensional analysis?

Dimensionless is not always without dimension and physical constants often have
dimensions.
 
> > 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.
> 
> Right, then you do pattern matching to see if those basic dimensions
> map into any of the derived dimensions.  (Or at least, that's what I
> did in Maxima.  Maybe that's not workable here - I'll have to think
> about it a bit.)

One may do a certain amount of guessing or pattern matching, but that is limited
by one's current knowledge (limited, at best). The example I gave earlier,
m^2.s^(-2), would you even have thought of it as absorbed dose? (I certainly
didn't before writing this email). Given the vastness of scientific research,
you need a subject matter expert to increase the chance of meaningful matching.
The user is often the subject matter expert. Let him or her deal with it.


> OK, gotta run to a dinner appointment - I'll reply to the second half
> later :-).  Very interesting stuff!
> 
Dinner bell just rung for me too. Thanks for the discussions.

William