[Axiom-developer] Re: Units and dimensions

[C Y]

--- Ralf Hemmecke <address@hidden> wrote:

> Hi Cliff,
> 
> At the end of section 4.4.2 of
>
http://portal.axiom-developer.org/Members/starseeker/axiomunit_diagramtest.pdf/download
> where you have discussed the problem of curvature, you say that the
> SI system is not a perfect one and that it is missing a dimension of 
> <CircularCurvature>.

That's the best way I have been able to find to express the problem.

> At the same time you say:
> 
> Unfortunately, Axiom must work with systems as they exist and are
> used rather than than their ideal implementations, we must somehow
> allow the current fundamental disodance to exist in Axiom's SI
> definitions and function non the less.
> 
> I understand your wish, but to my taste that is a non-mathematical 
> approach. As you have described, expressed in the SI base dimensions,
> <Work> and <Momentum of Force> are indistinguishable. So why would
> you want to implement an imperfect system? If there is nothing in SI
> that helps you to distinguish <Work> and <Momentum of Force> then you
> cannot  express it. You are basically saying that the SI system is 
> 7-dimensional, but the world is 8-dimensional (or even 
> higher-dimensional), but you want to describe your world with 7 
> dimensions.

In principle, I agree with you.  The reason I want to work with the
"real" SI system as such is basically that the scientific community
seems to be very accustomed to radians having dimension 1, but treating
Work and Moment of Force as two different dimensions.  In my opinion
this is a flaw of the system, but I wanted to be very "correct" about
implimenting the actual true-to-life SI system in order to cultivate
the interest of the scientific community in Axiom.  Now to be fair I
think most other tools that deal with this type of issue HAVE
introduced angle as a dimension, so perhaps that isn't so outlandish a
solution after all.  I guess the nagging question in my mind is whether
I (who am not formally trained in this stuff beyond a BS in Physics)
should presume to second guess the SI committee.  Finding the other
papers discussing that helped.  Maybe the thing to do is use the NIST
publication as the basis of a literate document implementation of the
SI system on top of the eventual Unit/Dimension framework, and update
it there with some of this discussion.

> That with fewer dimensions you don't see everything is 
> clear---draw a 4-dimensional hypercube on a sheet of
> (two-dimensional) paper and try to figure out from the latter,
> what properties the 4-dim object has. Of course, impossible.

Yes.  My impression is that because radian is an accepted unit in SI,
it is convenient for people solving for things like length using these
quantities to multiply by the numerical constant and ignore the
curvature aspect of the problem - in the end this is usually safe
because the radian multiplicative factor takes care of things, and
there is a "de-facto" curvature dimensional correction at the same
time.  I guess most people don't worry about the SI dimensional set
without thinking about the units as well, which masks the problem.  Heh
- maybe we can petition the SI committee to fix this issue - I wonder
what the procedure is :-).

> So if I were to implement dimensions and units, I would design a
> perfect system and allow the user to add dimensions and work with
> them. 
> Depending on which system the user chooses, he/she can work with 
> <CircularCurvature> or leave it out. Such an open system would even 
> enable one to experiment whether <CircularCurvature> is the right
> concept.

In the framework I'm thinking about this would be done by defining a
custom System, using these steps:

1.  Define as BasicDimensions your desired BasicDimensions for the new
system (that's why the BasicDimension definition needs a system slot -
whether a dimension is Basic or not depends entirely on what system it
is being used in.)

2.  Define your named DerivedDimensions using the BasicDimensions,
again specifying the System.

3.  I don't know if the System needs to be explicitly defined or not -
probably.  But it will need existing Basic and named Derived dimensions
defined for it.
 
> In the SI-system plus <CircularCurvature> you could distinguish
> <Work> and <Momentum of Force> in the pure SI system you cannot.

Yes.

> All I want to say, forget about the nature and all those systems like
> SI and cgs or whatever. In Axiom you should build a system that is
> flexible enough to accomodate for any system you like.

Absolutely.  But in order to make sure it IS flexible enough, my
approach was to look at a use case and see what features and structure
are needed.  It get's a bit weird - for example, to handle some high
energy physics unit systems the only thing that is axiomatic are some
dimensionless constants!  I'm still not quite sure how to handle that
one.

> If, for example, you want to replace the "fundamental dimension"
> <Length> by <Force>, then that is possible mathematically and should
> be allowed by Axiom.

Absolutely, but then you are no longer working in the SI system.  To do
this (which I agree should be allowed) you need to create your own
system.  If you use the SI system, it will enforce SI as defined by the
NIST Special Publication, give or take the CircularCurvature issue.

> <Length> is then simply a "derived dimension" that depends on the
> "fundamental dimensions" <Force>, <Time>, and <Mass>. Where would be
> the problem?

There wouldn't be - I agree this should be doable.  Just not in the SI
system - that would be MyNewSystem or some such.

> As a mathematician I can choose any axioms (fundamental things) I
> like as long as they are non-contradicting. Maybe a physicist thinks
> differently here?

In principle, no.  In practice, the SI definitions will be used in
almost all situations, except in cases where units from other system
need to be converted to SI.  But Axiom should be able to handle any
legally possible combination of setups correctly.

> By the way, if I look at section 4.2.2, then that very much suggests 
> that the *type* of a unit is a *dimension*.
> To my taste, that suggests to implement 7 (or 8 or how many
> dimensions you like) dimension domains:
> 
> Length: Dimension == add {
>    Rep == -- I don't yet know.
>    meter: % == ...
>    inch: % == ...
>    ...
> }
> 
> or you don't hardcode meter, inch etc., but make those units dynamic.

Yes, that's what I was thinking.  Something kind of along the lines of:

Length: BasicDimension == add{
     Rep == Record{name : String, system : String}
}

Meter : Unit == add{
     Rep == Record{name : String, system : String, physdef : String,
                   dimension : Length, pivotunit : Unit}
     convert: %,% == something
     etc...
}
> Similar domains for other dimensions.

Right - each dimension gets defined once for each system.  So for each
large scale built in system, we would have a pamphlet which uses the
core structural pamphlet defining things like BasicDimension and Unit,
and the specifics (Length, Meter, etc.) would be in the system
pamphlets.  There will also need to be some kind of Conversion pamphlet
that Axiom uses to know how to go from cgs->SI - I'm not sure how to
handle that yet.  Planck -> SI is going to be interesting.

> I could even imagine something like
> 
> Length(u: Unit): Dimension == add {
>     Rep == Unit;
>     unit: Unit == ...
> }
> 
> where out of the many units that are possible for lengths units, u
> would be the reference unit for this dimension. (So you could have
> the SI system and cgs system easily by using the Length constructor
> with a different unit.

That's an interesting idea.  The thing is though, I can envision a case
where someone wants to define just a Dimensional system with no Unit
component defined, in order to do dimensional analysis (which does not
involve units.)  Maybe optionally specifying a unit?

> I don't yet have a good idea for the domain Unit, though. :-(
> Please don't take all this too serious, I am just thinking aloud.

On the contrary, this is excellent!  It's exactly the kind of thinking
needed and that I'm not nearly expert enough in Aldor to do yet.

I'm afraid I didn't pick an easy topic for a first topic in Axiom,
despite what I thought earlier - because these ideas are so fundamental
to all scientific computation it is crucial to get them right the first
time, and mapping them into Axiom's systems takes some serious
thinking.

> Once you have these dimension domains, you could form an algebra with
> them, ehm, a abelian group, of course. No, no, there are still no 
> coefficients. So with that "abelian group" you cannot express 3m or
> 6s. 
> All you could do is to express, what you probably called "derived 
> dimensions".

Right.

> So Length, Length*Time^(-1) etc. are examples for such 
> monomials.

That's where I get in trouble.  (Well, one of the places.)  Length IS
basic in the SI system, but Length/Time is a different dimension from
Length OR Time and is not basic.  It's COMPOSED of basic dimensions,
but that could be said of every derived dimension in a complete system.
 

> As you see, each "fundamental dimension" is then also a 
> "derived dimension", but no conversions would be possible, since you 
> don't have coefficients.

I don't quite follow.  Length and Time are basic all right, but
Length/Time is a single derived dimension.  That's why I was originally
trying to say that if you multiply two basic dimensions (or take one to
a power, or divide - ANY such operation) the result is not a basic
dimension but a derived dimension.  However, Length/Time^2 * Time^2 is
composed of two derived dimensions - Length/Time^2 and Time^2 - but
will simplify to a basic dimension.  I was thinking some kind of
conditional definition of type output for those operators - if the
resulting dimensional expression is in the basic dimensions list for
the system, return type BasicDimension, else the result is a
DerivedDimension.  I'm sure I wrote crazy pseudocode trying to express
that, but I don't really see a way around it.  Derived Dimension almost
needs a generic Dimension type which can be either a BasicDimension or
a DerivedDimension, since either can be used to define a
DerivedDimension.  DerivedDimension is a bit recursive - a
DerivedDimension can be defined using DerivedDimensions.

> Now, having the monomials, you can think about quantities (= units
> (as elements of dimensions) together with numbers).

Makes sense. 

> I don't have a well developed idea of how I would implement what I am
> writing about here, but it reminds me a bit of what I am currently
> doing in aldor-combinat. There we define combinatorial species (which
> are  endo-functors from the category of finite sets and isomorphisms
> to itself. They are implemented as domain constructors in Aldor, but 
> as the theory goes, one can form a semi-ring where species would be
> the elements. This is in so far similar to what I was writing about
> above as I like dimensions to be domains. But later on you should be
> able to multiply together such domains.

Right.  Dimensional analysis would require that ability, as does
defining derived dimensions.

> Another remark concerns dimensional analysis... If in Axiom
> dimensions are implemented as types, couldn't then the dimensional
> analysis be done by the compiler? Types on the right and left hand 
> side must match. What about thinking along these lines for
> implementing dimensions in Axiom?

Yes, that is an interesting way to go - it would mean that equations
defined using dimensions could be checked as dimensionally correct
before they are ever used (that's one of the ideas I REALLY like about
a dimensional system in Axiom - any equation properly defined using the
units and dimensions system could be guaranteed to be dimensionally
correct.  Not a guarantee that the formula is correct of course, but it
would catch certain types of conceptual errors.)  I was hoping to get
this more or less for free from Axiom's domain/type systems - does it
require extra work?

> Maybe some day I'll find time to code my ideas into Aldor which would
> then be open for criticism.

That would be great!  I'm trying to think about this in order to make
the units paper something more than just an idea exposition (i.e. make
it a real pamphlet) but as Tim says there is no such thing as a simple
job.  This is compounded by being somewhat different from "typical"
mathematical programming in Axiom.

Cheers, and thanks again.

Cliff

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com