--- Bill Page <[EMAIL PROTECTED]> wrote: > Here are few initial ideas about how I think units might > be implemented in Axiom. > > For scientific applications of Axiom, I think units might be > very useful. My first reaction however is to try to imagine > what part of Axiom might be most suitable to represent the > concept of units.
It's most likely non-trivial - I've got some digging to do into Axiom programming philosophy. I'll try to describe what I had envisioned in my mind's eye, and perhaps it will emerge what it would take to teach Axiom to work with the new concepts. > > There are a number of surprisingly annoying features to handle > > based on my experience with Maxima, and one of the worst is > > the following: > > > > If I enter an expression, Axiom automatically formats it and > > orders it according to internal rules. See > http://www.axiom-developer.org/zope/mathaction/SandBox#msg20050819154916 > [EMAIL PROTECTED] > > > for an example of this. Normally, this is what one wants to do. > > I think what you are doing here is ok in Maxima, Maple and > Mathematica but it does not fit well in Axiom. I think it might > be quite awkward to treat units as expressions of this kind in > Axiom. Possibly - I'm not really sure myself yet. But as I'll explain below there are reasons for this approach. > > What I'm not sure of is how to instruct Axiom to display things > > that are Units at the end of an expression, e.g. > > > > kg*m > > a*b*z ------ > > 2 > > s > > What makes Axiom different is it's strong type system and it's > object-orientation. To me this suggests that units in Axiom > might be best implemented as extensions of the Float domain. The logic of units certainly has some similarities, but one needs to be careful because there are a fair number of unique options one would want to have with units. I'm not sure, on closer analysis, that Floats are really all that good a match. I'll try to give a couple examples below. > By this I mean we should be able to write something like this: > > (1) -> (2.0::kg + 1.0::lb)::ton > > (1) 0.0027 > Type: ton > > where kg, lb and ton are Axiom domains. Given the right > definitions of these domains we should expect that Axiom would > perform the necessary coercion/conversion from the domains > kg and lb to ton, the same as if we had written: > > (2) -> (2.0::Float + 1.0::INT)::SF > > (2) 3.0 > Type: DoubleFloat The problem with this is there would have to be one type/domain for EVERY SINGLE UNIT we wished to define. When one includes the metric prefix system, this can include a LOT of types/domains. Conceptually, I think it would be more elegant to have Axiom recognize a) a unit is in an expression b) determine the dimension of each unit and confirm the expression is dimensionally legal and c) depending on options return either i) the unsimplified combination of legal terms ii) the simplified expression according to a global set of user chosen standard units (MKS by default) or iii) if non-basic dimensions like Force are enabled, and an expression simplifies to such a dimensional type or a combination of higher order types, simplify to the most compact form available. Of course, this might not be at all elegant in Axiom as it currently exists, but here's a mockup session of what I'd like to see: (1) -> (2.0::kg + 1.0::lb)::kg Error - incompatible dimensions for Add operation (1) -> (2.0::kg + 1.0::slugs)::kg (1) 3.45939 kg Type: Mass (2) -> (2.0::kg + 1.0::slugs)::slugs (2) 2.3704355929 53220181 slugs Type: Mass Ideally I'd also like Axiom to be able to deal with (2.0*kg + 1.0*slugs)::kg as well, but I don't know if that would be legal or not. Conceptually at least, 2.0*kg and 2.0::kg are the same thing. I'll add more mockups below as they seem relevant. > To implement something like: > > (3) -> 2.0::m * 3.1::kg > > 6.1 > Type: m*kg > > Axiom will have to be told how to multiply meters by kilograms. > This is easily done given Axiom function overloading. Add of > course Axiom needs to know how to construct new units (types) > from old ones. Since types are first order objects in Axiom, > this is also quite easy. I would like to see this feature handle things as follows (I don't know enough about the type system to know if it could do this yet) (3) -> (4.0::kg * 3.0::m / 6::s**-2) kg m (3) 2.0 ---- 2 s Type: Mass*Length/Time^2 (4) -> ActivateExtendedUnitTypes(MKS) (4) True (not sure what the "standard" way to do this is) Type: Bool (5) -> (4.0::kg * 3.0::m / 6::s**-2) (5) 2 N Type: Force (6) -> (4.0::kg * 3.0::m / 6::s**-2)::dyn (6) 200000 dyn Type: Force (7) -> (a::N)::dyn (7) 100000 a dyn Type: VariableForce There are many other variations on what a user might want - for example, after doing some calculations in N or dyne they may want to render their forces in base units, but cm*g/minute^2 rather than MKS. Options to set defaults for and override locally all of these simplifications are needed. Assignment checking is also needed - for example, in the last example above a should only be assigned quantities of type Force. However, any Force type is legal and should be accepted and converted as controlled by settings. > Perhaps you are confusing the notion of 'dimension' and 'unit' > here Possibly - I get a bit loose with my terminology sometimes, which won't do in the Axiom world :-). To be clear - each unit is associated with a dimension, and I would like to see the rules governing unit interactions work on the dimension level, while handling the conversion between different units with the same dimension automatically based on circumstances as determined by either default settings or the user's preferences. > but still I think these ideas both map quite well to > Axiom's type system. For example > > (4) -> 1.0::m + 2.0::s > > would constitute a type error. Right - essentially Axiom's strict typing gives us a chance to have dimensional analysis as part of all calculations :-). > The display of units as types, e.g. > > Type: m*kg > > should be possible, although I think there my currently be > some built-in assumptions about type expressions that might > currently preclude this nice infix notation. But a type such > as > > Type: Prod(m,kg) > > is certainly possible. Right, but as I showed in my examples above my preference is for the units to remain as a displayed part of the expression, and the Type information to report the dimension of the quantity in question. This seems to me to be the most useful thing to do. > > Is there anybody who knows what the correct approach to this > > would be? > > Maple has an elaborate Scientific units and dimension system > that even takes advantage of overloading operations like + * / > such as I suggested above, although Maple does not really have > the notion of strong typing. If you have the opportunity to study > how this was done in Maple perhaps it will suggest a possible > approach in Axiom. I have looked at the Maple package, and indeed they use many similar ideas to ones I had arrived at (after much trial and error) in the Maxima design. (Boy was that embarassing - a real lesson to do my homework before beating my head against the nearest wall!) How it's ideas map into Axiom's strong typing system is, unfortunately, the real nut to crack. Axiom's system offers some exciting possibilities, but it looks like there might be some roadblocks to plow through too. I should mention that Maple has the idea of things like (IIRC) unit space where expressions are encapsulated in a Units() denotation, e.g. 4*z*Units(kg*m/s^2). This was rejected for the Maxima package - we felt that the program should be able to handle the "textbook" kg*m formatting style of 4*z ---- since this is the convention used 2 s almost universally in the sciences (who are most likely to be dealing with units.) I have the same hope for Axiom - units, as multiplicative factors, remaining part of the expression, and the Type information working on the dimension level. (As in my examples above.) > These are just some rough initial ideas. I am not sure how > well this concept of "units as types" will work out in > detail. It might be that that would be the best "mapping" of the idea onto Axiom's system, although aesthetically I prefer the idea of working with dimensions and units providing the multiplicative factors for conversion between each other. Discussion welcome. Cheers, CY P.S. - there's also the whole idea of error analysis which enters into this equation - for example, when discussing physical quantities 2.0 has a significance - you are implying a greater measurement accuracy than just stating 2. So there may be a collision in the future between float and integer behavior in Axiom and the handling of accuracy. For example, if I have a measurement of 10+-2 and I subtract the quantity 4.0007+-0.0005, the proper return (if I've got this right - it's been a while) would be 6+-2, since error analysis combining the two errors would result in 2 + <small amount>, and significant figure rules say to chop off the <small amount>. Anyway, there are rules governing such things and I suspect there might be a collision between those and "normal" mathematical convention, where all things are exact. Then there's the whole issue of errors introduced by the CAS itself, due to precision limits and such. But that's for another day. ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer