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] Semantics


On 3/5/06, David A. Wheeler <dwheeler@dwheeler.com> wrote:
> This was stated:
> >> why not make it so that text constants can get
> >> auto-converted to numbers using only the english locale ?
>
> A politically correct way of saying this is the "C" locale,
> if you wanted to do this.  The C locale uses "." as the
> decimal separator.

Okay, C locale is it, then. Although I do't really care about
political corectness in something that's not an official public
statement.

> There are pros and cons to doing this,
> but I'm delighted to see this dicussion winnow out the pros and
> cons.  I see the semantics issues as one of the harder areas to
> gain agreement on, so having this discussion now (so it can get
> worked out long before the deadline) seems like a good idea.
>
> Yet another alternative is to try to accept both "," and "." as
> decimal points.  That risks ambiguity unless you FORBID
> thousands separators, and I don't think anyone DOES it
> (suggesting it's not actually that useful).  I don't actually think
> that'd be a good idea, but it's worth mentioning for completeness.

Yes, forbid thousands separators. And before someone disagrees:
What I mean, is forbid thousands separators in text constants.
So, "3333" is 3333, but "3 333" is an error.
Locale-specific conversions should only happen in a carefully selected
subset of functions. For example, =VALUE("3 333") would be 3333, if "
" is the decimal separator. All this is about the storage format, of
course. Entering content to cells will surely still use locales. Apart
from the text constant part, that is.

I know that this solution is not fully ideal, but it does solve the
concerns raised, while at the same time allowing for extensions
(complex numbers entered as "1+4i" anyone?).
The only other option that was proposed, was to completely throw away
automated converting of strings to numbers. I don't like this, as it
restricts too much, and the only problem was inconsistency amongst
locales - forcing one locale only increases possibilities, because the
other option is not to have conversions at all, localed or not.

/ Tomas


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