Re: [Axiom-developer] Unit package proposals and questions

[William Sit]

> C Y wrote:

> OK, but don't we want to take it one step further and have Axiom assume that
> after a setDim("Dimension",s) command is issued when we type s on the input
> line we are referring to the new object with outputform "s [m]" when s is any
> type of  Variable?  If s is a number this doesn't make sense, but intuitively
> when I do setDim("Length",x) I expect that from that point on, unless I do
> unsetDim("x") to explicitly undo the setDim command, when I say "x" I'm
> referring to the object that has both the variable x and the information
> about Dimension. 

As I show in my earlier reply, we can do setDim("dim",s) but we still need to
assign it to s when s is a Symbol. There is a catch: since there are many
domains that include symbols, it won't be clear where s belongs. In other words,
since there are many setDim functions, one for each domain in the UnitSystem
Category, and each PARAMETER S for UnitSystem, you have to do a package call to
explicitly say which S should contain the symbol. For example, you may want:

   s:=setDim("Length",('s)::S)

or  

   s:=setDim("Length",'s)$SIUnitSystem(S)

In such cases, there is no point in retracting s to S (which will give a symbol
s). In order to make s behave more like it were without units, let's see what
the following scenario will require (assume FPS system)

(1) ->  s:=setDim("Length",4)
              4 [ft]
(2) ->  s:= 7

In order that (2) gives the answer "7 [ft]", the package will have to include a
coercion function that is quite smart: it will need to first coerce 7 to
FPSUnitSystem(PositiveInteger) WITHOUT knowing its dimension, then coerce that
to FPSUnitSystem(S), without knowing the dimension --- which requires S to have
PositiveInteger as a subdomain, then assign whatever property s has (its
dimension and unit at the time) to 7, and finally assigning the fully formed
object (Rep for 7 [ft]) to the identifier s of type FPSUnitSystem(S). Now of
course, the more direct and intuitive way is simply to change the value field in
the Rep for s to 7. But HOW is the Interpreter to know that via a simple,
universally coded assignment?

So to help the Interpreter, or indeed, to avoid having to modify the interpreter
to make it smarter -- such modification will add so much inefficiency to
ordinary assignment that it is not advisable in any case---we can design
functions to do the more intuitive thing:

(2') ->   setValue(s, 7)

but of course this is not as intuitive for the user as (2)! However, it is
actually quite uniform and similar to setDim or setUnit.

The same means that a statement like:

(3) ->  s:= s + 7

would involve the same type of coercions as for (2). If instead,

(3') -> setValue(s, s+7)

then the function setValue *may* be taught to first retract the s in s+7 to S,
add 7 to it in the domain S, then put this in the value-field of Rep of s. I say
*may*, because the general situation would require a parser!

So there is still a big design problem to think about: how to make subsequent
computations intuitive without writing a parser for the package! The following
way perhaps works (effectively asking the user to do the parsing):

    setValue(s, retract(s)+7)

(any implementation, in Axiom, will require conditional implementation, testing
that S can do arithmetic with PositiveInteger or Integer), and if s is not just
a symbol, a retractIfCan(s) may be more appropriate.
 


> That's implicit in issuing the setDim command in the first
> place.  In a software design sense I would think that doing otherwise would
> violate the Principle of Least Surprise.  

You should know that Axiom is full of surprises because it is not easy to
understand the implications of a strongly typed language.

> I would rather use some command
> like stripDim("x") to get at the object "x" that doesn't have a dimension
> associated with it if for some reason I want it, because once I so setDim
> command it's assumed (at least by me) that I don't WANT to have x work as an
> object without dimension anymore.  Obviously this doesn't work for
> setDim("Length",4), since 4 is not a variable, but in the case of x it should
> (at least IMHO) work.

The problem is with subsequent arithmetic (not to mention the grander vector
calculus) that involves quantities whose dimensions or units have not been
defined, whether they be numbers or expressions. In some sense, this is again
forcing the user to know what he is doing, to think of dimensions and units in
every step of the computation. But users used to the sloppy way will find this
very frustrating.  In the simple example above, s+7, the dimension and unit of 7
are not given. Is it good idea to "help" the user and "guess" that 7 should have
the same dimension and unit as s? If so, wouldn't that allow a sloppy user to
add s [ft] to 7 [in] and get (s+7) [ft]? 

I think we should not provide such automation: two reasons: simplifies
implementation, and forces the user to be specific on dimensions and units. So a
user MUST declare, using setDimUnit, EVERY quantity he wants to compute using a
unit system. If all inputs to an expression are declared ahead of time, the
arithmetic will take place in the unit system domain and parsing done by the
Interpreter, without the use of setValue. 

It would be desirable to allow:

    s:= setDimUnit("Length","in",'s)
    t:= s + 7 [ft]

to give a value of s+84 [in] for t. But this involves modifying the interpreter
and the language! ([ft] may be a list containing a variable ft). Here is an
argument for using variables for units, because there would have been created
conversion (rewrite) rule ft == 12 in, which would be applied automatically.

> Maybe we can flag this behavior so that if a hard core
> Axiom user prefers the behavior which is a consequence of strict interaction
> with a strong type system and doesn't want to special case variable behavior
> Axiom won't do the extra voodoo?

In general, I don't like (personal bias) a program to provide automatic help
(such as checking grammar or spelling or indentations in MS Word!). It is far
better to have fewer options and the system behaves consistently.


> What if we internally use
> some symbol other than the one given in setDim("Length",a) and have a rule
> for displaying a variable with dimension that it shouldn't show the internal
> symbol but a instead.  Something like:
>
> setDim("Length",a) -> creates some object containing [nondim_a,Length] and
> assigns this to the name a, just like a := <object> would.  Then we create
> some kind of display rule that rather that variables of the form nondim_* be
> displayed as * in output?  This would preserve the Axiom type behavior while
> hiding the messy details and avoiding violating user expection of variable
> interaction.  This could probably be turned off as well if a hardcore Axiom
> user wants normal behavior.

I suppose the above is obsolete now?

[snipped]

William
--
William Sit
Department of Mathematics....Email: address@hidden
City College of New York................Tel: 212-650-5179
Convent Ave at West 138th Street........Fax: 212-862-0004
New York, NY 10031..Axiom, A Scientific Computation Sytem
USA............... http://www.nongnu.org/axiom/index.html