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

[William Sit]

C Y wrote:
> 
> On Thursday 08 September 2005 01:39 am, William Sit wrote:

> > 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.
> 
> I'm not following - are you thinking that we won't know what type "s" is
> inside the object containing both dimension and the nondimensional quantity?
> Well, what about if we had just typed "s" on the input line without saying
> anything about where it belongs? In my copy of Axiom this gives:
> 
>    (2)  s
>                                                              Type: Variable s
> 
> I'm thinking we can assume whatever the "default" assumption would have been
> on the command line - just remember that, bump s temporarily to a symbol, and
> then return it to being a Variable (in this case.)  Or do you mean that s
> will need to wind up in a UnitSystem?  This isn't obvious to me - Dimension
> is more general than any one UnitSystem.  Maybe we need a domain for
> dimension-without-specific-unit objects?

No, I don't think so. So far, everything works even though users will be forced
to declare dimension and unit for each quantity (as we agree below). However,
the above is not the same thing. If a user is comfortable with defaults, that
is, undefined identifiers are of type Symbol (techically, Variable(s) for Symbol
s), and any other operations will be promoted to a higher domain, usually POLY
INT, then that is fine. But if someone wants to work with say S := EXPR INT and
uses SIUNitSystem(S), then he will have to package call the setDimUnit for an
undefined identifier s.  In principle, we do NOT know the type of undefined
identifiers. The Interpreter assumes we are using Symbol. This won't be assumed
in the compiler.
 
[snipped]
> Wait - why do we want s:=7 to work in that case?  I would expect that to fail
> - 7 is a dimensionless number.  For this to work, wouldn't we want either:
> 
> s:=setDim("Length",7)    or   w:=setDim("Length",7)
[snipped]

> I have the equation x(t) := x0+v0*t+1/2*a*t^2 which I want to define with
> dimensional information.  To do this, I need to assign dimensions to each of
> the components in this equation.  What I would LIKE to do is something
> similar to the following:
> 
> (1) -> setDim("Length",x0)
> (2) -> setDim("Velocity",v0)
> (3) -> setDim("Time",t)
> (4) -> setDim("Acceleration",a)
> 
> Then, if I want to assign 7 meters to x0, I would do the following:
> 
> (5) -> x0 := setDimUnit("Length","m",7)
> 
> This would do the following:
> 
> 1.  Create a temporary dimensional object using 7, m, and Length
> 2.  Verify that m and Length are a legal paring in the temporary object
> 3.  Check if x0 is associated with a dimension.   If not, proceed to assign it
> the full contents of the temporary dimensional object.  If it does, as in
> this case, check that the dimension of x0 matches the dimension of the
> temporary object.  If it does not, return an error.  If it does, assign the
> x0 dimensional object the specific unit and amount (7).

Perfect scenario.
 
> Generating plots of dimensional quantities will be interesting, but that's a
> bit down the road at the moment.  Does the above make sense?

I may think a bit of the last action though: whether we allow an identifier to
change its dimension. Say, what if I decide to "recycle" an identifier? Note
that x0 in (5) has the same TYPE as the rhs BEFORE assignment. It should be
legal, perhaps with a warning message, if the target dimension and unit do not
match those of x0.
 
 
> I don't think we want the "value" part of a dimension+nondim object to be
> workable as an individual object at all.  Adding 7 to it shouldn't be legal.

Certainly, the setValue function is still needed, but you may not want to export
it. In the example, I was pushing the "convenience" feature you have been
advocating. I am glad you don't want to push that far!

> I vote for just avoiding the whole situation by not dealing in anything but
> unit/dimensional quantities when dimensions are in play.  It's a bit sad to
> lose the convenience of being able to say s:=7*m but you finally convinced
> me.

Great. May be a future project is to modify the interpreter to allow s:= 7 [ft]
as syntactic sugar, once the foundation is done, correctly.

> We need to stay correct, but what I'm trying to do
> is make things as convenient as possible while remaining correct.

A very good ideal.


> I don't think we want to combine dimension/unit quantities with quantities
> whose dimensions or units have not been defined - are there scenarios where
> this is needed?

Not really, except for sloppy users.
 
> > 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]?
> 
> No, we shouldn't do that.  That wasn't what I was advocating - sorry if I gave
> that impression.

You did lead me into thinking about such scenario :-). But I am all for what you
now decide.
 
> > 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.
> 
> Right.
 
> > 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.
 
> I figured this scenario wouldn't work as I began coming to grips with your
> design - I don't think the above is possible, sadly.  

Yes, that would have made implementation much easier in the conversion part. (I
guess I have been "poisoned" by my Mathematica experience in implementing units
conversions).

> It would have to be
> done as follows, given the best setDimUnit definition I can see as being
> workable:
> 
>      s:= setDimUnit("Length","in",s)
>      t:= s + setDimUnit("Length","ft",7)
> 
> This would be legal, but the units of t, unless previously set, would be
> determined in this case by what the global default is.  (Probably meters ;-)

I think you have understood the design quite well.
 
> > > 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?

[snipped] 

> > I suppose the above is obsolete now?
> 
> I think you addressed that problem in the previous email, but we'll see when
> we get to coding :-).
> 
Yes, everything depends on how to coding goes! (especially when it comes to the
compiler). 

William