Re: [office-formula] Our next adventure: Types and conversions

["Tomas Mecir" <mecirt@gmail.com>]

Hi Eike,

On 6/2/06, Eike Rathke <erack@sun.com> wrote:
> Based on my experience with OOo's bug tracking system this indeed is one
> of the main differences that keep people mourning about "my spreadsheet
> calculates different", just because they don't notice that text doesn't
> calculate, respectively calculates as 0 in some cases. This is something
> we'll have to address.

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 !"

> 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. So, the question at hand would be,
whether we want to make things less confusing for group 1, or more
powerful for group 2.
And you know my stand on this :) My experience shows that Joe the user
will be confused about things no matter what, so I'm more inclined
towards making things powerful, rather than limited in functionality
to avoid confusion.

> Everyone who shares documents between different locales. A thing I do
> almost every day. Also see .sig ;-)
> I thought we had been through that already?

Yes but we didn't come up with any consensus :)

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

> We are not talking about power users here. We're talking about the
> average spreadsheet user accidentally having input some number as text.

-grin- Looks like the different views come to play again. I am talking
about someone deliberately inputting a number as a string and
wondering why it doesn't convert :)

> > 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 ! If you have a spreadsheet aimed at US users, and US users
only, the creators of it won't know my locale, thus the program will
not support it. Now, someone with such a spreadsheets wants to open my
document with VALUEL from "sk" locale - and now what ? The spreadsheet
knows nothing about "sk" locale, so what should it do to ensure that
the result will be the same than it is on my computer ?

It simply is not feasible to require all spreadsheets to know all
possible locales, hence such an approach is doomed to failure.

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

I think the problem at hand would be like this: is it at all POSSIBLE
to come up with a solution that would cater to all needs ? The only
solution that would ensure at least SOME interoperability (and that
even in number->string case, not vuce versa unless you use a function
that outputs text in C locale) that I was able to come up with was the
one that I proposed - conversions use C-locale and are stored that
way.

/ Tomas