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] Our next adventure: Types and conversions

Hi Tomas,

On Fri, Jun 02, 2006 at 10:19:06 +0200, Tomas Mecir wrote:

> Well, if your suggestion goes in, then they'll just get an error
> message instead, so the thing won't calculate either. I do see where
> you are trying to go with this, but I don't think that it would help
> much, you just create  a different kind of confusion - "it says I have
> a text in there, but it's a number, look !"

We are defining the ODFF specification here. Applications can still
react on documents loaded from other sources, or if they detect that
text should be used in calculations notify the user in some way. This is
also what Excel does since XP with the green arrow boxes.

> >I don't consider D being basically the same as B. B goes unnoticed,
> >whereas D clearly indicates an error the user either has to correct or
> >won't get a result at all.
> Yet they both do restrict functionality. I think this is where our
> opinions disagree, you're thinking about Joe the user, whereas I think
> about the power users and such.

I've seen thousands of spreadsheets over the last 10 years. Believe me,
this is about Joe User. Even if he's doing highly sophisticated work for
some company.

> >> As for locale conversions, there are three options.
> >> A. ignore the problem and hope for the best.
> >
> >Which is what many spreadsheets do. To my opinion unacceptable.
> Well, possibly, but basing on the problems that we now face, it does
> sound like they have a reason for being that way.

Legacy and sloppiness.

> >> C. number-text conversions first try C-locale, and then try user's
> >> locale. That way, if people want locale-agnostic documents, they can
> >> stick to using C-locale in formulas - not a problem for programmers,
> >> and others won't use this much anyway.
> >
> >Sigh.. again, you are basing this on wrong assumptions.
> Maybe, but what else to use ? You are proposing =VALUEL("12,45", "sk")
> - that would be for my locale, and it is to be treated as "12.45".
> Now, that might work IF all spreadsheets know all locales - only that
> they don't !

Easy to solve: VALUEL( v; decimalseparator [[;groupseparator [;dateseparator]] ... )

> >With the TEXT() function and the '&' operator and CONCATENATE(), yes.
> Yes. What will TEXT() produce ? On an US locale, TEXT(12345.45) will
> output "12,345.45". On my locale, it will be "12 345,45". On someone
> else's locale, it might be something completely different - Chinese
> characters or whatever.

Only that conversion number->text is not as critical as conversion
text->number is. Number->text conversion that includes separators is
mostly used for display purposes to produce "nice" invoices and such.


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

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