Unit expression (not handling) proposal

[Bryce L Nordgren <bnordgren@fs.fed.us>]

"David A. Wheeler" <dwheeler@dwheeler.com> wrote on 06/11/2007 04:34:48 PM:

> There's a lot of experience in the Ada community on this very topic.
> Ada has very good strong typing support for "traditional" data
> types, but when people tried to create types like "meters_squared"
> they soon discovered that the "obvious" type systems DO NOT WORK
> when handling unit systems in most cases.  Eventually they had to
> create complex overheads to track the units.

File format specifications (I'm not talking "Formula", but OpenDocument
itself) need only be concerned with the expression of the desired quantity,
and not with how applications implement conversions or even dimensionality
checking.

I'm not suggesting that now is the time to deal with the issue in full.
However, I wish to express my heartfelt opposition to allowing application
authors to drive the standardized expression of something already agreed
upon for decades by such organizations as ISO, NIST, and the national
standards bodies of most (all?) countries.  On the other hand, it is
entirely appropriate to give application developers a free hand when it
comes to handling units within their own application.  That's the line ODF
dances on and that's why it's "the choice that lets you choose".  When the
document is committed to a file, an application's peculiarities should not
be evident.  A different app can read the units, know what is meant, and
handle them however it sees fit.

We know what the apps have to handle, even if we don't know how they will
choose to handle it.  Units are well known quantites, already fleshed out
to a great degree of detail by experts.  Do not leave this to someone
trying to solve a business problem.  They will not be an expert and they
will be trying to solve a much narrower problem.


Now to the fun part of the message: how we might efficiently perpetuate
ODF's dance...

Steal the notion of "dimensionSets" from OpenFOAM
(http://foam.sourceforge.net/doc/Guides-a4/ProgrammersGuide.pdf) Section
1.5, p. 25.  This capitalizes on the fact that there are only seven base
units in the SI system.  Ergo, a vector of seven numbers is sufficient to
express the correct dimensionality for any physical quantity.  Each
component of a vector is the power of the relevant base unit...

Dimensions of vector components:
(mass, length, time, temperature, quantity, current, luminous intensity)

SI base units for vector components:
(kg, m, s, K, mol, A, cd)

Using vector to "dimension" quantities:
+ Length: [SI = m] (0,1,0,0,0,0,0)
+ Velocity: [SI = m s^-1] (0,1,-1,0,0,0,0)
+ Pressure: [SI = kg m^-1 s^-2] (1,-1,-2,0,0,0,0)
+ Power: [SI = kg m^2 s^-3] (1,2,-3,0,0,0,0)
+ Dimensionless (scalar): [SI = ...] (0,0,0,0,0,0,0)

All current numeric datatypes in ODF are Dimensionless.

Currency is hideous and veiled in black magic, but probably handle-able by
considering it "orthogonal" to the set of "real" (physical) units.

To handle currency, add an eighth component.  This naturally allows you to
express cost/unit, cost/time, cost/length, cost/velocity or whatever other
contorted thing the users are going to want without inventing custom
nomenclature which artificially separates currency out as "special".  Apps
can internally deal with this however they want to deal with it, but when
they write out a quantitied number to an ODF file they must follow the
rules.

All "quantitied" numbers are describable using this system.  For quantities
expressed in SI units, no further action is necessary (except to define a
"reference currency").  Other units may be described by "conversions" to
and from SI base.

NOTE: Apps which do not support "quantitied" numbers are free to use the
existing numeric type and pay no penalties.  Apps which do not handle
"quantitied" numbers (but which can read files containing them) should
write out a non-quantitied file using existing numeric types.  Also, they
should use the provided "baseValue" to promote the consistent use of units.




ODF should provide unambiguous communication between apps via:
+ Standardized identifiers for SI base units. ({meter, metre, m},
{kilogram, kg}, ...)

+ Standardized aliases for SI standard derived units (Joules, Watts,
Pascals, Coulomb, Tesla,...)

+ Standardized identifiers for SI unit prefixes ({mega, M}, {micro, mu},
...)

+ A means to describe user-specified aliases for units which are not SI
(hogsheads, cubits, MyPinky, ShareOfGoogleStock).  Apps could maintain
their own unit-alias databases and write the appropriate definition(s) to
the spreadsheet file, much like they now define named styles before they
are used.

+ A means to describe the conversion to the base set of units (SI +
reference currency) from each user-defined unit.  (Hint: use the formula
spec with special tags for "defined unit" and "standard unit")

+ A means to specify the units in which the cell should be displayed.

Potential ODF example:
<customUnit>
      <name>MilesPerGallon</name>
      <abbreviation>MPG</abbreviation>
      <alias>mileage</alias>
      <alias>fuel efficiency</alias>

      <!-- The dimensions of this unit -->
      <dimensionSet><length>-2</length></dimensionSet> <!--all others
zero-->

      <!-- Dimensions of "components" of this unit -->
      <!-- Assumes "mile" and "gallon" previously defined or std. -->
      <unitComponents>
            <factor><unit><name>mile</name></unit></factor> <!--default
power is 1-->
            <factor><unit><name>gallon</name><power>-1</power></factor>
      </unitComponents>

      <!-- How to convert to and from SI (using OD Formula) -->
      <convertToBase>=424776*Defined</convertToBase> <!-- Or legal formula
syntax -->
      <convertFromBase>=Base/424776</convertFromBase>
</customUnit>


<customUnit>
      <name>KmPerLiter</name>
      <abbreviation>KPL</abbreviation>
      <alias>fuel efficiency</alias>

      <!-- The dimensions of this unit -->
      <dimensionSet><length>-2</length></dimensionSet> <!--all others
zero-->

      <!-- Dimensions of "components" of this unit -->
      <unitComponents>
            <!-- Km (the hard way) -->
            <factor>
                  <dimensionSet><length>1</length></dimensionSet>
                  <convertToBase>=1000*Defined</convertToBase>
                  <convertFromBase>=Base/1000</convertFromBase>
            </factor>
            <!-- Liters the hard way -->
            <factor>
                  <dimensionSet><length>-3</length></dimensionSet>
                  <!-- NOTE: Define Liter, not Liter^-1 -->
                  <convertToBase>=Defined/1000</convertToBase>
                  <convertFromBase>=Base*1000</convertFromBase>
            </factor>
      </unitComponents>

      <!-- How to convert to and from SI (using OD Formula) -->
      <convertToBase>=1e6*Defined</convertToBase> <!-- Or legal formula
syntax -->
      <convertFromBase>=Base/1e6</convertFromBase>
</customUnit>



<!-- How efficient is a Go-Kart? -->
<!-- Apps not handling units should use baseValue -->
<measure>
      <value>100</value>
      <baseValue>42477600</baseValue>  <!-- probably optional, but helpful
-->
      <unit><name>MilesPerGallon</name></unit>
</measure>