[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Semantics
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?