Very interesting topic, which I have been following. I like the idea for a "pivotal unit". What better one to use than the international system of units (SI)?
http://physics.nist.gov/cuu/Units/ Different schemes for implementation have been proposed, some even coded. I don't like the idea of having one domain for each dimension (there are 7 base units listed in SI) because we would then have to have new domains for derived dimensions like "force". Axiom has a way to handle number systems and I think the unit systems can follow this number system model which has an IntegerNumberSystem category with four domains: Integer, RomanNumeral, MachineInteger, and SingleInteger. So we can have one category UnitSystem, with domains like CGSSystem, MKSSystem, InternationalSystem, etc, where InternationalSystem would be the default, and the other systems convert to and from this. In the UnitSystem category, we specify dimensions, beginning with the seven basic dimensions (length, mass, time, electric current, thermodynamic temperature, amount of substance, and luminous intensity) and expanded to include other derived dimensions. The UnitSystem category should allow a parameter S:SetCategory. In principal, units are input/output "decorations" attached to expressions from any set S. The complications of units come from the conversion factors, which are generally floating point numbers (and dimensionless). This would be ok if we only deal with numerical quantities. For symbolic quantities, it is the dimensions that are more important and conversion factors (not to be confused with universal physical constants) are seldom used, and universal physical constants are often denoted by a symbol (such as "g" for acceleration due to gravity) without units. Thus we should leave symbolic computed expressions alone (that is, in the set S, even though it is actually in some domain of UnitSystem(S), see below). The verification of dimension on the two sides of a symbolic equation is not a simple matter since in the applied sciences, one often "balance" dimension with a constant of proportionality, for which there is no a priori assignment of dimension in general. However, we can enforce some degree of verification by our implementation of dimensions (see below). Acutal units are needed once we pass from symbolic to numerical computation. Thus we should design the UnitSystem domains to facilitate such passage. We should have a discussion on what functionalities are to be included in the UnitSystem category. Here are a few that comes to mind: unitMass unitLength unitTime unitCurrent unitTemp unitAmount unitLight All of the above, and below, functions have signatures similar to: unitMass:S -> % and unitMass(s:S) would declare that the expression s has dimension Mass and unit of Mass for the domain %: UnitSystem(S). I think this is better than the syntax s::Mass or s::Kg because it avoids the need for many domains (which would be difficult to maintain). A representation for any of the domains of unitMass(s:S) would be Rep:= Record(value:S, dim:Dimension) where Dimension would be Dimension:=Union("Mass", "Length", ...) and we can provide queries for any expression in % as to its Dimension. (The Dimension domain can also be expanded than just this mere text implementation, if there are functions that are needed). We can add as many as we like for the derived dimensions: unitArea unitVolume unitForce unitPressure etc. As an (conceptual) example of implementation (forgive me for Axiom syntax errors, I did not bother to look them up), we can have: if S has Ring then unitArea(s1:%, s2:%):% == if and(s1.dim = "Length", s2.dim = "Length") then [s1.value * s2.value , "Area"]$Rep error "Invalid Dimension" We can have a "pure" declaration: unitPressure(s:S):% == [s, "Pressure"]$Rep or a "derived" declaration: if S has Field then unitPressure(f:%, a:%):% == if and(f.dim = "Force", a.dim = "Area") then [f/a, "Pressure"]$Rep We would need to handle outputs of domains of category UnitSystem(S) to make sure that the units are displayed at the rightmost location, but this is trivial given the Rep for the domains in this category (see OutputForm for all the functionality to handle outputs). Notice that all the dimension verifications can be done by default in UnitSystem category implementations and the actual domains only need to handle the units for the particular system. We need a way to include universal constants, the notation of which depends on the set S. if S has Field then unitAcceleration(dv:%, t:%):% == [dv/t, "Acceleration"]$Rep if S has RetractableTo(Symbol) then accelerationDueGravity == ['g:Symbol::S, "Acceleration"]$Rep If S does not have RetractableTo(Symbol), for example S is Float, then we can use a specific constant such as 9.81 depending on the domain %:UnitSystem instead of a symbol g. So far, the above discussion concentrates on the symbolic side. It also separates conceptually the notions of dimensions vs units. To handle the numerical side as well as conversion between different unit systems, one can have a "lift" (functor) category that performs this (much like the coercions between different types of polynomial domains when the coefficient domains are mapped): UnitSystemLifting(US:UnitSystem(S), UT:UnitSystem(T)) would take elements of say, US=CGS(S) to UT=CGS(Float), or to UT=MKS(S). The exports of this category would contain something like: convertMass(us:US):UT convertLength(us:US):UT The unit conversion factors would be included in such packages and the domain S should have RetractableTo(Float), or whatever (such as coerced to EXPR FLOAT) to make sense. Note that this proposed design allows mixed symbolic-numeric domains for S, such as POLY FLOAT. These are just some beginning thoughts, which certainly need serious critique from all. William -- William Sit Department of Mathematics....Email: [EMAIL PROTECTED] City College of New York................Tel: 212-650-5179 Convent Ave at West 138th Street........Fax: 212-862-0004 New York, NY 10031..Axiom, A Scientific Computation Sytem USA............... http://www.nongnu.org/axiom/index.html _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer