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

[C Y]

On Sunday 04 September 2005 01:22 am, William Sit wrote:

> ---------- General discussion on documentation
>
> C Y wrote:
> > --- William Sit <address@hidden> wrote:
> > > you have already started real work.
> >
> > That's probably too generous - I've started trying to become informed
> > enough to start real work, really.  Bill is probably going to flinch
> > when he sees my idea of basic pre-code (heck, it's really pure
> > background) documentation :-).
>
> Tim will love you!

Well, we'll see - it's way more of a challenge that I thought it would be 
originally!  (Which I guess is what Axiom is all about, in a way :-).)

> > I hope so, although I suspect your ideas are far more useful than my
> > own - I'm just asking questions and swatting user level features around
> > in my head at this point.  The hard part (and interesting part) is
> > expressing them in relation to Axiom's mathematical rigor.
>
> You are welcome to ignore or include in your work/paper any ideas I
> presented on this forum.

Thanks!  (Of course, that presupposes I can work my head around them... ;-)

> The hardest part is knowing questions to ask, and second is figuring out
> the answers; the easiest (though by no means trivial) is to code the
> solutions.

Well, that's the sign of using the right method of problem solving, at least!

> ---------- Basics of the proposal: Representation of UnitSystem domains
>
> This comment of yours is based on your breaking up UnitSystem into Static
> and Dynamic Unit System. This is certainly possible, but see my comments in
> the section on Static vs Dynamic user environment, which will list some
> pros and cons on this break up.

OK, will discuss later.

> > I think the latter is a matter of convenience - converting relative to
> > the current system is also doable via input unit -> SI -> output unit -
> > if I understand you what you are doing is precompressing this two step
> > process into one for the default "output" system?
>
> The relative factor can either be built-in for the UnitSystem domain, or
> via the SI mechanism. But we have to remember that SI is not universal
> (supermarket manager example). So a relative factor setup solves the
> general situation and is also more efficient. The SI approach is mainly for
> scientific applications AND conversion between two drastically different
> systems. Believe me, in less than 30 years, symbolic computations will be
> used by economists, if not already. (Mathematica has an operations research
> package, sold separately).

Hmm.  OK, I'll go along with that.

> Yes, I am more in favor of every UnitSystem domain being dynamic (again,
> see that section). As to shortening the Rep, yes, in principle, for
> "scientific" unit systems, it only needs a conversion factor relative to
> SI, and yes, for static unit systems, the relative conversion factors are
> not needed either. However, SI is not everything, so the relative factors
> will be needed in those cases, and SI may be replaced by another standard
> unit system.

OK.  The concept of an "Information" dimension, (i.e. whatever underlies the 
concept of bytes as a unit) convinced me of that.  Neither SI nor the seven 
physical Basic Dimensions are sufficient.

> C Y wrote:
> > This is definitely interesting, but I'm not sure we want such an ability
> > to be the default - I would suggest hiding the conversion factors unless
> > the user specifically specifies otherwise.  I like the idea of the
> > ability to explicitly show them though :-).
>
> What you meant then is to have something like:
>
>     setSymbolicConversion(): Boolean
>
> as default True, which will include symbolic conversion factors. Setting
> this False will use numerical values. However, if you meant that when I
> setDimUnit("Length", "cm",x) and x was in "m" originally that it will
> output only x [cm] instead of x m2cm [cm], then I don't agree.

Oh, I think I get it - you're discussing the case where the user does the 
following:

a)  assign a variable (call it "x") not only a specific dimension but also a 
specific unit.  (I expect this to be somewhat unusual but it should be 
legal.)
b)  either the unit assigned was different from the current global, or the 
current global is changed.  Now when "x" is evaluated that unit must be 
converted.
c)  we want to show that conversion descriptively (or have the option to).  
Agree.

What I was thinking about was probably setDim("Length", x).  My mistake - you 
were thinking further ahead than I was.

> ------------ Basics of the Proposal: UnitSystem domain specifications
>
> The following addresses only the user interface specifications under
> discussion and is not a complete specification for the category:
>
> C Y wrote:
> > I don't quite understand s:S - can you give a specific example of this
> > difference?  Also, I'm not following why you would want to make any
> > local vs. global distinctions here - wouldn't it be neater just to have
> > the set commands work in the CurrentUnitSystem, and base things off of
> > Static UnitSystems for definitions unless a totally custom conversion
> > is being defined?
>
> In the setDimUnit, 'setDimUnit' commands, an expression s:S is involved,
> where S is a domain that usually contains symbols ("RetractableTo Symbol"
> in Axiom jargon) and s:S means s is such an expression. 

OK.  So in words, s is some specific symbol defined in the domain S.

> Of course S can be just Float if no symbols are involved, in which case,
> expressions and  variables are simply constants.  But the user assigns a
> dimension and unit  to an expression, which will change the way certain
> variables involved in  the expression are inputted or outputted. This
> setting is for a specific expressions s, so has "local" scope. 

OK (I think.)  

> The other 'setUnit' is local for a 
> specific dimension, but has a wider scope and affects all expressions of
> that dimension. Finally, the 'setUnitAll' is global in the sense that all
> derived dimensions involving that specific dimension and all expressions in
> all those derived dimensions will be affected. The implementation will be
> assisted by the UnitConversion domain and the Rep remembers the conversion
> factors both relative to the current system and to the SI system, when
> possible.

I think I've got it - so there are three levels:

a)  change properties within a single expression, don't change global settings
b)  change global settings for one dimension, but not for other dimensions 
building off of this one
c)  change global settings for ALL dimensions using this dimension - e.g. the 
default rendering for force would become kg*cm/s^2 if 
setUnitAll("Length","cm") were used. 

> My proposal allows (but the decision is still open) changing the units for
> a single expression s:S -- 'setDimUnit(dim,u,s)'. It also allows changing
> the unit of a single dimension, say Length, in the current (loaded) unit
> system without affecting other derived dimensions that involve Length --
> 'setUnit(dim,u)'. Finally it allows changing the unit of a single
> dimension, say Length, and any other derived dimension that involves
> Length, such as Velocity -- 'setUnitAll(dim, u)'. 
>
> In your example above, changing the unit of Length 
> from "m" to "cm" will report the unit of Force (the dimension of "N")
> either still as "N", if 'setUnit(Length,"cm")' is used in SI; or as
> kg-cm/s^2 (by changing the value of any expression with dimension Force by
> a conversion factor m2cm), if 'setUnitAll(Length,"cm")' is used in SI; in
> which case, the new unit of "Force" is "kg-cm/s^2" or "kilodyne", following
> SI prefix convention (basically changing SI, which is MKS based, to CGS).

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

a::Length
b::Length
c::Force
setDimUnit("Length","cm",a)
setUnit("Length","m")
setUnit("Force"", "N")

-> a
                     a  cm                [Length]
-> b
                     b  m                  [Length]
-> c
                     c  N                  [Force]

setUnitAll("Length","km")

-> a
                     a cm2km  km        [Length]  (or would this stay as cm?)
-> b
                     b m2km  km         [Length]
-> c
                     c m2km  kg km / s^2     [Force]  (with better formatting)

setUnitAll("Time", "millisecond")

-> c
              c m2km s2ms^-2  kg km / ms^2     [Force]

[snip]

> Each expression requires one lookup at the
> time its dimension and unit is set. All subsequent uses and display will
> avoid the lookup again even if, in case of a variable, it is reassigned to
> a different value. All necessary conversion is taken care of by the
> arithmetic operation in the UnitSystem domain.

OK, I think I like this.

> > Does that mean an interpreter update is needed.?
>
> I hope not! The 'update()' function can handle that. We should not modify
> the Interpreter for this project unless it is absolutely necessary, which
> so far, I don't see. It is possible for the 'setDimUnit' function in the
> UnitSystem domain to record all calls to the 'setDimUnit' command to create
> and maintain a live list of variables or expressions, say as part of the
> state vector. An update can either be applied for just one variable in the
> domain, or all variables in this live list.

OK - so long as these things can be handled automatically (I had to hack in a 
mechanism in Maxima to do autoconverting globally.)

> ---------- Implementation issues: Updating variables and their units
>
> Some updating questions are raised and solutions suggested in the Scenario
> Example section above.
>
> > As for current variables, shouldn't they be updated automatically by
> > the global update?
>
> That is the idea. That is, a 'setUnitAll(dim, u)' command will change all
> output and input variables/expressions that are of dimension dim to use
> unit u. In the scenario Example section, we discussed the issues and some
> possible actions. The basic design question to decide is: should this
> global command affect only newer variables/expressions or should this
> retroactively set all existing variables/expressions? The basic
> implementation question is: what data structures will support these
> functionalities efficiently (bear in mind some trade offs between memory
> and CPU time, as usual)? It seems the proposed state-vector can support the
> implementation, whatever the decisions.

I think I would vote for retroactively setting all non-derived unit using 
instances, with perhaps another command to make this change without updating 
previous instances.  (How about setUnit is retroactive and changeUnit is from 
this point forward?)

> > I would have thought all you needed was a single command SetUnits()
> > command, which would take a minimum of one argument and a max of one
> > unit per available dimension, e.g.
> >
> > SetUnits(nm,N,inches);
>
> [NB, Axiom convention:function names should start with lower case]
>
> I do not quite follow. Your example has three arguments, all units of
> Length.

Not quite - N is force.  That was a mistake on my part - I meant something 
like setUnits(g,N,inches).  The above should have (and does, in Maxima) 
return an error.

> I think you are thinking of 'setUnitAll(dim, u)'? Maybe a simpler 
> 'setAll(u)' and let the system figure out the dimension of u? (But as
> explained below, this reverse lookup from unit to dimension is not unique;
> in that case, we can make 'setAll(u)' return an error message with some
> choices (probably not all possible choices). So you would still need the
> version 'setUnitAll(dim,u)' after the user picks one of those choices.

Yes, I understand your scheme better now.

> Your line:
>
>   SetUnits(nm,N,inches);
>
> is, as far as I can follow, a global set. 

In Maxima, I think this works as a global setting (retroactive) of all 
non-derived instances of a dimension to a new length - essentially the same 
as doing 

setUnit("Mass","g")
setUnit("Force","N")
setUnit("Length","Inches")

but letting Axiom figure out that g is a unit of Mass, N is a unit of Force, 
and Inches is a unit of Length.

> Surely, in this simple example, 
> Axiom can figure out that these (nm, N, inches) (aside: use "in" for
> "inches" -- SI recommendations) are units for Length, but as explained,
> this is not possible in general. My version 'setUnitAll(dim, u)" only does
> this for a particular dimension dim and a particular unit u. I don't know
> why you set the Length dimension to THREE different units.

Typing error ;-).  I meant to set the unit of three different dimensions.

> Are you  imagining mixing units for the same dimension in one session? 
> How are you  going to tell which variable/expression will use any one of
> these three units? Are you saying that ALL three units should be reported
> for ANY variable/expressions of dimension Length? (Note: even if you are
> mixing  units, the Rep will support it. I just want to know what your line
> meant.) 

The line meant I was sleep deprived ;-)  Hopefully round two makes more sense.  
The potential to report a single quantity in a list of different units, one 
converted quantity to a list entry is interesting but not really what I was 
after.

> Fair enough. We can ALWAYS add defaults. The example I gave in my last
> message (added above in Section on UnitSystem specification):
>
>    setDim(dim: Dimension, s:S):% == setDimUnit: (dim, unit(dim), s)
>
> performs a lookup for the default unit for a given dimension in the current
> UnitSystem. The 'setAll(u)' above can handle cases where an automatic
> lookup results in a unique dimension to set the dimension field in Rep.
> However we do not want to look up repeatedly each time we use a variable,
> so the results are memorized in Rep.

OK, that should do it.

> And, yes, users should know the dimension of the unit they are inputting.
> One danger with something like 'setAll(u)',  which left out the dimension
> for u, is that a simple typo say from 'setAll(cm^2)' to 'setAll(cm^3)'
> would not be caught and play havoc in subsequent computations. Forcing the
> user to give the intended dimension provides a better chance that these
> errors will be caught.

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.  

> > Maybe as a time saving alternative SetUnits could also
> > accept things of the form <UnitSystem>::Unit or some such, which would
> > limit the search space it would need to check?
>
> I don't follow the syntax of <UnitSystem>::Unit. Is :: coercion in Axiom? I
> have not heard of coercing a domain into a category. Perhaps you are
> thinking of a package call to a domain in UnitSystems? That would be
> setAll(u)$domain. But I do not like this default setAll(u) for reasons
> above.

Uh, nevermind.  I didn't understand your proposal as thoroughly as I needed 
to.  I meant to say one could say something like setUnit("SI/cm") or 
setUnit("SI->cm")  or whatever makes sense.

> > Or even better, if
> > Axiom is up to it we might also be able to build a toplevel hash table
> > of all defined units in all unit systems at compile time which can
> > quickly match up a unit up with a UnitSystem and Dimension.
>
> The UnitConversion domain (perhaps category) is for this purpose. I am
> still thinking about whether UnitConversion should be a category with many
> domains or just one domain. The many-domain approach may provide better
> efficiency for more localized conversion systems and flexibility future
> additions.

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.

> As we don't know all the expert areas now in existence, nor do we know what
> new derived dimension or unit we may need (especially in 30 years' time),
> there is no way we can have such a universal toplevel hash table. We CAN
> implement SI (all the default and acceptable dimensions and units) or even
> more, but such a domain will need to be revised to allow newer dimensions
> and units. The design proposed will allow this of course (any design in
> fact), but I still subscribe to the older Axiom philosophy that we do not
> modify existing libraries except for bugs, and extend existing libraries
> through additional implementation. We should allow arbitrary UnitSystems
> (as I also indicated in my last email, supermarket manager will need a
> totally different, "non-scientific" unit system with dimensions like
> "Coke", "DietCoke", etc.)

I agree.  I'm really curious to see if something like this ever gets used in 
such an application :-).

> ---------- Implementation Issues: Setting up Dimension and Unit domains
> C Y wrote:
> > Dimensions
> > may not always map uniquely to Units, but Units DO map uniquely to
> > dimensions.
>
> Your last remark is wrong, unless there are already standard terminology
> such as in the case of Work vs Moment: standard energy-units exist as
> Joule, erg, eV, etc. and moment-units exist as N-m, etc. 

Ah, point.  Darn.

> In other cases, 
> you may have to create new standard names first. 

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.

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

> --------- User environment for Unit systems: Static vs Dynamic

> All Axiom variables are typed. So once a user started computating using a
> UnitSystem domain, say A, all his computations will be in that unit system.
> If he then change to SI, he would have to coerce them to SI, which may or
> may not be possible, depending on what dimensions and units are in A. (So,
> the domain A, and the UnitSystems category, may have to include functions
> like convertIfCan: % -> SI).

Hmm, good point.

> I think you want somehow to restrict some users (say students who are
> learning about units and dimensions) not to allow them to "mess" with a
> UnitSystem domain like SI. I don't see the necessity because most likely,
> such users will only want to do their computations in whatever unit system
> is the default. Even if they were to use 'setDimUnit', 'setUnit', and
> 'setUnitAll' (which would be a good experience), these only affect the
> interpreter session and will not modify the SI domain at all. The
> state-vector does not survive an axiom reload since no modification to the
> compiled code is performed. 

Ah, OK.

> Also a user can save the history of all inputs, 
> including all 'set' commands (and also ')set' commands) and put them in
> axiom.input or a 'myunitmod.input' and read it in anytime. There is no
> need, in this dynamic design, to modify ANY compiled domain in the
> UnitSystem category. When a user wants to have modification compiled into a
> modSI domain, he will have to edit the SI.spad.pamphlet and change it into
> modSI.spad.pamphlet and compile it. However, I don't see the necessity.
> Your idea of
> 'SaveUnitSystem(<newUnitSystemName>) is difficult (but not impossible) to
> implement and involves automatically editing say SI.spad.pamphlet to
> modSI.spad.pamphlet and automatically compiling it. It is trivial for a
> user to read in an input file instead.

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.

> I note that each of our positions on this user environment issue has turned
> 180 degrees from earlier communications :-).

Hehe :-).

[snip]

> Requiring rebuilding the hash tree is not a good idea because a domain is
> supposedly stable once built. Plus, if someone adds a new UnitSystem
> domain, who would be responsible to rebuild the single hash tree? If the
> new domain introduces new dimensions and units, it should create a
> corresponding UnitConversion domain (hash tree) and leave the standard hash
> table alone.

Hmm.  Yes, a hash tree makes sense only when polluting the namespace.

> --------------- Name space issues
>
> > (I'm still
> > plotting to allow the user to gobble up all the unit names in the
> > default namespace at their option, and that will DEFINITELY need
> > interpreter work.
>
> As you know, I am strongly against "gobbling up all the unit names in the
> default namespace' even if it is 'at their option'.  If you are seriously
> thinking about student use, you know the average students will exercise
> their options without knowing or understanding what they are doing. There
> is no way to consistently reserve SOME unit names in namespace, and not
> others. Any code to implement this will have to know the reserved names a
> priori and that means ALL the abbreviations in SI units at a minimum.

Right.  Reserving some would be worse than none, because it would be 
inconsistent.

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

If this can actually function, then I am for it because it would be a 
virtually ideal solution, and it is more general in case other, non-physical 
unit cases need that generality.

> Modifying the interpreter because of a specific category or its domains is
> a bad idea. Any modifications should be general purpose or fixing bugs.

OK.  That I agree with.

> Most users
> will want to have more flexibility. I think even for student use, if they
> want to experiment with changing units (at run time), why should that be
> forbidden? (for that matter, Axiom being open sourced, why should ANYTHING
> be forbidden?)

Well, I might answer "encouraging correct and best practices" but that's only 
a good argument for defaults and utilities, not coding in limitations.

> There is perhaps one way to use variables (instead of strings) for
> dimensions and units, but they will be local to the domain (using domain
> namespace, rather than user namespace) and they will not be assigned any
> value. The advantage over strings is that they can be used to perform
> arithmetic operations of multiplication and division as symbols. Then
> general conversion factors can be computed by setting up a small number of
> conversion rules and by solving an equation.

I'm beginning to see how this might work - visually speaking though, it hinges 
on the robustness of Axiom's separating units and non-units in output.  I 
think Axiom might be able to do this in a way most other systems couldn't (at 
least not without a lot more work).

> Default relationship (tables) for conversion tables (which include both
> dimensions and units) and the dependencies like state-vectors, can use hash
> tables.

Or whatever is easiest/best.  I don't know offhand that hash tables are.

> ---------- Implementation Issue: Simplification of dimensions
> C Y recently wrote:
> > OK - so how to we represent this in a  CAS?  Or more specifically, what
> > about the fact that a dimensionless constant has dimension that cancels
> > is useful for us to display, and how do we go about it?
>
> We can do this:
>
>   piInEqn1:= setDimUnit("Length/Length", "m/m", %pi)
>
> or
>
>   piInEqn1:= setDimUnit("1", "1", %pi)
>
> but
>
>   piInEqn2:= setDimUnit("Degree/Radian", "deg/rad", %pi)
>
> 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?

[snip]

> Yes, unless given other examples, I think this is a way to get out of the
> dilemma. Of course, the strong typing of Axiom already drove developers
> nuts, and I'm afraid, surely, the strict setup to dimensions and units may
> likely do so to scientists or economists. This is the price to pay for
> insisting on formal correctness.

Perhaps not as bad as I originally thought, but the documentation for use will 
be critically important.  Perhaps that is an argument to continue work on the 
much less correct but perhaps friendlier in the short term Maxima units 
package, which I see now is focused exclusively on Physical Units.

> > > >Could unit and dimension cancelation be handled
> > > >on a per dimension basis?
> > >
> > > May be, or may be not. It depends on the physical meanings of the
> > > variables. If I have price at $5/m multiplied by 7 m, I should get $35.
> > > If I have 8 N divided by 2 m^2 for pressure, and N has dimension
> > > kg-m/s^2, is it ok to cancel one of the m? So a single rule of Length
> > > (m) is not applicable to all cases.
> >
> > This will need to be handled, somehow.  Are there any good references
> > that contain the applicable rules for us to implement?

[snip interesting references]

> Whether any such references will help us develop the rules to simplify
> dimensions, I don't know. From what we have discussed, it seems any rule
> will need some expert knowledge (in the example I gave, the expert
> knowledge is simply what pressure is). So I believe the best solution may
> be to "leave it to the users", and let them create their own names and
> simplification rules. 

Sounds good. How about as good setups are created we merge them into Axiom?  
Perhaps Axiom will become the central repository for advanced unit 
interaction rules, as people build off of the (hopefully) sound foundation of 
Axiom?

> This means that in a UnitSystem domain, there ought 
> to be facilities to handle rules of simplifications, where some common
> defaults can be implemented. Axiom has a RewriteRule domain that can help.
> RewriteRule can also be used efficiently to perform conversion. (I once
> wrote a UnitConversion.nb in Mathematica for a course using this idea: all
> conversion factors between the two units for the same dimension is then a
> simple Solve[unit1 = x unit2, x])

Hmm.  Worth some thought.

> > You mentioned $ interacting with meters, and in a previous email kilobits
> > and kilobytes were also mentioned.  Unfortunately, neither money nor bits
> > of information are covered by any combination of SI units I am aware of. 
> > So perhaps our top level category should be not simply Dimensions but
> > PhysicalDimensions, and we could perhaps implement some other Categories
> > for Dimensions not covered by SI (like money and bits, both of which are
> > Basic Units as far as I can tell).  Money might be defined in terms of
> > other things in some sense, but that definition is as complex as society
> > itself and ever changing.  Fascinating issues, but perhaps those should
> > wait for later. Indeed, does it even make sense to include a concept like
> > money in a system intending to stick to strict mathematics as much as
> > possible?  I suppose yes since we can think of practical uses, but
> > thinking about it is making my head hurt ;-).
>
> "Now, you're thinking!" :-)
>
> In my case, thinking about these things make me stare at the screen and
> then fall asleep! But you got a point here, building unit systems should
> include, or at least allow future inclusion, of systems outside of the
> usual scientific sphere. So having an WallStreetDimensions,
> SupermarketDimensions, FontsMetricDimensions systems would be fun 
> but we don't have to implement them right away.

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)
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)
c)  Domains of significance.  I don't know what else to call this, but as an 
illustration, we know that Newton's laws of motion break down near the speed 
of light.  Science generally gets on with life by neglecting Einstein type 
effects at velocities which are low compared to c, since any possible 
contribution due to those effects is washed out and below any significant 
level of measurement possible.  So, let's say we input the fully general 
equations into Axiom for motion, velocity, etc. since we like generality.  
However, for sufficiently small velocities (or more correctly, sufficiently 
imprecise) measurements, we want to use Newton's equations, even 
symbolically.  They should (and do) simplify in the limit, and we want Axiom 
to be able to understand or even figure out such things on request, since 
such information is very useful to practical work.  Plus, it would be an 
awesome way to build intuition on when things matter.  The problem is, there 
would need to be a definition given for sufficiently imprecise.  Either 
deduced from supplied measurement uncertainties (and it should deduce them if 
it can since the human probably can't be relied on for this) or supplied in 
purely symbolic situations.  I have no idea how  to express this idea in 
Axiom, if it can even be done, but it would provide an absolutely incredible 
and powerful tool for using the right  equation given the data.

OK, enough pie in the sky talk :-)  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.)

CY