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

[C Y]

--- William Sit <address@hidden> wrote:

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

Correct - the Maxima active unit rulesets got quite large.  However,
that is also when they are most useful, at least too me.  I want the
computer doing all my grunt work for me, which includes spotting all
the obscure unit definitions and taking care of them.  Fundamentally,
the set of all units is large, and that's what I want Axiom able to
manage.  Whether or not this will require such exponential data sets is
not totally clear yet, but would not surprise me.

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

Correct.  Maxima's checks first that it is a unit and then that that
unit is a length.

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

I would vote yes, because I can't predict what I'll want to do with my
unit environment.

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

Agreed.  I'm not shooting for immediately comprehensive, but for the
ability to be comprehensive in the future.  I can't imagine all the
ways and situations units can be applied, so I don't want to restrict
the user runtime environments that can be set up and customized.

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

But it should be doable, readily, IMHO.  That's what computers are for
- to handle the grunt work associated with such decisions.

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

No.  However, the ultimate burden in such cases will rest with the
scientist in question, and it may be that the dimensional correctness
of the equation is useful information to him/her.  Hence my suggestion
for two modes on dealing with such things.

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

Agreed.  My question is how dimension(<expr>) should react when <expr>
is not a set of variables, but an expression with units  (E.g. 10 J).
 
> 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. 

Right, if you are looking at the dimensional equality of two sides of
an expression.  There is also the case where you want to know what
quantity/dimension an expression is.

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

I'm not sure what the useful thing to do there is.

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

Right.  So conventions must be defined, preferable default ones as well
as specific ones for things like medical work.

> > 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, I guess it is cumbersome to implement, but I was willing to pay
that price for the convenience.

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

That was just an example.  nanometers instead of meters, or light years
instead of meters, would be more realistic examples.

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

But that's just it - part of the reason for implementing a Unit system
in a CAS in the first place is to get it to do all the converting and
other annoyingly boring and error prone tasks for you - both for input
and output.

> So pi has unit degree/radian (even though that is dimensionless)
> when it is viewed as a unit conversion factor between radians and 
> degrees.

I'm confused - when does it hurt to trivially reduce or ignore this?

> Dimensionless is not always without dimension

That makes no sense to me at all - when is it useful to consider a
dimensionless quantity to have dimension?  Isn't that a logical
contradiction?  F AND ~F -> F

> 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, but I still think a) we can prepare useful "domains" such as
defaults for physics, and b) if such work is done by subject matter
experts we should be able to incorporate it since it would constitute a
useful tool for work in the subject in question.

Fascinating discussion!

Cheers, and thanks!

CY


                
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs