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

[William Sit]

Just a quick answer for now:

You can use

 s:=setDimUnit("Length", "cm",('s)::S)

if s is an unassigned symbol. The quote in the argument tells Axiom to use s as
a symbol temporarily, but then assign it to the domain SIUnitSystem(S) provided
S has RetractableTo(Symbol) such as POLY INT.

So for "variables" (symbols), that is not an issue. For expressions, you need
not assign it to a variable first:

  s:=setDimUnit("Length","cm", P*V)

is quite ok (assuming you want the aggregate variable PV).  In our discussion,
we did not use any specific expression and use "a" to stand for one, so I have
to use a new identifier "ua", assuming "a" is already bound.

I'll respond to other questions later tonight. Got to go to school.

William
--

C Y wrote:
> 
> 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

-- 
William Sit
Department of Mathematics....Email: address@hidden
City College of New York................Tel: 212-650-5179
Convent Ave at West 138th Street........Fax: 212-862-0004
New York, NY 10031..Axiom, A Scientific Computation Sytem
USA............... http://www.nongnu.org/axiom/index.html