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

[Vanuxem Grégory]

Hi,

Le vendredi 09 septembre 2005 à 09:42 -0400, William Sit a écrit :
> -- 
> 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.

You can have some introductory materials 
in "Elements of Abstract and Linear Algebra" from E.H. Connell

http://www.math.miami.edu/~ec/book/

or Wikipedia.

Cheers,

Greg
> 
> William
> 
> 
> _______________________________________________
> Axiom-developer mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/axiom-developer
>