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

[C Y]

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

> Let's be clear. You are requesting a reverse dimensional analysis 
> in essence. Given a rational expression in the dimensions (basic 
> or derived), you want to give as meaningful as possible an
> interpretation (or list of interpretations) that is relevant to 
> the expert user. 

Right.
 
> From you statement:
> 
>    dimension(23*J)
> 
> you are assuming that J is a reserved variable in Axiom, or at least
> recognizable by the system just like %pi.  I think using up name
> space with short names like "J" for Joule, etc is going to be very
> problematic with the interpreter. My proposal puts these only as
> output strings, and does not allow their direct manipulations as 
> variables.

Ah, OK - yes, I can see how your design implies that.

> To input 23 J, one would have to do:
> 
>    x := unitEnergy(23)$SI(INT)
> 
> assuming Joule = Newton-meter is the default energy unit in SI. 
> Under this setting, one can create a function
> 
>    dimension: % -> Dimension
> 
> where for example, dimension(x) would return 
>   
>       "Energy"
> 
> (the unit may or may not be given, depending on design; and I think
> if unit is what is intended, then we should have:
> 
>    unit: % -> OutputForm
> 
> and 
> 
>    unit(x)
> 
>        "J"
> 
> or in basic units:
> 
>        "N-m"
> 
> (adopting notation from SI).

Makes sense.

> Since I view units I/O as only decorations, they are all strings
> and not to be manipulated by arithmetic (but string operations
> are allowed of course). All this works in the current proposed
> scheme.

Yes, with the exception of the namespace issue it looks good.  You have
a valid point about using up namespace - more on that below.

> Now the reverse dimension analysis (RDA) is a totally different
> problem. The input to RDA is the outputform of a physical quantity
> (symbolic or numeric), perhaps inputted as a string (as I 
> discussed, I object strongly to using up user namespace). Assuming
> the string uses SI convention, we can write a parser based
> on the grammar defined, first to reduce every additive term to basic
> units in the seven basic dimensions, verify that they are all the
> same, then re-interpreting the resulting dimension expression in
> terms of plausible physical quantities depending on the subject 
> matter expertise. This requires a substantial amount of math: 
> basically, assuming you have the taxonomy for units
> in the expert area, you have to solve a dimension analysis problem,
> which is a (fairly large size) linear diophantine problem. A 
> solution is of course guaranteed since the dimensions of the given 
> terms in the input expression are solutions, but more likely, you 
> are going to have many solutions (for example, energy can be 
> produced various ways: potential and kinetic, rotational, work,
> Einstein's mass-energy exchange, etc). A decision criterion 
> to choose the "simplest", perhaps by the minimum total sum of the 
> exponents of all the basic/derived dimensions allowed, would then
> present the user with the result or set of results.

I guess that's pretty much what I pictured, yes.  I think it's less
important to identify things like potential vs. kinetic energy and just
identify that <quantity> IS an energy.  This can be helpful in building
an intuition about the system you are working on, even without more
specific information.

> I think the usefulness of such a RDA is minimal. A user typically
> knows what that is when he forms the expression.

At the student level I'm not sure I agree.

> Perhaps letting the system check the consistency of terms in 
> dimension is the only useful feedback, but that does not
> require RDA.

There have been times in the past when I would have liked to have RDA
to help me understand the calculations I was working on in a "physical"
way, but this can probably be defined as a deficiency on my part.

> Having a system setting to choose a particular unit system as 
> default is certainly desirable and possible. Axiom has extensive 
> )set commands. The convenience gained after this )set command
> 
>    )set unit SI
> 
> will be that the following commands do not require a package call:
> 
>    unitMass, etc
>    dimension
>    unit

That's most definitely a good feature to design in - I might set
UnitSystem rather than unit, but that's just a quibble.

What about by default creating a UserUnits system, and "importing" the
SI definitions into it as the "default" state?  This would amount to
putting user-friendly tools on creating a custom unitsystem domain, and
hide the need to do so from the user.  The system need only define the
standard environments, but if we allow the UserUnits system to
automatically import definitions while preserving and allowing local
overrides transparently, this would allow for full flexibility.  Best
of all, it can be defined "above" the more correct, structured systems
and ignored unless it is actually of interest.  So, upon consideration,
I vote for the SI/MKS/CGS domain proposal, since it can be built upon
for other environments which might be less "Axiom-like" in behavior.

> Being "fuzzy" is certainly against the philosophy of Axiom, but I
> suppose as long as it is clearly pointed out, there is no reason 
> not to allow it. Martin has a "guessing" program for sequences, and 
> it is very useful. So go ahead. I agree that Axiom suffered 
> commercial failure for its inflexibility.

To my mind the important things are a) to be able to work in a useful
way for the target audience, and b) to start with definitions in full
rigor and build "looser and friendlier" systems on top of that, so
additional power up to fully rigorous is available depending on the
situation.  I am very appreciative of these emails - they have made me
think about dimensions and units in ways I hadn't previously
considered, and that is valuable as an insight into the nature of those
systems all by itself :-).
  
> No, energy is energy and Work is energy, so they are interchangeble.
> (For example, work against friction produces heat).

OK.  I guess we would need to find some place where such things are
cataloged, and impliment that catalog in Axiom - unfortunately I have
no idea where to go for such a document.

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

> Well, in my proposal, units names are implicit by using declarative
> functions (like unitMass()) in a particular domain of the UnitSystem
> category. I have already argued against the use of reserved 
> variables for units. People should be allowed to use J, nm, etc as 
> their own variables. All system variables (except domain
> abbreviations and names) have to be preceded by a % sign, as in 
> %pi. You have to teach the interpreter to recognize these special
> names.

I disagree here, although I concede you have valid points and the
default should probably be your way.  When I (or a student) am working
in Axiom on a physics problem, I have certain definite meanings
attached to symbols like J, nm, N, etc.  I want my use of these symbols
as variables to be illegal, since if I do so I am introducing the
chance for MASSIVE confusion down the road.  My mind is trained to look
at kg as kilograms when I am working on a problem with units as opposed
to numbers, and I would prefer that the CAS enforce this to make sure I
don't make mistakes.  However, based on my experience with Maxima you
are correct about the difficulties this introduces, and so if it is
done it should be built as an extension to the "correct" units
environment, not as the default.  I think this is doable, and the
design of the main units package does not need to specifically
accomidate it.

> > 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.
>
> As long as you are willing to do the programming :-)

Heh - well, that's certainly fair enough :-).

Cheers,
CY

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