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

[C Y]

On Wednesday 07 September 2005 02:15 am, William Sit wrote:
> C Y wrote:
> > 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.

OK, but shouldn't that be a separate issue from what is assumed by Axiom when  
a is input into the command line?

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

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

If this is not possible, we can probably document things to make them usable, 
but requiring using a second variable to assign dimension to another one is 
(at least based on my own expectations) going to be very, very non-intuitive.  
If x is given a Dimension of Length, x without dimension doesn't have any 
sensical meaning I can figure out.

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

Right, but that's a constant, and %pi is one of those "dimensionless but not 
without dimension" scenarios, IIRC.  In general I agree - if s is providing 
the value for two quantities with different dimensions, the current setDim 
behavior is good.  But,  *in the specific case of variables*, I still think 
it is a better idea not to require a separate identifier for the x with 
dimension object, since any use of it other than as a variable with dimension 
isn't going to make sense in the context calculations using x and (IMHO) 
shouldn't be allowed.  I would MUCH rather, in that case, that we provide a 
stripDIM(x) command for the presumably much rarer case where you are actually 
looking for that.  Or perhaps an alternative suggestion below, which would 
require (maybe) less violation of Axiom's rules.

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

This seems a little odd to me - why can't you have a situation where the 
"toplevel" object a refers to a variable "a" and a dimension "dim", and just 
rely on a command to reach the inner variable in the rare case you would want 
to?  A limitation of Axiom?  If so this is very unfortunate, since I suspect 
this is not the only case out there where this kind of thing is going to play 
havoc with the intuitive expectations of users.  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.

Maybe I'm making too much of this but I'm still not totally happy about 
enforcing the requirement to always specify a dimension with a unit (although 
I still agree it's the best solution available) - I'd rather avoid any more 
surprises for the user if possible.

> > So be it - we'll go for enforced dimension awareness.
>
> Good, we have fewer and fewer differences.

The user docs for this point are going to have to be verbose, elegant, and 
compelling, but this being Axiom I think we can get away with it :-).

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

Hmm. OK, we can burn that bridge when we come to it if no one tosses up a 
solution first.

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

Surely this can be made optional?  Current behavior can be preserved, just add 
the ability to ask questions if allowed?

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

Right.  Actually, for physics it's probably necessary.

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

I think those can be handled once the basic structure is in place.  At any 
rate, they'll have to be ;-).

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

<snort>  So did I, when I started thinking about the original Maxima unit 
package a few years ago!  Opps.  Oh, well - maybe the chance to use it for a 
phd will come up if it's already done, and available to show anybody who 
still thinks that ;-).  Easier to fund if all the work's already finished - 
takes less time that way too.

> > > > > --------------- Name space issues
>>
> > 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?

Anything that behaves at all differently from the normal way people use units 
in equations, or would expect things to behave.  Axiom is going to enforce a 
few things most people probably never think about and won't want to think 
about, so we need to coax users in carefully or they'll run screaming.  
(Well, the undergrads will anyway, but there's no help for that...)

> > > > > ---------- Implementation Issue: Simplification of dimensions
>
> > > > 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)
>
> 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.

Correct.  However, the physical sciences are my primary interest, at this 
point - and they will need it.  Error analysis should be optional, but it is 
a necessary tool for many important kinds of work.

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

That's up to the scientist - garbage in equals garbage out, even in Axiom.  
However, given good measurements and sufficient information about the system, 
I'm thinking Axiom should be able to take it from there.

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

Well, I'm trying to avoid abject public humiliation, too ;-)  I'd rather have 
something at least semi-polished for the wiki.

Cheers,
CY