Re: [Axiom-developer] Unit package question - part 2

[C Y]

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


> 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 reminds me that we 
> should separate scalar quantites from vector quantities).

So you're saying that dimension(23*J) should return an error, because
without context it's not clear what physical dimension is being
described?  I agree that if the knowledge exists in the definitions it
should be carried along, but without context, as in the above example,
what should be done?

I propose a convention - it is likely that any use Axiom's unit package
will see will be from the physics community, since that is the most
math heavy of the basic physical sciences.  I propose we create a
variable that can be set to select pre-defined behaviors for cases
where a physical unit corresponds to more than one dimension.  For the
PHYSICS convention, I suggest that the above command return a dimension
of Energy, with perhaps a cautionary that this mapping is not unique in
general.  This would correspond to what I would expect.  (Also, are
Energy and Work different physical dimensions?)  A mode STRICT might be
created where the above returns a description in terms of the seven
base dimensions, which will be correct without pinning the definition
specifically to one derived dimension.  What should be the default I
don't know.

> > 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.
 
I think there could be again modes of operation - in this case fuzzy
(which goes ahead and assumes if MKS units are the same the derived
quantities can safely be considered the same) and strict, which will
raise flags and/or provide correct but less useful answers.  I
guarantee that making Axiom too strict in a correctness sense without
providing a way to get things done will lose it much of its audience in
the unit game, since physicists as a rule are not overly concerned with
mathematical rigor. (Compared to mathematicians, anyway ;-)  I think
allowing both strict mode and fuzzy mode is a good idea, which allows
for both full correctness if needed and a more practical working
environment if desired.  I invite comment on this, since I might have
just stomped Axiom philosophy into the carpet :-/.  At a fair number of
usage levels, people might not even know what Moment IS, much less
whether the dimension of the quantity found in the book is Work or not.
(The book itself might make an unstated assumption, which a student
would have no way to be aware of but an expert in the field would know.
 The student would want to make such assumptions initially, and only if
problems arose go back and check hidden assumptions.  (At least, that's
my guess ;-)

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

OK.  It seems like as long as actual unit transformations are
neglected, things are fairly easy to work with, so I don't think a
design decision change would pose too great a difficulty at the
symbolic level.

> I suppose if there is no consensus, then we would have to implement 
> with different designs. Axiom can support that with no problem.
 
But our limited developer manpower pool can't :-(.


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

Fair enough :-).


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

Hmm.  Well, the situations in which the labels are used are different,
but I'm not sure what is being described isn't the same thing on a
dimensional level.  But, I'll go ahead on it, since it could be Energy
and Work don't always interchange either...

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

Well, that sounds like a pretty good argument for at least having a
mode of operation like this :-).
 
> 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.

Don't we WANT the units and dimensions to take namespace, at least at
user toplevel?  If the UNITS package were active, we certainly don't
want people using unit names for anything ELSE - it would cause waaay
too much confusion.  I would have viewed it as a design goal that (3
meter + 5 feet)::meter work as expected.

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

I guess I would prefer to be able to either "use" the SI system, and
allow local overrides through simple syntax, or "set" the SI system,
and insist on everything being rendered using it.

Cheers,
CY


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