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

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

David A. Wheeler ecrit:
> > 1. Proposal: Mandate lots of units, mandate prefixes Z, Y, z, y, and "da" (10x), binary prefixes.

Eike proclaimed:
> "Mandate lots of units" would actually mean which?

The current list is in the current draft on the OASIS website.  It's everything supported by Excel, almost everything supported by OpenOffice.org 2.1, plus various widely-used measures.  All distance measures have a square and cubic variation, even if they're rarely-used.

> For example, I don't
> think that mandating units that are not already supported by the
> majority of applications would actually make sense if they're not used
> in the wild. For example the Reaumure temperature scale supported by OOo
> may be nice to have, but I wouldn't mandate it. The Rankine temperature
> scale on the other hand would be worth it.

Understand.  Currently Reaumure is in the mandated list, but of course that's just the current proposal.

But that's exactly why I posted this... exactly where we cut things off is going to be arbitrary, no matter what.  I'm fine with mandating Reaumure, with making it optional, and even with not mentioning it at all.  Given your comments, I'm leaning towards making it optional.

> > 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),
> 
> Actually Pica^3 isn't that a good example.. while Pica is commonly used
> in typesetting, square or cubic Pica though theoretically being a valid
> measurement practically don't have any relevance.

Actually, it's a great example of my point (pun brazenly intended).   We have a LOT of units, some of which are of debatable use. I only included Pica^3 becuase Pica _IS_ useful, and it makes sense to have all the cubic versions of the distance measures (and because OOo supports it).

> > 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.
> 
> I don't think that adding units to a table would give any heartburn.
> It's "just" a matter of work and time.

If we want to back off, we could add a new column to the unit symbol table labelled "Required".  An application, to be compliant with CONVERT, "SHALL implement all of the unit symbols marked as required, MAY implement the units not marked as required, and SHALL not implement other additional unit symbols that conflict with any of the following symbols:"

Then make Reamur, Pica^3, etc. optional.

What do you think about that?

> > 3. Proposal: Say "SHOULD NOT permit prefixes on all unit symbols"
> 
> Agreed. There may be some subtleties though. For example, it is
> perfectly valid and common usage to add prefixes for 10^(<0) to seconds,
> as in 'ms', but prefixes for 10^(>0) are at least rare. For 's' being
> the unit for a SI base quantity though it is legal to do so.

That happens with several units actually.  I hesitate to do that; by the official specs, if you can add prefixes at all, you can use any prefix, and in any case what's rare in some places may be common in others.  It could even change over time (as well as by place).  Other people who have thought through this stuff (like UNIFIED) haven't gone down that road, either.  So I think we shouldn't try.

> However,
> almost no one, I guess, would add a prefix to hours or days. Do we want
> to permit them anyway? OOo currently does.

No, I think we should NOT permit prefixes for hours and days.  We're adding the official prefix "d" (day), and eventually in a future version hope to add "h" (hour instead of horsepower).  It's REALLY easy to get in trouble with single-letter symbols that permit prefixes; best to avoid the problem.  And I don't think people normally talk about kh (kilohours) or kd (kilodays), or mh (millihours) or md (millidays).  So we'd be asking for trouble, for no good reason.

The current draft does NOT include prefixes for day and hour.

> > > > > http://scienceworld.wolfram.com/physics/AvoirdupoisSystemofUnits.html
> > 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.
> 
> You probably don't do much shipping.. at least UPS and FedEx know it,
> other freight companies as well, and it seems that sometimes you get
> a different pricing when ordering goods in hundredweights. Search for
> "hundredweight shipping".

Ugh. All right, we can add them.  Should we use "cwt" (100 lb) and "uk_cwt" (112lb), which would continue the original convention of "uk_" for Imperial measures?

> 
> > 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.
> 
> While Rod seems to be a historical measurement, Chain seems to be used
> in agriculture, see
> http://en.wikipedia.org/wiki/Chain_%28unit%29#Contemporary_use

Ugh.  I believe "chain" has the same problem as feet (survey vs. international).  If there are several of these, maybe we need a standard prefix "survey_" (correlates with "uk_" for Imperial and "us_" for U.S.; you don't want to use "us_" as the prefix in this case because BOTH survey and international measures are in use in the U.S.).

> Btw, 'cable' is used in nautics, 1/10 nautical mile.

But is it widely-used enough to add it?  To mandate it?

> It might be the naming of 'brton' currently present in OOo actually
> derived from the German BRT "Bruttoregistertonne", I'm not sure though.

As long as it's the same value we're okay.  Looks to be the same.

> Same category as 'g' gram. What about 'ct' metric carat (0.2g)? Could
> clash with a prefixed 't' tonne though, see below.

Right.  If we have "ct" (caret), then you cannot use "ct" as centi-tonne (I doubt that's REALLY a problem... you'd use kg then).

> There is also 'u' unified atomic mass unit (1.66053886e-27 kg) and some
> "Non-SI units accepted for use with the SI, and units based on

Already in there.  EVERYONE has that.

> Should we add the 4 "Units accepted for use with the SI", eV, Da, u and ua?

eV and u are in.  What's Da?  I presume by "ua" you mean astronomical unit; it turns out that standards differ on how to abbreviate AU, and it's got uncertainty of measure too, so I suggest passing on that for now.

> Btw, not sure if we already came across this for reference of conversion
> factors: http://physics.nist.gov/Pubs/SP811/appenB9.html

You bet.  I read that through before I started, and it's in the citation list.

> > * "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.
> 
> That should be 'dwt' instead, see below.

INSTEAD? Why?  I think "Imperial ton" is one of the most common terms for this measure.  I particularly don't want to use "dwt", because that's ALSO the official symbol for pennyweight.. and I hate to fix a symbol when we KNOW there's a conflict.

> > * "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"!)
> 
> I don't see a metric TON appearing..

Agree.  That's usually "t", and we have that already.

> > [... "M/T", "MT", or "MTON" ..]
> 
> Yes, MTON is better. MT is also used in "MT TNT" (yet another mega-ton),
> M/T looks like a division.

> > http://www.msc.navy.mil/inventory/glossary.htm
> > * 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.}
> 
> The common symbol is 'dwt'.

That conflicts with the symbol for pennyweight, see:
http://en.wikipedia.org/wiki/Pennyweight

Also, this isn't just a mass value, it's a mass value that implies a specific use.  I think we should prefer the general terms that's don't require a specific use.  Thus,  I'd prefer to use "uk_ton".

> > * 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}
> 
> 'GRT' (or 'grt'?)

Yes, I chose 'GRT'.

> > * LONG TONS - One long ton is equal to 2,240 pounds; used to measure petroleum products. {ANOTHER 2240-pound ton}
> 
> 'dwt' again.

Same problem, conflicts with another symbol.

> > Interestingly, the "hundredweight" measurements are NOT noted here.  They're probably used somewhere, but I think they're disappearing.
> 
> See above.

Okay, looks like we'll need to add those too :-(.

> > 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.
> 
> As mentioned, 'dwt' should be the symbol, it seems to be the one that is
> commonly used. In USA long ton is used to distiguish from the 2000
> pounds "short" 'ton', so we might add 'lton' as an alias. Similar to
> MTON I've also encountered it as LT, L/T and LTON.

'lton' and 'LTON' aliases make some sense.

> Don't know if it's
> really used and we may as well do without, but it would complete the
> list from
> http://scienceworld.wolfram.com/physics/AvoirdupoisSystemofUnits.html


Thanks. Whew!

--- David A. Wheeler