OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hi David,

On Tuesday, 2007-02-13 12:04:02 -0500, David A. Wheeler wrote:

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

"Mandate lots of units" would actually mean which? 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.

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

> some older symbols for backwards-combatibility (sic :-) ),

nice one :)

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

> 2. Proposal: DON'T use the [UNIFIED] symbols directly in most cases.

Given your explanation I agree. It's useful, but as they say: "The focus
is on electronic communication, as opposed to communication between
humans."

> 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. However,
almost no one, I guess, would add a prefix to hours or days. Do we want
to permit them anyway? OOo currently does.

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

Width-of-Table, ancient measurement for cakes.. no, just joking.

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

> 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

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

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

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

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

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

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
fundamental constants", see
http://www.bipm.org/en/si/si_brochure/chapter4/table7.html
Should we add the 4 "Units accepted for use with the SI", eV, Da, u and ua?

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

Mentioned at "Other non-SI units not recommended for use"
http://www.bipm.org/en/si/si_brochure/chapter4/4-2.html

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

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

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

Maybe they are used, Wikipedia explicitly lists them:
http://en.wikipedia.org/wiki/Tonne

There is also use of 'Tt' thousand tons in business reports, so that
might be confusing. 'kt' though sometimes is used also. And there is use
of 'dt' decitonne in German agriculture. So probably yes, allow
prefixes, and don't add 'ct' carat.

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

> * 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'?)

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

'dwt' again.

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

See above.

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

  Eike

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]