Hi, Le vendredi 09 septembre 2005 à 09:42 -0400, William Sit a écrit : > -- > William Sit > Department of Mathematics....Email: [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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 > [email protected] > http://lists.nongnu.org/mailman/listinfo/axiom-developer > _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
