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

[William Sit]

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


C Y wrote:
> 
> --- William Sit <address@hidden> wrote:
> > 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 types.
> 
> Hmm - is that good or bad?

Good for naive users and maybe even for expert users. But just like types are
rigid, sticky dimension will also be rigid. There are users who prefer more
loose settings (that's one reason why Mathematica or Maple is popular).

[snipped]

> Except in the case of a student, they might just ignore the warning,
> accept the overwrite, and proceed with the calculation hoping they can
> just ignore the problem and get an answer that "looks" right.
> 
> Hmm.  How about this - by default we require an explicit unSetDim, but
> we provide a mechanism for advanced users whereby they can read in a
> script with the error mechanism reduced to a warning.  An advanced user
> will be able to find and use this, and by default we preserve Axiom's
> tough-guy rep ;-).

As long as you know how to do it. Axiom interpreter has three settings. See )set
user. That may provide the switch. I don't know how that works.

> > 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'm working on an idea or two about expanding that a bit, but basically
> it looks like you're right once we substitute for any derived
> dimensions.  I'm trying right now to straighten out the rules for such
> things in my head via writing them down ;-).

Speaking of "substitute", if Dimension is modeled by a free abelian group (maybe
not even free, since it can be factored by using derived dimension definitions
(relations); the more I toyed with this idea, the more promising that looks),
then units can be obtained by a substitution. We may be able to let the rules be
user add-ons. Again, need more thoughts on this. 

> > 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.
> 
> Agree wholeheartedly now :-).


The reduced dimension would be the default representation in Dimension if it is
modelled by a group. The only way to "recover" or retain the physical dimension
may be in the Rep of the UnitSystem domain itself, for each identifier.

So the group model will provide all the computation to get reduced dimension and
also equality of dimension. The Rep retains both dimension and reduced
dimension.



 
> > 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 conceptof 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.
> 
> Well, I'll be able to comment better once I know what a free abelian
> group is/means, but in general it sounds like it's a good solution.

Well actually, the Mass, etc on the foo definition probably should have been
quoted as strings, but they are NOT strings anymore, but are generators for the
group for the dimension domain.
 
> > We need more discussion on this, on how this affects the functions.
> 
> OK - I'll try and qualify myself - where are the good docs on free
> abelian groups?

An abelian group is simply a set with a commutative multiplicative (but usually
written additively) binary operation and every element has a multiplicative
inverse. It is free if there are no relations among the generators. As mentioned
earlier, maybe we should actually allow non-free abelian group to model
Dimension domains. We will need to construct quotient objects in the abelian
group category. Any introductory modern algebra book will have enough coverage
for this project. Or just google.
 

William