--- William Sit <[EMAIL PROTECTED]> wrote: > > No, I don't think so. So far, everything works even though users will > be force to declare dimension and unit for each quantity (as we > agree below). However, the above is not the same thing. If a user is > comfortable with defaults, that is, undefined identifiers are of > type Symbol (techically, Variable(s) for Symbol s), and any other > operations will be promoted to a higher domain, usually POLY > INT, then that is fine. But if someone wants to work with say S := > EXPR INT and uses SIUNitSystem(S), then he will have to package > call the setDimUnit for an undefined identifier s.
Ho boy, this is where my limited understanding of strong typing rears its ugly head. I think we need to have sensible defaults for this (I'm definitly opposed to forcing the user to think about such things unless they choose to) but I agree we need to allow for more advanced uses. Ugh. That will take some thought. > In principle, we do NOT know the type of undefined > identifiers. The Interpreter assumes we are using Symbol. This won't > be assumed in the compiler. OK, so we need to explicitly make some assumption in the definition of the function I guess - so long as it doesn't make its way into require default user syntax ;-). > > Generating plots of dimensional quantities will be interesting, but > > that's a bit down the road at the moment. Does the above make > > sense? > > 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. > 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). 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. 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? > Certainly, the setValue function is still needed, but you may not > want to export it. In the example, I was pushing the "convenience" > feature you have been advocating. I am glad you don't want to push > that far! Nope, I know there are limits to convenience :-). Just want to do the best I can to ensure this sucker gets used, but if I didn't think correctness was priority #1 I wouldn't be interested in doing this in Axiom ;-). At the user level, setValue should not be an option - you're right, such actions are needed for manipulation at low levels INSIDE the package, now that I stop and think about it - but they do need to be very strictly internal. > Great. May be a future project is to modify the interpreter to allow > s:= 7 [ft] as syntactic sugar, once the foundation is done, > correctly. That's a very good idea, but definitely lower priority at the moment. > > We need to stay correct, but what I'm trying to do > > is make things as convenient as possible while remaining correct. > > A very good ideal. Well, I think the lesson of the commercial Axiom is that you need to sell correctness and be as friendly as possible about it - otherwise you starve from lack of users. Axiom is open source now, of course, so we don't have the financial problems, but we still need users to remain (or become) a living, breathing project. Be correct, but remember the human side of the equation when possible, too. > Yes, that would have made implementation much easier in the > conversion part. (I guess I have been "poisoned" by my > Mathematica experience in implementing units conversions). Well, Maxima did the same to me ;-). I guess it's true what they say, assume you'll have to try to implement something at least once before you can properly define the problem. > Yes, everything depends on how to 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? In Maxima, generally speaking, it was all the same - I take it that's not the case here? Eeep. Cheers, CY __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
