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

[Eike Rathke <erack@sun.com>]

Hi David,

On Wednesday, 2007-02-14 14:16:09 -0500, David A. Wheeler wrote:

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

Ok. I'll browse through again by the end of this week when the new draft
document will be up.

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

Reconsidering I'd just keep it and don't make it optional. There is no
clear rationale in drawing an arbitrary line between units we already
supported.

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

Well, ok, it may even ease implementation when requiring square and
cubic of all distance measures.

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

I think the less we define optional / not required the more
interoperability we achieve. So from that POV we should require units
that have a clear and unique definition and were used before or found be
worth to be added, or are squares/cubics of lengths.

So as long as no one objects I'd not add a new not/required column to
the table.


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

Just a misunderstanding, I did not propose to restrict prefixes to
10^(<0) for seconds, it was more an introduction opposed to the
following

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

Agreed.


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

If we want to use "uk_" for all those to be differentiated, I'm fine.
I don't know much about the U.S. customary units vs. Imperial units
usage, just thought that "long hundredweight" 'lcwt' and "long ton"
'lton' might be common. So that would be 'uk_qt' quarter, 'uk_cwt'
hundredweight and 'uk_ton' for the Avoirdupois system then?


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

Arghl. From the Wikipedia page I thought that the definition of an
"Gunter's chain" (66 ft (survey it seems)) _is_ accepted and it would be
equal to a "surveyor's chain". If it's not, let's drop it. I'm not
interested into adding yet more of that nonsense.

> > Btw, 'cable' is used in nautics, 1/10 nautical mile.
> 
> But is it widely-used enough to add it?  To mandate it?

Forget it, I stumbled about http://en.wikipedia.org/wiki/Cable_length
We'd just have another 4 different definitions, common, ordinary, US
Navy and Royal Navy. For the common usage of 1/10 nautical mile it's
easy to divide by 10.


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

Yes, the value is the 100 cubic feet.


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

But the table/algorithm would need an exception then just for this one.
And the user would had to remember, just in case.. nah, if we define
prefix usage for 't' let's drop 'ct'.


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

Ah, true, I missed that one and eV.

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

It seems 'Da' "dalton" is identical to 'u'. I guess we don't need it
additionally, so we're fine then with those.


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

ok ok.. uk_ton then


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

I just cite the first subsentence: "A pennyweight (dwt) is an obsolete
unit of mass" ... obsolete. On the other hand, citing from
http://en.wikipedia.org/wiki/Tonnage

| Deadweight (often abbreviated as DWT for deadweight tonnes) is the
| displacement at any loaded condition minus the lightship weight. It
| includes the crew, passengers, cargo, fuel, water, and stores. Like
| Displacement, it is often expressed in long tons or in metric tons.

we may as well drop the deadweight ton, if it's "long tons or metric
tons". So one point for uk_ton.

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

Agreed.

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

Same solution, uk_ton.

Gee.. are we through with this now?

  Eike

-- 
Automatic string conversions considered dangerous. They are the GOTO statements
of spreadsheets.  --Robert Weir on the OpenDocument formula subcommittee's list.