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 - why not metric prefixes everywhere?


Eike Rathke:
> Ecma says uppercase 'H' or lowercase 'hp' for horsepower. Both are not
> accepted by Excel 2003, but lowercase 'h' and uppercase 'HP' are.
...
> I doubt they intentionally spec'd something that doesn't fit with older
> releases in the sense that this argument's value can't be interpreted
> anymore just because they flipped cases.. however, I currently have no
> access to an Excel 2007 installation to verify.

Hmm, good point. I think we should flip it, and make a note.  Probably add a TODO to "doublecheck this" in a few weeks.

Can anyone confirm or deny what Excel 2007 does?  I think nobody believes the Ecma spec.

> > You could treat some things as a special case, but I don't understand
> > how OOo could do that. "m" is a metric prefix, but it's in front of
> > mi, mi2, mi3, mph, etc.  "u" is a prefix and also begins "ui_pt" and
> > "us_pt".
> 
> OOo tries to match the whole string as unit first, only if that fails it
> tests for prefixes.

Perfect; that implements the disambiguation text I've already put in.  I'd expect a typical implmentation to (1) try without prefix, (2) try with prefix.

> > The U.S. NIST's "Guide to the SI, with a focus on usage and unit conversions" at:
> > http://physics.nist.gov/cuu/Units/bibliography.html
> 
> Thanks for the URL. Nice overall title btw, "The NIST Reference on
> Constants, Units, and Uncertainty", I know they refer to the uncertainty
> of measurement results, but in our context it gets a different meaning..

:-)

> Other URLs, some with a more dense overview than the NIST pages:
> http://scienceworld.wolfram.com/physics/SI.html
> http://www.metas.ch/en/scales/index.html
> http://www.simetric.co.uk/

Thanks.  The NIST pages are worth noting, though, because in the U.S. they're the closest thing to being authoritative.  (NIST is the U.S. government arm responsible for weights and measures.  I say "closest thing", because although they technically are authoritative, how the U.S. typically views standards is rather different than most of the rest of the world...!)

> > Is there an
> > objection to supporting an optional "^"?
> 
> I'm fine with that if it's additional.

Okay!  We have an agreement.  So _both_ "m2" and "m^2" will be okay for square meters, etc.  That should serve everyone.

> <sidenote>
> In fact Germany already demands since a few years [ago] that measurements of
> end consumer products are to be given in metric units. No one remembers
> the metric size of a 17" monitor screen or 3.5" diskette, but anyway ;-)
> Btw, to complicate things, a 3.5" floppy disk never was 3.5" but 9cm
> instead..
> </sidenote>

<sidenote^2>
Floppies are a particularly funny example.  The 3.5" drive was said to store "1.44 megabytes", but the "mega" was neither base 10 nor the "mebi" of base 2, but a hybrid. It actually stores a 1.44 kKiB (kilo-kibibytes) capacity, that is, 1,440*1,024 bytes, or 1,474,560 bytes. See http://en.wikipedia.org/wiki/Megabyte
This kind of size confusion is a good rationale for supporting binary prefixes.
</sidenote^2>

--- David A. Wheeler


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