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

[C Y]

On Tuesday 06 September 2005 07:35 am, William Sit wrote:
> I have snipped without indication, a lot of the paragraphs that we agreed
> on.

No problem - I'm guilty of that too.

> s does not have to be a symbol, it may be an expression involving several
> symbols even though that maybe a bit "dangerous" and unusual. This allows
> the user who knows what he is doing to use what is known as an aggregate
> variable. Aggregate variables are used to simplify the number of variables
> in an equation and often very useful to understanding the interdependencies
> of variables, reducing the equation into a dimensionless form, or to a
> linear relationship between two aggregate variables. However, not all
> aggregate variables are dimensionless. The ideal gas law is such an
> (simple) example: PV/T = constant; so PV/T is an aggregate variable. The
> ideal gas law can also be put into the form PV = cT, where c is the
> constant. Using PV as an aggregate variable, it is proportional to T (and
> how coincidental, of reduced dimension Force*Length again and unit for
> example, liter-atm, and the constant c is not dimensionless.)

OK.  That sounds very interesting and may have possibilities for dimensional 
analysis tools like finding dimensionless constants.  (I need to re-read 
Barton Willis's docs for his Maxima package to remember what features he 
added.

> > So let's say I define some examples (sorry, I'm not up enough on Axiom
> > syntax yet to use it for this) would this be roughly how things would
> > work?:
>
> Your example below is basically the correct scenario. The syntax and output
> need some changes, given next. I added sequence numbers.
>
> > a::Length
> > b::Length
> > c::Force
>
> Since Length, Force, etc are not domains in my proposed setup, you cannot
> use the coercion symbol ::. Assuming you started with SI, you would have to
> replace the above three lines by:
>
> ->(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)

> ->(2) ub:= setDim("Length", b)
>
>        b [m]
>
> ->(3) uc:= setDim("Force",c)
>
>        c [kg-m/s^2]  or [N]
>
> > (4) setDimUnit("Length","cm", a)
>
> This would have the following output:
>
>       a [cm]
>
> Note that no conversion factor is used, since the expression a is entered
> afresh. The two identifiers a and ua are of different types. This suggests
> that we should add a new signature:
>
>      setDimUnit:(Dimension, Unit, %) -> %
>
> so that
>
> -> (4)' ua:=setDimUnit("Length","cm",ua)
>
>         a m2cm [cm]

Makes sense, except again I don't follow the need for ua.  Intuitively I want 
to be working with a, and ua is unnecessary - what purpose is it serving?  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?  

> > (5) setUnit("Length","m")
>
> This would set all declared expressions of dimension Length to use [m] as
> unit. Whether this is done retroactively or not is a design issue. We can
> provide both options with an added parameter.

I think your arguments for it being retroactive are compelling.

> > (6) setUnit("Force"", "N")
>
> Same, all expression of dimension Force use N as unit.
>
> > -> (7) a
> >                      a  cm                [Length]
>
> No: The use of 'a' will only return 'a', not 'a' with a unit. To get the
> unit, you have to use:
>
> -> (7)' ua

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

[snip]

> > -> (11) a
> >                      a cm2km  km        [Length]  (or would this stay as
> > cm?)
>
> -> (11)' ua
>
> The expression a was in [cm] or [m] depending on design (see (7)). Assuming
> you meant ua instead of 'a' in (11), your output assumes that no
> retroactive update in (5) but retroactive update in (10). There are four
> possibilities already.

Sorry if I got sloppy.  retroactive makes sense to me.

[snip]

> > > ---------- Implementation issues: Updating variables and their units
>
> Trouble is, neither the word "change" nor "set" provides a definite
> meaning. So I think it is better that setUnit or setUnitAll will change all
> instances retroactively.  As I already warned, just like when the unit of a
> single expression is changed (the setDimUnit, either version), the other
> alternative, changing only future instances will give rise to mixed units
> and a subsequent computation involving mixed units must be brought to a
> common unit system. What would be the unit of the result? I suppose the
> only meaningful unit is to the system's unit in the state vector. Thus, by
> making changes retroactively at the time a setUnit or setUnitAll is run, we
> bring the system back to uniformity earlier and hence subsequent
> computations are more efficient. Lazy evaluation does not pay if there are
> lots of subsequent computations, requiring conversion for each quantity
> involved, and with no place to hold the changes.

Agreed.

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

> > I agree - I would like to have a "strict" mode available which compels
> > the user to do this.  I fear making it the ONLY alternative will lose us
> > users though.
>
> By "us" you meant "USA"? I always remind my students the probe crashed on
> Mars was due to mixing up (or unaware of the mix up) units. I don't think
> user would mind including the dimension when setting units. It does help
> prevent typos from passing through.

Well, my guess is they will mind, but I agree they should do it.  I just hope 
the decision to enforce this rule doesn't make people decide to use Maple or 
some other package (on such small things do decisions hang, sometimes :-/). 
So be it - we'll go for enforced dimension awareness.

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

> As long as they are doing only number crunching, they won't need it. But if
> they have to solve for the optimal re-stock inventory strategy to minimize
> cost or maximize profits, they may need symbolic computation.

Sounds like something Walmart might be interested in.

> > > ---------- Implementation Issues: Setting up Dimension and Unit domains
> >
> > How about we allow the mapping to go through when it IS unique, and
> > return an error or ask a question if it isn't (something like provide a
> > list of options, and ask the user to select one)?  (Maxima has the
> > ability to ask questions of the user if it needs to - it makes some
> > problems MUCH easier to solve.)  This is helpful and friendly to the user
> > while still being fully correct.
>
> To a certain extent, that can be done. We discussed that already. However,
> Axiom does not seem to have the ability to ask questions of the user as far
> as I know. The graphics package allows mouse selection and controlling
> using the mouse, so I suppose that is a form of asking user input. But the
> 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.)

> > > However, the problem still
> > > is: given some unit in reduced basic dimensions such as
> > > (mass-length/time^2).length, say kg.m^2/s^2, we do not know if the
> > > dimension should be Energy (either Work or Kinetic Energy or Potential
> > > Energy) or Moment. Vectorizing some of these dimensions may help: Work
> > > is a force vector times a length vector, and so is moment, but the two
> > > length vectors have different directions with respect to the direction
> > > of the forces.
> >
> > Woo boy.  That's going to be a challenge to report - direction of length
> > vector as a factor in results.  Actually, that's an interesting question
> > - two length vectors may have different components, but the same
> > magnitude. Does the unit meter represent merely the magnitude, or the
> > vector information as well?
>
> The Length units are scalar units. Magnitudes are not necessarily length
> but they are also scalars. Vectors are given by its scalar components.
> Directions are given by unit vectors, usually in terms of directional
> cosines. There are formulae in standard coordinate geometry texts to
> compute projections of a vector in any direction (by using the dot
> product).

OK.  So in theory, if we vectorize the Units/Derived Dimensions, we won't need 
the idea of Reduced Dimensions?

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

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

> > > --------- User environment for Unit systems: Static vs Dynamic
> > Actually, that was more my idea - have the saveUnitSystem command pick
> > out all the most recent inputs that set the UnitSystem environment, and
> > save them to a file.  The trouble is to pick out such commands, which was
> > why I thought it might be simpler just to diff the "current" environment
> > from the "default" environment and autogenerate the minimum set of
> > commands to get from a to b.
>
> Well, the setUnit and setUnitAll commands can be tracked by the UnitSystem
> domain, and hence all it takes is to report the state-vector at the end of
> the session, or just to save the state-vector and reload it in the next
> session. Not a big deal.

Sounds good.

> > > --------------- Name space issues
> > >
> > > You  would have created a nightmare in using the interpreter by
> > > requiring users  to avoid any SI unit abbreviations as user variables.
> > > No computer language  ever has that many reserved words. Note: Axiom
> > > function names are NOT  reserved, but constructor (which may be
> > > category, domain or package) names and their abbreviations are.
> >
> > If we were talking about a normal computer language, I agree.  However,
> > in normal scientific usage, proper definition and use of equations should
> > NOT use SI abbreviations as variables.  Doing so creates far too much
> > potential for misinterpreting said variables later on.
>
> That is true, but we are talking about computing. In normal scientific use,
> most symbolic derivations or equations do not use units. The symbols do
> carry units occasionally, but equations never include units. An equation is
> always an equality for values, and homogeneous in dimension (which is not
> stated explicitly). So the chance of seeing something like m m (for m
> meter) is small.

I suppose - but I'm not sure what the use of this will be - scientific 
computing, or more traditional "working on problems in a notebook" style 
stuff.  I'd like to be able to do the latter as well as the former, and in 
the latter the convention would be to avoid using SI units for variables.  Oh 
well, I think it's pretty much covered.

> > I grant that your proposed
> > system has a far better chance than any I have ever seen or heard of of
> > making this workable, by being able to separate out m the variable and m
> > the unit in the output even if they look the same to the human eye -
> > e.g.:
> >
> > (1)-> 3*setUnit("Length","m","m")
> >
> >                                           3m m
> >                                                                     
> > [Length]
>
> This works, if you give the right syntax:
>
> -> (1)'    3*setUnit("Length","m",m)
>
>                   3m [m]

OK.

[snip]

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

> > > ---------- Implementation Issue: Simplification of dimensions
> > >
> > > Perhaps we can add a field to Rep that gives the reduced dimension as
> > > well? or provide a function
> > >
> > >   reduce: Dimension->Dimension
> > >
> > > (which in any case, will be useful and necessary).
> >
> > Yes, I think so.  Is the concept of reduced dimension defined anywhere?
>
> I am not a historian. This can't be a new concept, but may or may not have
> been formalized. May be the book "Theory of Dimensions" had it.

Hmm.   OK, I'll have to do some digging.

> > Without doubt scientific units will be the most useful in the short term.
> > Building scientific symbolic computing on top of Axiom is going to
> > require, as near as I can tell, three things:
> >
> > a)  the concepts of Dimensions and Units (underway)
>
> Good.

Well, underway in design phase anyway - I'm still getting a handle on your 
design ideas, it seems :-/.  Hopefully my skull will prove to be of finite 
density, and ideas will filter in eventually.

> > 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)
>
> This is a totally different domain, involving interval arithmetic, for
> example. I don't know what error analysis packages or numerical packages
> have been implemented in Axiom. While they are important, I suspect most
> people are so used to very high precision computations they ignore to the
> accuracy of the raw data.

Not in proper scientific measurement and data analysis.  It is a totally 
different domain from units, but it is one of the foundations of experimental 
science and will be needed for any intelligent handling of results from 
experiments.  In introductory physics labs (at least the ones I helped teach) 
the two first concepts people are introduced to are units and errors (and I 
might add, they are the most common areas where points are lost in subsequent 
labs :-/).  Any definition of physical constants (which have to be measured, 
after all) will require incorporating information about the accuracy of the 
measurement of the constant, to preserve the full meaning and utility of the 
definition.

Error Analysis is something I have been told cannot be automated, and I accept 
that to a point, but only to a point.  Fundamentally, if it is a 
deterministic and reproducible process to find the real uncertainty on a 
calculation, given enough information about the system in question it has to 
be something that can be reduced to a set of routines.  It might mean that 
the user will need to supply more information about the system to the 
computer than they usually think about explicitly, but it's like being forced 
to define dimensions for all units - if the user doesn't know it, they don't 
know enough to be sure of using it properly, and correct application can (and 
often is, I suspect) a matter of not happening to violate assumptions being 
made unknowingly.

Since this is separate from Units it can come later, but I regard it as 
fundamental for establishing a truly robust basis for scientific computation 
in Axiom.  Indeed, in some sense Axiom might ultimately provide a bridge 
between pure mathematics and the physical sciences, making explicit the 
mathematical tools and assumptions used to "get the job done" in the 
mathematics of physics, chemistry, etc.  

> > c)  Domains of significance.  

 [snip] 

> > OK, enough pie in the sky talk :-)
>
> That what I think it is! I guess such generality will only be useful to
> those who work in the area of transition between Newtonian and Quantum
> (don't even know if that make sense). Maybe you are dreaming of the grand
> unification theory and implementing that in Axiom?

Not a bad idea, actually :-).  But, for instance, what IS the definition of 
the "transition region" between Newtonian and Einsteinian behavior in 
descriptions of velocity?  How do you know when you should be using one and 
not the other?  For some cases it is easy, but in the intermediate range it 
is not so simple.  There are borderline cases where uncertainty in 
measurement and relativistic effects are the same order of magnitude, 
although admittedly offhand I don't know how many experimental systems are in 
that range.  These are the types of questions I would sometimes ask myself in 
Physics classes - I would like to have a system that kept track of such 
issues automatically for me when I was doing "real work."  Not that I do much 
of that in physics these days, of course...

I would like to ultimately use a proper Units, Uncertainty, and Error Analysis 
system in Axiom to begin building scientific mathematics on top of it.  Maybe 
it wouldn't be very useful, I don't know.  But, for example, Feyncalc in 
Mathematica is widely used.  I can't help thinking that implementing it in 
Axiom, on top of a Units and Error system which would allow for things like 
plugging in the latest experimental particle accelerator results directly 
into theoretical HEP equations to see if things make sense and are 
significant would be a very exciting and useful tool.  Maybe not though - 
it's been a long time since I was in physics in any significant way.

> > Night all, and thanks William as always
> > for your patient, helpful and amazingly powerful ideas and thoughts.  I
> > hope mine aren't being too tiresome - I think I'm finally beginning to
> > see the light, although I'm afraid we might have a bit more than three
> > set* commands when we get done.  (Derived Dimension simplification rules
> > in SI will require a few more commands, based on my Maxima experience,
> > and that didn't have anywhere near the flexibility this will have.)
>
> You are welcome. Yes, there will be way more functions specified in the
> UnitSystem category. We have discussed the may functions, but there will be
> support functions, which are not too hard to implement and can be added
> quite naturally.

True.

> I look forward to seeing this becoming a reality. It has been quite an
> interesting discussion.

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