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

[William Sit]

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.  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).

> 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.

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. 

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?), 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? 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].

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.]
 

> 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.) 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. 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 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.
 
> 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"?

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.
 
> 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.

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).

> 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.

William