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

[C Y]

--- William Sit <address@hidden> wrote:
> 
> 
> 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 types.

Hmm - is that good or bad?

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

A good point.

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

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 ;-).

> 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 ;-).

> 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 :-).

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

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

OK, I think this might be useful later on.  Once I get to writing up
the Axiom level represenation of quantities with dimensions/units I'll
try and think some more about this.

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

Hmm.  OK.

Cheers,
CY


        
                
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/