--- William Sit <[EMAIL PROTECTED]> wrote: > 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/
Sounds good to me. The only fly in the ointment is kilograms for mass, but this can be handled. (It might not be an issue if we don't automate metric prefixes anyway.) BTY, what is the actual difference between SI and MKS? > 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". Is that a bad thing, necessarily? I know there are a fair number of derived dimensions, but I think it's on the order of 10^1, not 10^2 or 10^3. That way we can deal with any quirks on a per-dimension basis, which would be conceptually a good match with the "real world." Are there reasons it's a bad idea to define large numbers of domains in Axiom? > 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. I like this as a user option, but I'm wary of it as a fundamental structuring mechanism - what about the case where a user finds it convenient to adjust dimension to a custom default, say wanting Length to be displayed as nanometers by default instead of meters, but leave most SI units in place? (I do understand and agree with the appeal of this as a way to group definitions of units in terms of SI units - it does organize that well.) Where do we put definitions for units not an official part of SI or one of the other systems? What if (for whatever reason) someone wants to mix and match CGS and MKS over the various dimensions - what mechanism do we use? I don't think we want to restrict that behavior - it might be unusual but can't really be called bad practice, since having whatever units happen to be intuitive available is perfectly legit, especially when the tools exist (or will exist ;-) to automatically standardize all units for publication :-). > 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. Hmm. So instead of domains, we specify the existance of dimensions in the category definition, and then create domains based around standard measurement systems which must provide unit definitions for all defined domains in their category? > 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. Yes, I hadn't gotten to physical constants yet - I figured Units should be in place first :-). > 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. Hmm. Did you have an example in mind? Sometimes that helps. Are you referring to the problem that some combinations of units that will occurr will not map to a derived dimension? We must allow for expressions which are composed of the product of base and derived dimensions - that's inevitable. Does that pose a problem? If you're looking to determine dimensional equality, the best way I know is to reduce everything to the seven base dimensions and simplify. That might be a bit more CPU intensive than taking shortcuts in the case of complex expressions, but it is the most general way I know of and has the best chance of succeeding in general. [snip] > 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). I guess I'm not understanding the difficulty of maintaining domains - unless there would be problems setting it up, wouldn't it be a one time effort to create the domains and then occasional additions and unit definition updates? [snip] > 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). This works for things contained in systems, but what about piecemeal/custom setups? > These are just some beginning thoughts, which certainly need serious > critique from all. I like a lot of these ideas, I guess I'm just confused by your adversion to domains - or rather, I don't fully understand the difficulties associated with them. What do we gain by defining dimensions in the Category, instead of doing the dimensions as domains and defining the unit systems in terms of specific unit choices for available dimensions? Just curious - lord knows I'm not informed enough to critique :-). 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
