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

[C Y]

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

> C Y wrote:
> 
> > I would vote yes, because I can't predict what I'll want to 
> > do with my unit environment. 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.
> 
> Fair enough. But there is no reason why one cannot first convert
> ft to m, use SI as is, then convert back from m to ft.  If a user
> really want to use ft instead of m but retain all other SI units 
> ALWAYS, then create a MYUnitSystem domain, and use )set unit 
> MYUnitSystem. The implementation would be so much easier and
> you still retain the flexibility. Flexibility and generality may
> complicate usage as well as simplify usage. We have to balance 
> the them.

Agreed.  What about this - create such a domain as the "default"
domain, "use" SI units for defaults, and provide tools for the user to
make changes?  The changes would occur within the Default "working"
unit domain, assuming any were made - otherwise, it would look just
like the SI domain.  If one wanted to work in an environment which flat
out disallowed such setting changes, )set UnitSystem SI (or whatever
system desired) would take the user to the system defined SI domain
instead of the Default environment.  Does this map to what Axiom can
do?
 
> > But it should be doable, readily, IMHO.  That's what computers 
> > are for - to handle the grunt work associated with such 
> > decisions.
> 
> As long as you are willing to do the programming :-)

Hehe - fair enough!  In fact, I think such things can be built as a
layer on top of your system, which is undoubtedly the most robust way
to handle things.  So I vote for doing it your way, and then if I
really want some of what I say I want it can be implimented on top of
the core system.
 
> > There is also the case where you want to know what
> > quantity/dimension an expression is.
>
> Reverse dimensional analysis, is useful for providing the user 
> with possibly different interpretation of the dimension of an 
> expression. Checking dimensional correctness is a different, 
> though related, issue.

Ah :-). Thanks for helping clarify all of this - it's definitely
broadened my understanding of units/dimensions/etc. :-).
 
> > > 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.
> 
> Sure, but that does not mean one has to do it for all possible
> conversions, only the most useful ones should be provided, with
> functionality that allows, though not as convenient, the very 
> special user to change units.

OK, point.  As a possible future extension to this environment though,
I may try and code up a way to do as many such conversions (arbitrary
unit -> current environment) as possible, since usually the unit that
causes the biggest problem in a problem is the obscure uncommon one you
have to go dig up the conversion factor for.  This argues for as broad
a knowledge of units in Axiom as possible, although I admit this should
probably be done over time and not as part of the initial effort.
 
> Ignoring it in this example would mean the equation is not
> dimensionally balanced, and worse, some may think that 
> degree = radian!

I think this is a weak spot in my understanding of dimensionality, so I
apologize if I'm being dense here.  If we take C=%pi*d where C is a
circumference, %pi is %pi, and d is diameter, and look at the
dimensions, we have:

          degree
Length =  ------ Length
          radian

Casually, this doesn't look at all balanced.  Does it mean that when we
define the dimensionality of the variable C we need to define it as:

 degree
 ------ Length
 radian

rather than just Length?  I suppose in once sense this preserves the
information that C is a curve instead of a straight line, but I don't
quite see how the ramifications of that play out.  I suppose if you
then describe the distance a wheel would move in x if you rotate it
around its center n times the degree/radian information might be
pertinant, so perhaps there is reason to do this after all, but I think
it will require careful though on how to deal with this situation.

> OK, let me try to explain again.  A quantity is dimensionless 
> means its dimension can be reduced to 1. But sometimes, it is 
> more meaningful (physically or mathematically) to view these as a 
> quotient (this is like, but not totally, we sometimes rewrite 1 as 
> 2/2 to add fractions). Even SI recognizes this in stating that the 
> unit of a phase angle is m. m^(-1) = 1 because this IS the 
> definition (arc length spanned by the angle, divided by the radius).
> Just because the dimensions cancel out (making it dimensionless) 
> does not mean the dimension is not there.

OK, I think I'm getting it.  So what we need to do is examine the cases
where it is actually useful to retain this information, and see what
behaviors are rigorous/needed/useful.  Definitely in some cases we need
to canel dimensions out - we don't want something described in (say)
kg/s multiplied by seconds to wind up as kg*s/s, but if there are cases
where m/m is useful to preserve there would seem to be a problem with
having a general rule.  Could unit and dimension cancelation be handled
on a per dimension basis? 

> Definitely. We can have a nanosytem domain, and other domains of
> UnitSystem(S) as experts need them. That is the beauty of Axiom's 
> categorical approach: unifying domains with a common set of API.

OK, cool.  So we might actually develop a situation where, for
different kinds of work, we have different standard domains defined
(say, as an example, if someone is working with radio telescope data
and equations, they can do )set UnitSystem RadioTelescope having
previously defined the desired unit conventions for such work.  I
guess, thinking about it, my scenarios for unit use were too narrowly
focused on the case of students, where arbitrary units will appear for 
any reason and no reason (sometimes just to make them look them up and
do the conversion, which always annoyed me as an extra and unnecessary
potential source of numerical errors but in retrospect was probably
good training.)  For "real world" use, that case is not terribly
useful, and Axiom is definitely not focused on introductory student
problems :-).

Cheers,
CY


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