--- Ralf Hemmecke <[EMAIL PROTECTED]> wrote: > Hello Clifford, > > Aldor is much clearer than SPAD. You will agree on that when you > later have to understand what you once have written in SPAD.
Hehe - hence's Tim's focus on literate programming becomes important, although I note at least some of the dvi files produced by my latest Axiom compile were less useful than I had hoped and had some rendering issues. However, it is so incomparibly better than the Maxima source code situation I'm not dismayed :-). > I think you should try to ask Stephen Watt, whether the Aldor > compiler will ever become open source. He claims that there is > still some copyright issues to be solved. But I don't know which. > Maybe it helps if many people ask him for opensourcing it. I would > be very much in favour of it. Peter Broadbery once worked with NAG > on Aldor and I think he could do wonderful things with making the > Aldor compiler better. Anyway at least he could document the code > properly that he added to the compiler. So I rather ask you to help > making Aldor free. With pleasure. I like Martin's idea of a petition - getting some big names on board would help. I had assumed it was impossible - some communication I remembered from long ago had indicated that there were commercial ambitions for Aldor and that would preclude open sourcing it - perhaps I misunderstood or the situation has changed. That would be very good news indeed. > > I guess I was thinking something like a Category Dimension and the > > various Domains (Mass, Length, etc.) as members of that Category. > > Sounds like that might not be the right way to work things though. > > Right. The reason is: what do ALL dimension domains have in common? I > cannot think of a single function, except, maybe "convert". Well, yes and no - I agree functions might be limited, but there are other things. They all have in common the rule that you can only add dimensions if the dimensions being added are the same. They all have the same requirement for display formatting - e.g.: kg*m a 23 ----, 23a N, 25 K, - Ohms, etc. 2 b s All metric units share the same prefix convention both for full names and abbreviations (the programmer in me wants to use that, but I concede it might be better in the Axiom world not to, though I have not given up yet). There are rules that work for all units which tell you what the units would be for operations like integration even if you don't DO the integration (see Barton Willis's dimensional analysis package - I'm not sure how formalized those rules are there, but they do seem useful.) There could be global settings which might potentially apply to multiple dimensions (like, say, don't use derived dimensions at all - report everything in base dimensions.) That kind of thing was why I thought a category might be useful (not fully understanding the purpose of categories, granted) but if it would make it hard to multiply dimensions like Mass*Time then it's a bad idea - the very notion of derived dimensions rests on those operations. > > OK. What about this - have two domains, Dimensions and Units. > > Have Units depend on Dimensions and define its units in terms of > > Dimensions. > > He? Maybe I am missing the difference beteen dimensions and units. > What is what? A dimension is an abstract concept of a physical property, whereas a unit is a description of some specific instance or manifestation of that property. For example, Length is a dimension, meter is a unit describing the dimension Length. Inch would also be a unit describing the dimension Length, and because they both describe the same dimension it is legal to consider things like 2*meters+3*inches. By the same token, Mass is a dimension, kg is a unit describing the dimension Mass, and a slug is also a unit describing the dimension Mass. So 3*kg+2*slugs has meaning, because the dimension of both terms being added is the same. However, 3*kg+2*meters is not legal, because although both are units the dimensions each of those units are describing a DIFFERENT dimension. Also, let's consider the equation for parabolic motion: x = x0+v0*t+1/2*a*t^2 We know that x and x0 describe distance (e.g. Length), t describes Time, v0 describes Velocity, which is a derived dimension defined as Length divided by Time, and a is an Acceleration is a derived dimension, defined in terms of another derived dimension (Velocity) divided by Time, or more fundamentally as Length divided by Time divided by Time. We know all this, but if we were to USE this equation we would input quantities with units, such as 4*m, 5*hrs, 45*km/s, 9.8*m/s^2, etc. But we can use ANY units - equally legal would be 4*yottameters, 5*eons, 45*inches/minute, 10*miles/day^2, etc. Indeed, it is not uncommon to have some physical constant or experimental data in inconvenient units - one of the primary purposes of a units package is to do all the annoying work for you. So what you want to do is define your equation, and define the dimension (NOT the units) of the variables used. This prevents x0 being assigned 5*kg, but will allow any unit which makes physical sense to be used successfully. A variable has no concept of what unit it is in most physics equations, for example, and it isn't supposed to know that. Perhaps constraining a variable to a specific unit for display could be implimented, but the check to make there is that it can be converted to the correct unit and perform this operation automatically. A second option/setting could be to accept only a form described in the correct unit, e.g. a*meters for a variable x with set unit meters. I can see the latter being useful only to prevent accidental entry of incorrect data, but it might be useful for that. Conceptually I would prefer to allow variables to only know their dimension by default, and require a specific override on a per variable basis for other behavior, for two reasons: 1) This allows a global setting to govern the reported units for all variables, which I think is useful. If we want to be able to override this for specific variables I suppose that would be OK (and maybe even valuable) but I would much prefer the default to be that all dimensional quantities be reported in the global unit I specify for that dimension. 2) It works against the temptation to allow a user from inputing only a number to a variable and getting a dimensional quantity back. One of the biggest problems in introductory labs (and sometimes well beyond that!) is people who don't write units down. Sometimes they don't even KNOW the units, and are just trying to get by without doing the extra research and figuring out what they are. (Textbooks sometimes are unhelpful in this regard, in my experience, so the habit is to be lazy, manipulate the numbers, and assume everything worked.) Implimented the way I have described, a unit will never get automatically assigned to anything unless a user specifically sets that up, and to do that they have to know what unit they want. E.g. even if we define x as meters and only meters are allowed for assignment, x := 30 is still rejected as an error. x := 30 should never be a legal assignment for any kind of dimensional variable, regardless of settings. I think what people are doing, when they say they want to describe the variable x as being in meters, is that they want the CAS to know x is a length and to always display it's value in meters. That I can agree with, but I would suggest that if such a feature is implimented it be in such a way that it does NOT accept x := 30 as being an assignment of the value of 30*m to the variable x. This is exceptionally bad practice and should be disallowed. I prefer that something like the following be put in place: DefineDimension(variable, dimension) : This will associate a given dimension with a variable. I would suggest that x::dimension be configured to do this, as well. DefineDisplayUnit(variable, unit): This will a) automatically assign x the dimension Length, and b) instruct Axiom to always convert a displayed value of x into meters, whatever units it was assigned in or the global settings tell it to display. I'm not sure if x::unit is a good idea or not, but probably should be done for consistency. Documentation would have to train people to use the more general x::dimension if they want global unit settings to be workable. DefineAssignableUnit(variable, unit): This will allow assignments to this variable ONLY if the form being assigned is of the form variable*unit where unit matches the expected unit of the variable. It should not enable an assignment without specifying unit. Perhaps it should set the output flag of DefineDisplayUnit as well, or best of all a flag could control whether it does or not, with the default being yes. Does this seem to make sense? > Ah, I've heard of dimensional analysis once. That rather checks > whether the type of the result has the correct format. Oh, that > somehow seems to suggest the domain way. But first explain. And > maybe let me sleep then a night about it. Hopefully the above outlines it - "dimensions are what units describe" is probably the shortest way to put it I know. units can share a dimension, dimensions do not share units. Dimensional analysis will report the dimension of an expression, not the units of that expression (e.g. Time instead of minutes). It is useful for checking that an equation gives you the type of dimension you expect - for example if you define F=ma and dimensional analysis of F gives you Energy, you know you goofed somewhere (this is less obvious sometimes with units, particularly in complex cases.) It also is useful for giving you an idea of what some quantities in science actually correspond to physically (also often not as obvious and would be nice.) Hopefully I'm thinking about all this correctly. Most people never need to delve into the nature of units like this - or maybe most other science types figured this out sooner and more easily than I did, assuming I've got it right. Either way, a units package in Axiom will make it all explicit and documented, if done correctly :-). > Well, yes, but as far as I understand you want to distinguish the > type of the units (length, time, mass, etc.). So maybe the > metadomain approach would be a good idea. Distinguishing the type of the units is essential for knowing what legal operations for "+" are, just for starters. This is where my knowledge of Axiom is too limited to know what the good mappings are - hopefully that will emerge. I'm pretty sure there IS a good mapping - it just needs to be hammered out :-). Cheers, CY __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer