[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: William Sit
Subject: Re: [Axiom-developer] Unit package proposals and questions
Date: Fri, 09 Sep 2005 03:34:02 -0400

C Y wrote:
> --- William Sit <address@hidden> wrote:

> > I may think a bit of the last action though: whether we allow an
> > identifier to change its dimension. Say, what if I decide to
> > "recycle" an identifier?
> Maybe that's where my "unSetDim" idea can come in?  We need a way to
> undo what we do, but I don't think we want it to be automatic.

I'll leave that up to you. Enforcing a sticky dimension to an identifier is
similar to enforcing type to an identifier, so it is similating dimensions as
> > Note that x0 in (5) has the same TYPE as the rhs BEFORE assignment.
> > It should be legal, perhaps with a warning message, if the target
> > dimension and unit do not match those of x0.
> I think I disagree, if I understand you here - one of the primary
> benefits I see of having generic dimensions without units associated
> with variables is to enforce matching dimensions between assignments
> and variables being assigned (this is another check on correctness, and
> a useful one IMHO).  

Sure. The problem is not that critical in a line by line interpreter
environment. If an assignment is illegal as above but simply because the user
forgets to unSetDim, he gets an error message and he can easily correct that.
However, if the user is writing s script (.input file), and the running of the
script stops because of such an "error" (which is not an error to the user
because he thinks he is just recycling identifiers), it may cost him a lot of
recomputation time. On the other hand, a warning would alert the user, but
without aborting. (I really hate it when I back up a bunch of files, and one of
them was in use by the OS, and the OS stops; I have no way, except to check file
by file, how to restart or continue.) I think the decision of whether we should
stop or just warn must be weighted by whether our intended users are
knowledgeable experts or amateur beginners (like students). I would opt for
warning, because it helps the advanced users, and at the same time, to an
interactive line by line user, it makes no difference whether the message is
"this is illegal" or "warning: dimension error";  in both cases, he is stopped.

> For example, if someone solves for a Moment of
> Force quantity and tries to assign it to a variable defined to have
> dimension Work, on the grounds that they have the same reduced
> dimensions, Axiom can (and should, IMHO) stop them cold.  Which also
> raises the point that we need to add a way to define a variable such
> that it will accept any dimension who's reduced dimensions match,
> proceeding on with those reduced dimensions.

No matter how you try, there is no way to guarantee correct verification of
homogeneity of dimension in an equation or expression. The best we can do is the
guarantee that for reduced dimension because the only algorithm to do the
verification is to reduce all dimensions to the basic dimensions. I had
suggested earlier that the Rep include the reduced dimension to make such
checking more efficient. Then the dimension can be as fancy as the user wants. 

This brings another design issue into sight: Dimension should be a group
(mathematical term) generated by the basic dimensions, but allowing the user to
define arbitrarily any derived units. We need to allow this since a user may
want to call "Mass^2 Time/Length^3" by the name "foo". With the current concept
of the Dimension domain as a Union of Strings, the set of dimensions is fixed
and not extendable to include something not anticipated.

  foo:PhysicalDimension:= Mass^2*Time*Length^(-3)
  setDim(foo, s)

Making Dimension a free abelian group, written multiplicatively, based on some
basic dimensions as generators (these may differ depending on expert area) may
avoid the "Union" problem. We can now easily have a DimensionCategory. A
corresponding UnitsCategory will also be a subcategory of the free abelian group
category (FreeAbelianGroup is a category in Axiom, this will save a lot of
implementation work since all the functions (equality, and reduction, for
example) are built in already! We can have a free abelian group on ANY set. 

We need more discussion on this, on how this affects the functions.

>  Would it be possible (or
> rather, interesting and useful) to have the state vector preserve the
> history of derived -> reduced conversions?  Sort of a pedigree of where
> the given unit/dimension definition came from, conversion wise?

This can be done in the Rep of each quantity with a unit.

> > Yes, everything depends on how the coding goes! (especially when it
> > comes to the compiler).
> Ah, point.  So in general, it is not always useful to try something in
> the interpreter as opposed to coding it and compiling it?  

Yes, code that work in the interpreter does not work (usually) in the compiler
because the interpreter is "intelligent". However, it is still a good idea to
first use interpreter code to test some implementation of functions. Most of the
problems are you have to tell the compiler where to find the functions
(coercion, package call). All abbreviations must also be defined for the


reply via email to

[Prev in Thread] Current Thread [Next in Thread]