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

[William Sit]

C Y wrote:
> 
> On Saturday 10 September 2005 02:13 pm, William Sit wrote:

[snipped]

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

OK, so (below) "dimension"="normal dimension" = "regular dimension"=
"non-reduced dimension". That's a lot of unnecessary aliases. In documentation,
it is important not to fall into using colloquial English when precision is
needed.
 

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

So may be we should adopt that. It would avoid confusion between unit and
dimension.

[snipped]

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

To me, a derived dimension is one which is obtained as a product and/or quotient
of other dimensions (which may be derived and/or basic), but is given a name.
The name describes a term used in the expert area. So <Pressure> is one since it
is defined as <Force>/<Area>. We should allow derived dimension to be defined
this
way, but the point is, a derived dimension has an associated name (like
<Pressure>) and it is this name that is used for later references. In some
sense, a dimension is the name of some property  of one or more objects, and a
unit in this dimension is a quantitative measurement of the property. So
<Pressure> is the name of the property of fluid or gas when their molecules
bombard on a surface and may be measured in say, [Pascal] or [Atmosphere].
 
[snipped example discussions on <Energy> and on <Work>/<Moment>]

> > I think maintaining a full history may be done in a chain. 
[snipped]
> 
> 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?  

That would be a quite a feat, if it were implemented (surely, it is possible).
Whenever (in any language) an expression is computed, the formula may or may not
be retained, and often, it is not when simplification occurs. This is especially
true when there are numerical computations. In the example I gave:

> >   E := setDimUnit("Energy", "kwh", p*t - m*g*h - 1/2 * m * v^2)

any of the identifiers may have symbolic or numerical values involved, and there
is no reason to expect that in the Rep for E, this expression will look anything
like the input expression. My comments on "history" were limited to the
"history" of the dim field in the Rep of E and p. The only one who retains a
knowledge of how E depends on p is the user (through a trace of the inputs).

C Y wrote:
> > > 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.

This is still not clear to me. The word "product" means "result"? You are
confusing "unit" with "dimension"?  Can we give a (pseudo) grammar for what is
<dimension>? From what we have discussed, it seems there are three aspects of
any dimension: a name, a definition, and a reduced form. The name may be
optional, in which case, perhaps we should use as default the reduced form
(converted to String) as name. Here is what I propose as a start, to accommodate
the three aspects: the three fields are tagged by name, definition, and reduced:

  <Basic> := <Mass> | <Length> | ...

  <Name> := "String" | <String> 

(here, String stands for any string, or perhaps identifier, and the two forms
using double-quote or pointed brackets, are considered as interchangeable; a
full grammar for such strings is omitted; <Mass> is an example.)

  <Basic-Dimension>:= (<Mass>, <Mass>, <Mass>) | 
                      (<Length>, <Length>, <Length>) |
                      ...

(this means, the name is <Mass>, and is defined in terms of <Mass> from <Basic>
and the reduced form is also <Mass>)

 
  <Reduced> := "1" | <Basic> | <Reduced>*<Basic> | <Reduced>/<Basic> 

(more precisely, products or quotients of <Basic> in lowest terms, whose
grammatical definition is omitted)

  <Definition> := <Dimension.name> | <Definition> * <Dimension.name>
          | <Definition>/<Dimension.name>

(this means a dimension's definition is formed using a product or quotient of
previously defined dimension names)

  <Dimension>:= (<Name>, <Definition>, <Reduced>)

(not included in the grammar above is the requirement that the reduced part
should be obtained by reducing the definition part to lowest terms; under this
production rule, <Basic-Dimension> is part of <Dimension>).

(If you prefer, you can read the above from bottom up, so that <Dimension> is
the sentence symbol of the grammar).

Note that <Derived-Dimension> is nothing but <Dimension> \ <Basic-Dimension>.

Examples would be

    (<Pressure>, <Force>/<Area>, <Mass>/(<Length>*<Time>^2))

    (<Force>, <Mass>*<Acceleration>, <Mass>*<Length>/<Time>^2)

    (<Area>, <Length>^2, <Length>^2)

In the same way, we can define the grammar for Unit, with an added tag:
abbreviation. (Details left as an exercise for the reader :-))

    

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

This is not what I would call "reduced dimension". I would say the ENTIRE
expression <Mass>*<Length>/<Time>^2 is ONE reduced dimension, namely, the
reduced form of <Force>. Each component is a BASIC-dimension. In the paragraph
below, you WERE using "reduced dimension" in MY sense.

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

Why do we have ANY (casual) simplification FROM base dimensions TO derived
dimensions? Need to clarify your thoughts -- after some sleep? :-).
 

> > > > 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.
> Sorry.  regular dimension = normal dimension or just plain "dimension".

But I want to keep the two (reduced and not-reduced) forms of a unit, if they
are different. So I may want to use both [Newton] and [kg][m]/[s]^2 for the unit
of <Force>. Another example, for the unit of <Pressure>, I want to keep three
aspects of it: name, definition, and reduced (just like Dimension); and in
addition, abbreviation.

    ([Pascal], [Newton]/[m]^2, [kg]/([m]*[s]^2), [Pa])

If such information is derived from information retained in <Pressure>, we will
only be able to use the default units, not perhaps the user chosen units after
using a setDimUnit command. Note that in the above, I have not included the
Dimension for the unit named [Pascal]. This is because in case there is no name
(or if the default name is simply the definition or reduced tag value), then it
would not be clear what dimension the unit should belong to. If a Dimension MUST
be included, then it would be biased in the sense that the programmed code may
use that more often over other possibilities because of convenience.
 
[snipped]

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

I take that to mean you want to force the user to associate a dimension with a
unit he uses. That's reasonable. However, for the system, a unit can be
standalone and not associated with a dimension until used. The representation
for a dimensionless unit like radian can be:

   ([Radian], [m]/[m], [1], [rad])

I think it would make more sense to require that a basic unit be associated with
a basic dimension, because the dimension would be unique.

William