Re: [office-formula] CONVERT - big issues, and let's add the tons!

["David A. Wheeler" <dwheeler@dwheeler.com>]

Okay, I think we're getting towards closure on CONVERT.  This is a painful function to deal with; it touches so many other things, and I don't think many people have really examined this function carefully.  It's taken a while to get through it, and I want to report what I propose to do in case someone disagrees.

Major proposals for CONVERT:
1. Proposal: Mandate lots of units, mandate prefixes Z, Y, z, y, and "da" (10x), binary prefixes.
We've got a pretty long list of units.  My current draft requires nearly all the ones supported by pretty much any spreadsheet implementation including Excel or OOo (e.g., "Pica^3" for cubic Pica), some older symbols for backwards-combatibility (sic :-) ), and standards compliance ("s" for second, "da" for 10x, "ly" for lightyear, etc.).   There's a trade-off.. the more we require, the better for users (because more units interoperate between OpenFormula implementations), but more work for implementors.  Right now I'm theorizing that we want to maximally help users (who have spreadsheet documents that may use them), and adding the units isn't a big deal anyway... so let's give users a really useful function!  I But that means that all implementors will need to add stuff.  If anyone has heartburn with that, please speak up ASAP.

2. Proposal: DON'T use the [UNIFIED] symbols directly in most cases.
"The Unified Code for Units of Measure" by Gunther Schadow and Clement J. McDonald, aka [UNIFIED], is not an official standard, but it's a really useful document. They try to
give unique ASCII names to all units, something we need and the official standards don't do.
Some of their suggestions are great, e.g., "ar" for "are" (officially "a" is both "are" and
"year").  When I first found this document, I had high hopes for it.. until I read it in detail.

Unfortunately, their audience is a highly technical one; many of their symbols are too complicated and risk dangerous confusion by a non-specialist user.  Our users include many users who are NOT that sophisticated; complex unit names risk getting the wrong answer.  So I don't think we should copy their symbols (too bad, the problem they face is the same as us). But they've got lots of good info, so it's an invaluable reference.  And their symbols hint at reasonable symbols for nontechnical users.


3. Proposal: Say "SHOULD NOT permit prefixes on all unit symbols"
Now that I've had a chance to read through everything I can get my hands on regarding measures, I think we should say that applications SHOULD NOT accept prefixes for units unless specifically stated.  So "km" (kilometers) must be supported, but "kmi" (kilomiles) should not be.  That's a change from what I suggested before (look! He _can_ be taught!).  Reason 1: If app A accepts a "kmi", but app B doesn't, we have an interoperability problem. Reason 2: If we accept prefixes everywhere, there's a GREATLY increased probability of future problems with a unit suddenly changing its meaning (because some prefixed form in an earlier version suddenly conflicts with a new unit name).  E.G., if in the future we added a new unit called the "kmi", it would conflict with a current "kilomile".  Best to avoid this.

The good thing is that current apps already tend to do this (I know Excel does).  Even [UNIFIED]  I mentioned above does this; for each unit they note whether or not prefixes are required or forbidden.  And I propose stating this as a SHOULD NOT, so if an app ALREADY does it, they're not required to remove it.  That will ease local transition.

BTW, I've created a huge table that compares lots of different implementations, as well as various other documents. That table makes it much easier to do the comparisons and make rational decisions, and I think explains pretty well why the proposed names are as shown.  I'll include that table in the Rationale section of CONVERT.


Eike said:
> > > Commented as Hundredweight and Shorthundredweight in the sources.
> > > Yet another U.S. invention. Used in commerce, it seems, and corresponds
> > > with 'ozm' and similar. Should use an abbreviation instead, see
> > > http://scienceworld.wolfram.com/physics/AvoirdupoisSystemofUnits.html
> > 
> > Looks like cwt and lcwt are their official abbreviations.
> > 
> > Should we include this?  Just the official symbols, or the older OOo symbols too?
> 
> We can mention the old OOo symbols for reference, but I doubt anyone
> used them because it wasn't clear what they are.

Okay.  There's already text that notes that applications MAY support other unit symbols.
We could add, "For example, applications may support..." and note these symbols and their meanings.  I guess if we're doing "may", we may as well include the old OOo symbol and the official symbol.  A "cwt" would interfere with a metric unit named "wt" (a centi-wt), but I don't know of any "wt"s, so no problem.

I don't think these units are very widely used, even in their claimed field, so I'm hesitant to add them.  I live in the U.S. and I've never seen these measures used.  Officially the "rod" and "chain" are measures, but we don't include them because they get almost no current-day use, and I think the same is true here.

Sound okay?  If someone thinks they're important, please say so; it's not a big deal to add them.  But there are whole databases of weird units out there; let's prefer widely-used ones.

> > > Not mentioned in the online-help is 'brton', Gross Registered Ton, but
> > > that should be 'GRT' then instead.
> > 
> > Aka a "long ton".  "lton" seems to be used too.  Okay, now I know what it is... do we want to include it in the spec?
> 
> GRT isn't a unit of mass. A gross registered ton is not to be confused
> with a gross ton (= long ton), it's a unit of volume instead and equals
> 100 cubic feet. Used to describe the cargo capacity of ships. See also
> http://en.wikipedia.org/wiki/Ton
> We may include it, it is commonly used.

If we're going to add tons, we better add all the widely-used ones.  I believe they are:
* "GRT", gross registered ton, volume, 100 cubic (international) fee.  Not mentioned in [UNIFIED].  I don't think we want to require "brton", it's not really UK-unique.
* "ton", U.S. customary short ton, mass, 2000 pounds (avoirdupois) (this is the U.S. customary ton, aka short ton).  Uses the usual CONVERT convention "non-prefix is U.S. conventional".  [UNIFIED] uses the nasty symbol "[ston_av]".
* "t" - tonne / metric ton, mass, 1000 kg. "t" is the widely-used symbol; [UNIFIED] uses "t" also.  That's a really short unit name, which can be a problem, but it's the normal abbreviation and the fact that [UNIFIED] is willing to make it "t" suggests that it's okay.
* "uk_ton" - Imperial ton, mass, 2,240 pounds.  Uses the usual CONVERT naming convention, with "uk_" prefix meaning "Imperial".  [UNIFIED] uses the symbol "[lton_av]".   Note: the deadweight ton is also 2240 pounds; I don't see the need for another symbol for this.
* "MTON" - Measurement ton, volume, 40 cubic feet.  Not mentioned in [UNIFIED] (note that if we use this symbol, we'll have trouble adding a prefix-permitting "TON"!)
Prefixes forbidden on all but "t"; [UNIFIED] is willing to give "t" decimal prefixes, and tonne is simply 1000kg, so there's some logic in using prefixes for tonne.

One other common ton is the "freight ton" or "measurement ton". It's a unit of volume used for describing ship capacities (tonnage) or cargo, and is 40 cubic feet.  One nasty problem is that its common abbreviations are "M/T", "MT", or "MTON".  All of those abbreviations are easily confused with the metric ton (though at least metric ton is mass, while measurement ton is volume, so CONVERT will notice the problem).  I'd prefer using "MTON", so that we don't cause troubles with mega-T (in general, short symbols can cause more grief in CONVERT, because we want all unit names to be unique).
Confirmations about measurement ton are here:
http://usmilitary.about.com/od/glossarytermsm/g/m3895.htm

By the way, there's a useful U.S. Navy glossary, with many ship-unique measurements:
"Military Sealift Command, Ship Inventory: Definitions, Tonnages and Equivalents" at
http://www.msc.navy.mil/inventory/glossary.htm
Here are its relevant measurements:
* DEADWEIGHT - The total lifting capacity of a ship expressed in tons of 2240 lbs. It is the difference between the displacement light and the displacement loaded. {This is equal in mass to an Imperial ton. I suggest just reusing "uk_ton" instead, since don't see a need for yet another symbol.}
* BARREL - 42 gallons {we agree!}
* GROSS TONNAGE (aka Gross Register and Net Register Tonnage) - The entire internal cubic capacity of the ship expressed in tons of 100 cubic feet to the ton, except certain spaces which are exempted... {Okay, gross register ton = 100 ft^3}
* LONG TONS - One long ton is equal to 2,240 pounds; used to measure petroleum products. {ANOTHER 2240-pound ton}
* MEASUREMENT TON - Bale cubic in units of 40 cubic feet to the ton. {Agrees with earlier}
* WEIGHT TON - Calculated as long ton (2,240 lbs.) Abbreviated W/T.   {ANOTHER 2240-pound ton. We don't want to use "W/T", that implies a division.}
Interestingly, the "hundredweight" measurements are NOT noted here.  They're probably used somewhere, but I think they're disappearing.

The "long ton", "deadweight ton", and "weight ton" are all 2240-pound tons, just like the Imperial ton.  I suggest just using "uk_ton", continuing the tradition that the "uk_" prefix means "Imperial", and not adding all these other symbols for the same thing.


> > > Btw, a 'd' for day would fit into the time quantities.
> > 
> > True, I wasn't sure we wanted to add that.  I fear adding much more.
> 
> This one wouldn't hurt, I think.

Agree, and this addition would make the spec more compliant with measurement standards.  Certainly BIPM etc. use "d" for day.  So let's do it.

--- David A. Wheeler