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?


I posted a big email about CONVERT; here are some of my comments on Eike's email, now that I've had a chance to think this through.

> 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, and I also found a solution for it (prefer the no-prefix interpretation as a tiebreaker).

> > so I did a quick test to see if there's a problem if the prefixes are
> > just accepted everywhere.  The attached program creates all possible
> > combinations, and no conflict was found. There isn't even a problem if
> > you also permit binary prefixes (Mi, etc.) everywhere, and support
> > b (bit) and B (Byte) units.  You would only use those prefixes for
> > information units, but even permitting them everywhere doesn't seem to
> > be a problem.
> 
> 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 think it's safer to say that the binary prefixes are ONLY guaranteed to work for the information units, that eliminates many problems.

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

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

> > prefixes = [ "K", "E", "P", "T", "G", "M", "k", "h", "e", "d",
> >             "c", "m", "u", "n", "p", "f", "a",
> 
> What's that with the upper case "K" there?

I wanted to see if adding a "K" would be a problem.

> Should be "Z" (Zetta)
> instead, I think. Followed by "Y" (Yotta) == 10^24. Similar in the other
> direction after "a" follow "z" (zepto) and "y" (yocto).

Agree.  I added them.

--- David A. Wheeler


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