Re: [office-formula] Semantics

[Daniel Carrera <daniel.carrera@zmsl.com>]

Tomas Mecir wrote:
> The problem with COUNT/COUNTA: what if a cell contains a string that
> can be converted to a number ? Say, "3". What then ? With this
> approach, COUNT doesn't include this, but your average user will say,
> but it's a number.

But now you are getting into the area of UI.

Let's suppose that the spec says that COUNT shouldn't count "3" but 
COUNTA should. I don't say that the spec should say this, I'm just 
giving an example. Let's suppose the spec says that. The application 
writer is still free to make their user-visible COUNT equivalent to the 
spec's COUNTA. So, if (say) KSpread wants COUNT() to count everything, 
they can do that, and just *save* the file using COUNTA. When I open the 
file in Gnumeric I'll see the result that the writer intended.

The problem arises when KSpread opens a file that has COUNT. The correct 
behaviour (in this example) would be to count only numbers. So KSpread 
would have to come up with some syntax to show this to the user. Perhaps 
a COUNT_NUM function, I don't know.

> I think this introduces the problem of our goal: shall we design a
> spec based on real spreadsheets, or also put in new/changed things, if
> we feel that it makes sense ?

I would be happy to change things if they make sense. Generally I'll try 
to change them in a way that can accomodate everyone's syntax. That's my 
natural impulse. The problem with that is that it might create an overly 
complex spec, so take my comments with a grain of sand. I'll try to not 
make life difficult for implementors. That is very important.

Cheers,
Daniel.
-- 
      /\/`) http://opendocumentfellowship.org
     /\/_/
    /\/_/ I'm not saying there should be a capital punishment for
    \/_/  stupidity, but why don't we just take the safety labels
    /     off of everything and let the problem solve itself?