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

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

Rob Weir:
> 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.

I intentionally didn't include it; when I looked, there seemed to be some disagreement over its exact value. (Light-year doesn't have that problem; meters are defined by light-speed, and the IAU has declared that a "year" for this purpose is 365.25 days). E.G., Wikipedia claims "The currently accepted value of the AU is 149 597 870 691 ± 30 metres".

If you can point me to an authoritative source (Wikipedia isn't) that gives its exact value, great.  I don't mind, as long as we can find an authoritative source for its value.  [UNITED] gives 149597.870 Mm as its value.  Alternatively, I guess we can give its physical definition, which implies that as the value's measure improves, applications will need to change the conversion factor (!).

Oh, you DO NOT want to use "ua" as its abbreviation (the BIPM abbreviation); the "a" is also "year" AND "are", so "ua" would be considered a "micro-year" or "micro-are".  Ugh.  I suggest AU instead, if added.  That is what ISO 31-1 and [UNITED] uses.  Note that IAU recommends "au", ANOTHER CONFLICTING abbreviation.  "au" is a terrible unit name, because it conflicts with atto-u, so I think we should go with ISO 31-1 and [UNITED]'s choice.

You'd think that standards bodies would manage standardize UNIQUE ASCII NAMES for every unit, but you'd be wrong.  Hopefully the latest ISO/IEC unification process will produce that.  I want to maximally make CONVERT accept standard (ISO/IEC) symbols where there's agreement; when the standards disagree it's much harder to figure out what to do.

> 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 don't think that's a real problem now.  We have several saving graces that make this MUCH less worrisome:
* CONVERT only permits conversions if the "from" and "into" units are in the same group.  So you can't convert meters into grams.  So even if there are MANY units, as long as the groups are small it's very unlikely.
* By saying that applications SHOULD NOT permit prefixes for all unit symbols, but instead for only a limited set, we limit the number of extraneous units. Also reducing the risk of a mistake.
* The unit names are case-sensitive.  Again, this makes the likelihood of "guessing wrong" go down even further.

In short, a mistake is very likely to return Error, not a useful value. By design.

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

WAY beyond.  Google calculator does this, as do many other programs, so there's precedence for this.  But I don't know of any spreadsheet app that does this.

If we're doing something today that would directly PREVENT something useful in later versions, please let us know!  Especially if it's arbitrary.  But otherwise, let's work on today's work :-).

--- David A. Wheeler