[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] Unit package proposals and questions
From: |
Vanuxem Grégory |
Subject: |
Re: [Axiom-developer] Unit package proposals and questions |
Date: |
Fri, 09 Sep 2005 16:27:05 +0200 |
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
>
- Re: [Axiom-developer] Unit package proposals and questions, (continued)
- Re: [Axiom-developer] Unit package proposals and questions, William Sit, 2005/09/09
- Re: [Axiom-developer] Unit package proposals and questions, C Y, 2005/09/09
- Re: [Axiom-developer] Unit package proposals and questions, William Sit, 2005/09/09
- Re: [Axiom-developer] Unit package proposals and questions, C Y, 2005/09/09
- Re: [Axiom-developer] Unit package proposals and questions, William Sit, 2005/09/10
- Re: [Axiom-developer] Unit package proposals and questions, C Y, 2005/09/11
- Re: [Axiom-developer] Unit package proposals and questions, William Sit, 2005/09/13
- Re: [Axiom-developer] Unit package proposals and questions, Clifford Yapp, 2005/09/13
- Re: [Axiom-developer] Unit package proposals and questions, C Y, 2005/09/09
- Re: [Axiom-developer] Unit package proposals and questions, William Sit, 2005/09/09
- Re: [Axiom-developer] Unit package proposals and questions,
Vanuxem Grégory <=
- Re: [Axiom-developer] Unit package proposals and questions, Camm Maguire, 2005/09/28
- Re: [Axiom-developer] Unit package proposals and questions, William Sit, 2005/09/28
- Re: [Axiom-developer] Unit package question - Reply to 1st half, C Y, 2005/09/02