C Y wrote: > > --- William Sit <[EMAIL PROTECTED]> 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. > > Note that x0 in (5) has the same TYPE as the rhs BEFORE assignment. > > It should be legal, perhaps with a warning message, if the target > > dimension and unit do not match those of x0. > > 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. (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. > For example, if someone solves for a Moment of > Force quantity and tries to assign it to a variable defined to have > dimension Work, on the grounds that they have the same reduced > dimensions, Axiom can (and should, IMHO) stop them cold. Which also > raises the point that we need to add a way to define a variable such > that it will accept any dimension who's reduced dimensions match, > proceeding on with those reduced dimensions. 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 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. 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 concept of 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. We need more discussion on this, on how this affects the functions. > 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. [snipped] > > Yes, everything depends on how the coding goes! (especially when it > > comes to the compiler). > > Ah, point. 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. William _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
