Re: [Axiom-developer] Unit package question

[C Y]

--- William Sit <address@hidden> 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