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!
- From: robert_weir@us.ibm.com
- To: dwheeler@dwheeler.com
- Date: Tue, 13 Feb 2007 13:04:31 -0500
If we have light-year and parsec, then
how about the Astronomical Unit (AU), which is abbreviated "ua",
"au" or "AU"? It is used for distances to plants,
comets and other solar system objects.
As far as the overall workings of this
function, my main concern is that when a function is rich enough to do
everything, then it will be more likely to give strange and mysterious
output in the presence of a typographical error. In other words,
when everything means something, errors are hard to detect. (Imagine
using the Oxford English Dictionary as your spell checking dictionary.)
Although we can be clever in picking unambiguous, non-overlapping
abbreviations, users will not be so lucky. No one reads the manual.
They'll guess and sometimes get it right, but sometimes get it wrong.
And when it is wrong it will just give a wrong answer.
I think we can solve this all so much
more elegantly by allowing numbers to have units. So, allow someone
to enter "3 meters" into a cell, and have it calculate correctly
when added to "24 inches". And just as someone can format a field
to display different date formats, they could format cells to display US,
Imperial, MKS or CGS units. Of course, that is something beyond
ODF 1.2.
-Rob
"David A. Wheeler"
<dwheeler@dwheeler.com>
02/13/2007 12:04 PM
Please respond to
dwheeler@dwheeler.com |
|
To
| office-formula@lists.oasis-open.org
|
cc
|
|
Subject
| Re: [office-formula] CONVERT - big issues,
and let's add the tons! |
|
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]