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

[C Y]

--- 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.

> 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?

> 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.  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?  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.  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 ;-)

> 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.
          
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. 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.

> 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.

> 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?

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?

> 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?
 
> 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.)

OK, gotta run to a dinner appointment - I'll reply to the second half
later :-).  Very interesting stuff!

Cheers,
CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com