Re: [Axiom-developer] Unit package proposals and questions

[C Y]

On Saturday 10 September 2005 02:13 pm, William Sit wrote:
> C Y wrote:
> > --- William Sit <address@hidden> wrote:
> > > C Y wrote:
> > > > Mass[r]*Length[r]/Time[r]^2
> > >
> > > No [IMHO]. This adds something unconventional and complicates things.
>
> [snipped]
>
> > Hopefully this could be done with some conditional outputform tweak
> > based on the Rep, so maybe a system setting to enable or disable this
> > would be a good idea, assuming I can convince you it's a good idea -
> > )set ShowReducedDimensions true  or some such.
>
> I think the global )set is the wrong place, since a lot of users are not
> going to bother with units (or have no need to use units). If you really
> like to use a different but optional notation in output for reduced
> dimensions, then use a set command in the package (and even include this in
> the category specificiation), remember this in the state vector, and modify
> the outputform coercions to do it.  

Sounds good.  There are a fair number of options worth tweaking in a units 
environment, so that mechanism is a good one to nail down early.

> This is different from the )set 
> UnitSystem because one cannot include this setting in a unit system domain
> without first choosing the domain, whereas the reduced dimension flag may
> be unit-system dependent. (Even for the )set UnitSystem case, I have also
> suggested a simpler )library command to replace the )set command).

Sounds good.  Whatever the best way is, so long as we document it ;-).

> > The reduced dimension flag tells us that these dimensions are the
> > result of a substitution for some derived dimension, but otherwise we
> > allow things to proceed as normal - the reduced dimensions of work and
> > moment of force are the same, even though the derived dimensions
> > themselves are not.  The implication is that a reduced dimension
> > differs from a normal dimension in its history, but not in any
> > functional way, which also implies that its history is somehow
> > "inherent" in the Rep.  (one of the reasons I am in favor of preserving
> > the dimensional history of a reduced dimension in its Rep).  Just by
> > making the distinction, we are stating that there is something about a
> > reduced dimension compared to a regular dimension that MIGHT matter -
>
> You have to define "normal dimension" for me.

Opps - sorry.  "normal dimension" would in this case be a "non-reduced 
dimension," which may not be much more informative.  More on this below.

> It may not be easy to trace what you called "history". My use of reduced
> dimension is strictly reducing a derived (or basic, which would be
> unchanged) dimension to a product and quotient of basic dimensions (that is
> where the idea of using a (free) abelian group written multiplicatively to
> model Dimension comes from), where each basic dimension only appears ONCE
> to some power.

Sounds good. (the abelian part).  

> Let's consider a hypothetical situation where electricity is used to raise
> a big steel ball with mass m to a certain height h and then give it a
> certain velocity v; assume that energy in the form of electricity can be
> provided at a rate p for a period t, we want to compute the excess
> electricity (as a margin of error) using the formula:
>
>    E = p*t - m*g*h - 1/2* m*v^2
>
> where p is power in [kw] and t is time in [hr], and the rest are potential
> energy and kinetic energy imparted to the ball (neglecting all other loss
> of energy due to friction, etc), resulting in an expression for excess
> electricity capacity which the user wants to express in [kwh]. This may be
> accomplished under the present proposal as:
>
>   E := setDimUnit("Energy", "kwh", p*t - m*g*h - 1/2 * m * v^2)
>
> assuming all the other quantities are assigned their correct dimensions and
> units already. In reduced dimension, <Energy> = <Length*Mass^2/Time^2> but
> for E
> (I am starting to use pointed brackets to enclose dimensions IN 
> DOCUMENTATION rather than the string quote even though they may be
> represented internally as strings; what do you think?), 

Hmm - not a bad idea, since interacting with them will be quite different from 
string interactions at the user level, in all likelyhood.

> this basic 
> dimension expression comes in three different ways of expressing energy, in
> terms of derived dimensions such as <Power>, <Acceleration>, <Velocity> and
> the basic dimensions <Mass>, <Length>, <Time>. How would you capture the
> "history" of E in its Rep?

I wouldn't capture it in E exactly, except maybe as a consequence of 
incorporating reduced dimensions.  I need to define my terms - I'll try to 
revisit this issue later - it's an excellent example and my point out flaws 
in my thinking to me.

> If the unit is to be automatically set, E may be 
> assigned to have unit [kg m^2/s^2] or [Joule], but probably not [kwh]. In
> this case, the equation is homogeneous dimensionally and correct. However,
> the user may want the unit to be associated with a derived dimension
> [Power*Time]. There is currently no provision to specify a derived
> dimension as a product. So we may need to create a new one, say called
> <Electricity>. Otherwise, the user's desire can be accommodated by the
> choice of unit such as [kwh].

OK (I think.)  Offhand I'm guessing products as derived dimensions aren't the 
best idea?

> The Rep of E in the example above would be, if it includes the reduced
> dimension:
>
>    Record[value=E, dim = "Energy", reducedDim = "Mass*Length^2/Time^2",
>           unit = "kwh", etc.]

OK, that looks good.

> > there may be some incompatibility not expressed in the dimensional
> > representation as it currently exists, although we don't know what.
> > Certainly, if I divide work by moment of force, this is a dimensionless
> > number in terms of reduced dimensions but not in terms of derived
> > dimensions, and I would be happier if the "dimensionless" number
> > remembers something about this.
>
> The dimensionless case is but one instance of the many-to-one (indeed,
> many-to-many) mapping of units to dimensions. We can capture (partially)
> the nature of a quantity with dimension <Work>/<Moment> with the following
> Rep:
>
>    Record[value=work/moment, dim="Plane Angle", reducedDim="1", unit =
> "rad", etc]
>
> To understand this, think of the moment generated about the pivot when the
> end of a lever, of distance ell from the pivot, is rotated through an angle
> theta with a force of constant magnitude f, always perpendicular to the
> lever. The ratio <Work>/<Moment> may be meaningful; the total moment is
> computed by the (scalar) product of the magnitude of the force f, and the
> distance ell to the pivot, but the work is computed via an integral of a
> dot product for vectors, since the direction of the force is constantly
> changing along the tangent of an arc. The force vector is a function of
> theta, and is given by
>
>     F(theta) = (f sin(theta), f cos(theta))
>
> and the infinitesimal change in position r through which this force acts to
> produce work is the vector (where r is the position vector for the point of
> application, relative to the pivot as the origin)
>
>     d(r) = (ell sin(theta) d(theta), ell cos(theta) d(theta))
>
> giving the infinitesimal work done as
>
>     F(theta) . d(r) = f*ell d(theta)
>
> so that the total work through an angle theta is
>
>    work = integral(f*ell d(theta)) from 0 to theta
>         = f*ell*theta
>
> Hence work/moment =  theta [rad]. (If my analysis above is correct, this
> explains in some detail why the two are different.)

I'll need to think about this one some more after getting some sleep ;-).

> Since the derived 
> dimension for <Plane Angle> is actually <Length>/<Length>, the reduced
> dimension is just "1", but to say that <Work>/<Moment> is dimensionless is
> not to recognize the physical difference between the two. Note moreover,
> the derived dimension of <Plane Angle> does not capture the full physical
> meaning either. A better unit may be [N-m/N-m] (recall that [m/m] is [rad]
> too) and unless we create new names for each of these many-to-many
> instances (for both dimension and unit), it is hard to assign derived
> dimensions. So a more desirable design would be to allow an expert user to
> add derived dimensions (and units) on the fly, and using a Dimension domain
> constructor with arbitrary set of dimensions may be the way to do that.

OK.

> By
> using the idea of a quotient of a free abelian group divided by a subgroup
> generated by these new derived dimensions in terms of basic dimensions,
> Axiom can handle such generality. The analog would be the idea of
> polynomial ideals (which captures relations among variables) and the
> quotient ring constructed by dividing a polynomial ring by the ideal. We
> can construct ideals on the fly and work with the quotient ring.

I'll re-read that last part after I get through the Group and Ring chapters in 
those notes ;-).

> > I'll have more details later - I'm
> > still chewing on this issue.  I might be thinking of reduced dimension
> > a bit differently than how it was originally defined - I'll have to
> > look - I'm viewing it as the dimension itself remembering its history,
> > rather than it being the name for a basic dimension definition of a
> > derived dimension.
> >
> > > There should be no difference in the output form. It should be quite
> > > obvious that a dimension or unit output is reduced or not. Plus,
> > > there are dimensions whose reduced dimension is identical to the
> > > dimension. The user can also explicitly ask for a reduced dimension
> > > through functions such as reduce(identifier).
> >
> > It is obvious in the initial substitution, but what if the resulting
> > quantity goes on to be used elsewhere, where its history is not
> > immediately apparent from the environment?
>
> I think maintaining a full history may be done in a chain. However, due to
> the many to many mapping for units to dimensions (and I am not thinking of
> incompatible ones like <Work> and <Moment>, but just say units for
> <Energy>), it will take a lot of new names to separately capture history. I
> still think the units themselves are sufficient indication of the relation
> between (derived) dimension and reduced dimension as far as the user goes.
> In the system, to be able to recognize, say [kwh], or more simply
> [watt-hour] (dropping the prefix kilo) as a unit of <Energy> requires
> setting up such a relation. Any intermediate steps, say how the power p is
> computed before E is computed in the example is not something of interest
> to E, but only of interest to p, and in the Rep of p, we have that
> information. So we can keep the history in this chained fashion, but in
> each identifier, the "history" is short and immediate.

Except E knows about a specific p, and so (in theory) the user could enquire 
about the history of p that E depends on, correct?  I'm not sure whether it's 
actually useful or not to preserve history - it might not be worth the 
effort.  I'll have to think about it some more, in light of your new 
examples.

> > A user can't always ask for a reduced dimension - what would that mean
> > in the case of basic dimensions?  reduced from where?  from which
> > derived dimension?  reduced(Length) wouldn't mean anything, but the
> > Length which is part of the reduced dimension definition of Force is a
> > reduced dimension.
> >
> > I'm not sure I agree there are dimensions whose reduced dimension is
> > identical to the dimension, depending on which definition of reduce we
> > are using.  I view a reduced dimension as a normal dimension which
> > calculates as normal, but preserves information about its origins.
>
> You have to be more precise than that! What is "normal"? "origin"?

Apologies.  Here is how I've been thinking about these terms:

"dimension" or "normal dimension" - a dimension with no historical 
information, which is not the product of a substitution used in calculations.  
Any unit input by the user is a "normal" dimension, as is an dimension which 
passes through calculations without being altered.

"reduced dimension"  - a dimension which is the result of a substitution for 
another dimension.  E.g. if we have <Force> and substitute in 
<Mass>*<Length>/<Time>^2, each of those three dimensions is a "reduced" 
dimension because it was substituted in for a higher order dimension.

Of course, in the Force example the mapping may be unique (don't know offhand) 
in the default SI  definitions, but who's to say a user won't define a custom 
derived dimension with SI base dimensions the same as those of force?  That's 
why I don't want to assume any case where reduced dimensions are identical to 
"normal" dimensions - e.g. their origins can be ignored.  It may be that we 
DO want to ignore their origins, as long as we prevent casual simplification 
from  base dimensions to derived dimensions without explicit user input/rule 
definitions.  In which case "reduced dimensions" would retain no history.  
Needs more thought.

> In mathematics, we consider integers as a subset of fractions, and in
> reducing all fractions to lowest terms, we also consider that reducing the
> integer 2 to lowest terms as reducing the fraction 2/1 to lowest terms.
> This is so that the procedure "reduce to lowest terms" is applicable to all
> fractions, whether the "origin" of a fraction is actually an integer or
> not. I think this convention applies through all subdomains in mathematics
> and in Axiom. So it should be perfectly correct to speak of the reduced
> dimension of a basic dimension in the sense that the set of basic
> dimensions is a subset of all derived dimensions.

OK, I'll agree with that.  

> > I'm working on the interaction rules between reduced, derived, and
> > normal dimensions, although again I suspect I've gone a tad overboard
> > with the reduced idea.  Maybe this weekend I'll get some more written
> > on these thoughts, and realize they make no sense ;-).
> >
> > > Reduced dimension can have reduced units (why not)?
> >
> > Because this information is already in the dimension.  A unit might
> > have either a reduced dimension or a regular dimension associated with
> > it, depending on its history, but I see no reason to impart that
> > information to the unit as well since the unit MUST be associated with
> > a dimension.
>
> Please do not keep adding new terms ("regular dimension") without defining
> it.

Sorry.  regular dimension = normal dimension or just plain "dimension".

> I don't follow the precise meaning of "the unit MUST be associated with a
> dimension".  Do you mean "For each unit, we must specify a [emphasized]
> dimension to which the unit belongs?" I have no quarrel with that. If you
> meant "the REDUCED dimension of the unit MUST be unique", I also agree (at
> least with MY definition of reduced dimension). If you meant "a unit MUST
> be associated with a dimension, but that dimension need not be unique",
> that would be ok also. However, if you meant "a unit MUST be associated
> with a UNIQUE dimension", that I don't agree. The mapping between
> dimensions and units is many-to-many, unless you are determined to create
> new names for dimensions and units to split the mapping to force it to be
> many-to-one, one-to-many or one-to-one (I certainly don't recommend that,
> and won't do that).

No, a unit doesn't need to be associated with a unique dimension.  Agree with 
that.  I just meant "a unit cannot be defined without an associated 
dimension."  Although strictly speaking, dimensionless things like radians 
might make that invalid.  Hmm...

> > Hmm.  Time to regroup and state my ideas on the definitions of reduced.
>
> Precise definitions is the first step, always. Precise statements (even if
> long-winded) is the next.

OK. :-).  I'm working on a (hopefully) precise writeup of my definitions 
(hopefully it will be the first sections of introductory material for the 
eventual units.spad.pamphlet) - once I'm reasonably sure it's ready to be 
shredded I'll post it ;-).  With any luck, once things are reasonably well 
defined we can proceed without too much more trouble to the design issues in 
terms of Axiom :-).

Cheers,
CY