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

[William Sit]

C Y wrote:
On Tuesday 06 September 2005 07:35 am, William Sit wrote:
> > ->(1) ua:=setDim("Length",a)
> >
> >        a [m]
> >
> > Note that the unit is output using a pair of brackets, to avoid confusing
> > it with a variable m, perhaps. Also, the type of ua is now SIUnitSystem(S),
> > if the type of a is S.
> 
> I'm afraid I don't quite understand this part.  Why is ua needed?  I wanted to
> assign a dimension of Length to a, such that typing in a results in the
> following:
> 
> ->(1) setDim("Length",a)
> 
>            a [m]
> 
> ->(2)  a
> 
>            a [m]
> 
> Is this not possible, or did I miss another subtle design issue? (probable)

Axiom is a strongly typed language, which means that if you change the
representation of something, it will belong to a different type (or domain). The
two are distinct objects, even if in some sense, they are mathematically the
same. You cannot substitute one for the other without some sort of coercion, if
that is possible at all.

Thus SIUnitSystem(S) is not the same as S, because objects in S has no units
attached (purely mathematical objects, usually). Attaching a unit to an element
s in S immediately takes the result out of the domain S, into the new domain
SIUnitSystem(S). Sure, we can retract the result back to S, but then it will
lose its unit! So if you look at the signature of setDim:

     setDim: (Dimension, S) -> %

The % is SIUnitSystem(S) in our example, in general, it is any domain in
UnitSystem(S) category. Say if s is just a symbol, then the result of
setDim("Length",s) would be an object with Rep

    Record(value = s, dim="Length", unit="m", etc)

whereas the Rep of s in Symbol is simply s itself (probably just a string "s" as
name, or even some hash code). The display s [m] is the display for this new
object. If you do not assign the result to a new variable, say sWithUnit, then
this object is "lost" immediately (although Axiom has a way to recall results in
a session). So one has to assign it to use the new object again. The statment
setDim("Length",s) does not change s at all. It does not add a unit to s. It
creates a new object whose outputform is "s [m]". In fact, you can even assign s
to two different units in the same session, if s happens to just provide the
value for two quantities with different dimensions. So s as an element of S is
dimensionless, and only gain dimensionality via the setDim command. This is not
that uncommon in the real world. We had the example even with the mathematical
constant %pi, with two dimensions in two equations.

> I
> can see setDimUnit refusing to work on an actual number (e.g. setDimUnit
> ("Length,"cm",4) ) without being assigned to a variable, but surely this
> restriction shouldn't apply in general?

This has nothing to do with whether s is a number or a symbolic expression. The
"ua" is required because of types. Unfortunately, while you can retract "ua"
back to "a" because the value of "ua" is "a", you cannot coerce "a" into "ua".
(The quotes are just to separate it from the text, not to be meant as string
deliminators).

> 
> I think your arguments for it being retroactive are compelling.

So we agree on another design issue. Making progress.

> > -> (7)' ua
> 
> Same question as to why ua is needed.  Also, are you quoting ua, i.e.  ' ua?
> Or is that my mail client?

The single quote was really a prime; I was simply labeling the command as (7)';
may be I should have used (7').  A quote would have no space between the quote
and the symbol.

> > I see, you want to set the units for multiple dimensions in one statement.
> > We can do that easily by allowing:
> >
> >     setUnits: (List Dimension, List Unit) -> Null (or state-vector)
> 
> Sounds good.

In Mathematica, one can set the attribute of a function to be Listable. In
Axiom, one has to explicitly create a new function, but one can use the same
name.

> So be it - we'll go for enforced dimension awareness.

Good, we have fewer and fewer differences.

> > > Yes, I think we might want to do something like that - it would allow (or
> > > would it?) the possibility of a UnitConversion category with domains for
> > > PhysicalUnits, ComputerUnits, EconomicUnits, etc.
> >
> > That is the idea. However, there is some technical difficulty that I do not
> > yet know how to solve, but I think it is doable:
> >
> >     UnitConversion(dim:List String, unit:List String):Category == ...
> >
> > Trick is to convert dim and unit into arguments for the constructor Union
> > so we can form
> >
> >     Dimension:=Union(dim)  -- right now, syntax error
> >     Unit:=Union(unit)
> >
> > There must be a function in Axiom to do that. I just don't know. Here Union
> > is expecting a tuple of domains. In Union("Mass", ...), the strings are
> > magically turned into domains.
> 
> Any Axiom gurus that can help us on the above point?

I left the above in, just hoping someone will know how to do this. It is really
a very simple thing. The information (strings for the dimensions) is in a list.
Why can't we feed this to Union without the list wrapper? Axiom allows commands
in Lisp, and so someone who knows Lisp (Tim, Bill, Camm) should be able to
easily write a line to do that. In Mathematica, one can replace the "Head",
which is "List" for a list, by another function using "Apply", such as
Apply[Plus, {1,2,3}] would produce 1+2+3=6. Surely Axiom can do that too -- but
note Union is not a traditional function, but a domain constructor expecting
domains as arguments.

> > > > ---------- Implementation Issues: Setting up Dimension and Unit domains

> > Interpreter interface does not even support the mouse. (Anyone wants to
> > pick up this challenge?)
> 
> Hmm.  I'll add my voice asking for this option/feature - it made Maxima many
> times easier to use on a variety of problems (in Maxima, for example, the
> integration routines would ask the user if things were positive, negative, or
> zero in order to limit the amount of work and provide a unique answer.  I
> wish I could remember the example that I wound up using in Solid State
> Physics once.)

I think Axiom's design philosophy (one of these) is to have as few (none?)
interaction with the user as possible so that functions can be fed into other
functions for automatic execution. With functions requiring interaction, you
can't do that. Graphics is a big exception, but any graphics done by interactive
manipulation can be done in batch mode as well.
 
> OK.  So in theory, if we vectorize the Units/Derived Dimensions, we won't need
> the idea of Reduced Dimensions?

I don't think so. The newly discovered example that PV (Pressure times volume)
also has reduced dimension of energy shows that the problem occurs for scalar
quantities already. But the idea to handle vectors with dimension is still one
worth investigating.

> > > How do we represent vector information if we want to preserve it
> > > through the process of reducing dimensions?  The Work vs. Moment example
> > > would seem to argue that vector information and Dimensions can't really
> > > be separated, but I don't really know if I'm interperting that right.
> >
> > That is right. Well, like it or not, physicists use lots of vectors and a
> > unit system should really support vectors. This can be done componentwise,
> > but the system has to be aware of how to obtain derived units when vector
> > calculus is applied! With symbolic computation, we can talk about vector
> > functions, differentiation, integration, etc and all these computations
> > change the units and dimensions.
> 
> Ho boy.  This is going to be a loooong pamphlet file ;-).

Don't forget the dot product, cross product, gradient, curl !

Looks like the discussions will continue. Tim has the idea of a pamphlet book,
so don't worry about the length.
 
> > The proposal allows a UnitSystem to be parametrized by a set S, and this
> > set S can be a set of vectors or vector functions. So when coding say
> > SI(S), for arbitrary S, one has to do cases when S has Vector, etc. Hehe,
> > may be you can get a ph d for this project!
> 
> Heh - that'd be cool, but for that I'd have to be enrolled somewhere and
> actually be a student again, and I doubt I'd ever get this across as a thesis
> topic :-).  Dunno where I'd get funding from :-/.  Sure would be interesting
> (and fun!) though.

Funding is a real problem, and you're probably right, who would think unit
system is doctoral material? After all, it's just arithmetic!
 
> 
> > > > --------------- Name space issues

> > Yes, that is probably much harder than providing arithmetic on strings.
> > Besides, we only need to provide multiplication and division. But I think
> > it is doable in Axiom. These local variables are not really visible to the
> > Interpreter user directly. The user may still have to use setDimUnit,
> > setUnit, etc. The separation is via the Rep already and the output can turn
> > them into strings. The problem is they are still symbols and so still
> > restricts the namespace of the domain, but that is much better than user
> > namespace because the author for the domain can avoid any potential
> > conflict. The danger is in future updates of the code;  the person updating
> > may not be careful enough to avoid the reserved names (like adding some
> > units that turn out to be one of the local variables). Strings avoid the
> > problem altogether.
> 
> OK.  Any introductory tutorial on units in Axiom will need to make it clear
> that units are not normal variables, and explain how things work, but I think
> it should be doable.

Which do you mean? Using local (domain) variables, or using strings?

> > > > ---------- Implementation Issue: Simplification of dimensions
[snipped]
 
> > > b)  Significant Digits, Uncertainty in Measurement, and Error propagation
> > > (hard, both in itself and also since potential errors due to the
> > > numerical calculations of the computer must also be considered in order
> > > to be rigorous)

[snipped]

I agree totally with your view that scientist should know about uncertaintly in
measurement and be able to do error analysis of any computation they do . But
that is for "scientists" (in the sense of physcial sciences). A lot of
measurement are not of that nature, such as statistical measurements, or
processes that involve a lot of randomness such as economics, or weather, It
would be difficult to carry out every computation with an error range.
THe problem is not the computational error analysis, which can be automated
using techniques in automatic differentiation perhaps (applying chain rule to
propagate the error computations as differentials). The problem is in the
determining the accuracies of the input measurements.
 
> I'll try and begin structuring the emerging design into some kind of pamphlet
> file, although filling in the code will be a project in and of itself :-/.
> Oh well.  I'll see if some good can come out of all this by remembering all
> of my beginner questions and try to write the pamphlet in a way that
> addresses the reasons for doing things this way and not another, and defining
> concepts I had a hard time with.  If you're interested William I can send you
> a draft before dumping it on the list/wiki, since it is close to certain my
> first attempt will need a lot of tweaking, polishing, and rewriting.
> 
> Cheers,
> CY

No problem and I'll be glad to help out. In any case, if it is on wiki, it will
get modifiable by readers too!

William