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


Hi Tomas,

On Tue, Feb 28, 2006 at 11:24:35 +0100, Tomas Mecir wrote:

> First of all, my fundamental principle: as far as the user is
> concerned, there are no datatypes. Everything automatically gets
> converted to what is expected.

This is exactly the hell in which the approach of the one big player
brought us..

> - Numbers are numbers, treated as numbers. No problem here.
> - Passing a number to a string function converts the number to a
> string, using locale settings.
> - Passing a string where number is expected, converts the string to
> some number.

Now consider that you pass the document to a colleague who works with
a different locale. Maybe it breaks.

> 0 if failure. Yes, that's how I did it in KSpread (so I
> may be biased here), and yes, we silently ignore errors, but at least
> we're consistent.

Within one locale.

> - SUM is doing the same, and functions like AVG basically just use SUM.
> - COUNT includes text and boolean and whatnot. It does not include empty values.
> - basically, SUM/COUNT/... become what SUMA/COUNTA/... are now.
> - remove SUMA, COUNTA, AVGA, ***A - or make'em just aliases.

I wouldn't do that if I were you.. after all, these different functions
_do_ exist and they exist for a reason and they're used in the wild,
people are used to them.

> I realize this may create problems, but it follows my fundamental
> principle of no datatypes.

Well, it's your decision, but then you'd have to write COUNTA to the
file format instead of COUNT. And you wouldn't be able to correctly read
a file that uses COUNT.

> Anything else may be easier for the geek population, but
> confusing for anyone else. Imagine a Random User (TM), who has a
> column full of text data and tries to put a count at the bottom;
> =COUNT(range) is the obvious choice, right ? Only that it won't work.

If your application aims at Random User it could inspect the range and
if it ecountered text, after having informed the user, change the
formula to COUNTA(range). Doing so would even educate the user.

> Bad, in my opinion. All this ***A business is only in because
> spreadsheets didn't auto-convert values as needed, thus a work-around
> was necessary.

Bear in mind that AVERAGEA(range) does not convert strings to numbers,
it treats them as zero. This is a different functionality.

  Eike


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