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

[William Sit]

C Y wrote:

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

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. 

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

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 think the usefulness of such a RDA is minimal. A user typically knows what
that is when he forms the expression. Perhaps letting the system check the
consistency of terms in dimension is the only useful feedback, but that does not
require RDA.
 
> 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.

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

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

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.
 
> But, I'll go ahead on it, since it could be Energy
> and Work don't always interchange either...

No, energy is energy and Work is energy, so they are interchangeble. (For
example, work against friction produces heat).
 
> 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 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 :-)

William