Re: [office-formula] CONVERT - why not metric prefixes everywhere?

[Eike Rathke <erack@sun.com>]

Hi David,

On Tuesday, 2007-02-06 19:29:42 -0500, David A. Wheeler wrote:

> > We should add a portability constraint though that prefixes to other
> > than metric units may not be supported by applications.
> 
> Okay, will do something like that. But I won't say "metric units",
> I'll identify each unit that MUST have prefix support, and note that
> an implementation MAY support prefixes for ALL units.  I did find
> a funny conflict ("hh"), which is true for Ecma too,

First I was tempted to say "'hh'? what 'hh'?" because it never occured
to me and is not mentioned in an Excel 2003 online-help, but then
I looked up in Ecma and there we have "HPh or hh: Horsepower-hour" and
"H or hp: Horsepower". However, the latter is wrong and not recognized
by Excel, it is 'h' respectively 'HP' instead.

> and I also found a solution for it (prefer the no-prefix
> interpretation as a tiebreaker).

Sure, works.


> > Hmm.. "Pi" might conflict with "Pica", even if there is no unit "ca". So
> > far simply parsing away a prefix was a valid approach without these
> > binary prefixes.
> 
> There's no "ca", so no issue.

I just wanted to point out that an algorithm using the "parse away
prefix" approach that (apart from the horsepowers) worked so far, when
adding a "Pi" to its list of prefixes, will leave a "ca" only. Of course
this can be prevented by trying a full match of known units first.

> I think it's safer to say that the binary prefixes are ONLY guaranteed
> to work for the information units, that eliminates many problems.

Fair enough.

> > > Is there some reason the metric prefixes shouldn't be just accepted everywhere?
> > > And should we also permit "b" (bit) and "Byte", along with binary prefixes for these two?
> > 
> > I don't see a strong reason why we should not permit it, with the
> > restriction of not being portable.
> 
> Why not just require it?  As my last post noted, I plan to merge OOo
> and Excel's capabilities, so no current application will implement all
> of CONVERT anyway.  But it should be easy for implementors to add.

> If one vendor chooses to not implement the complete function, it's not
> surprising that some documents can't be supported by that vendor's
> application.

Ok, I reword: with the restriction of not being interoperable with Excel ;-)


> > Btw, OOo supports square and cubic
> > measures such as "km2" and "m3" and "acre" and "ha", and many more. Also
> > velocities like "m/s" and "km/h" and "kn" are supported. Do we want to
> > add them all?
> 
> As you can see from my last post, I think the answer is "yes".  Then
> we can support spreadsheets that use them!  I think we should permit
> alternate spelling using "^", e.g., "m^2"... that is a much more
> common representation out there.

Actually I've seen more m2 in the wild than m^2, IMHO most people would
not use 42m^2 in daily writing but write 42m2 instead.

  Eike

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