Re: [office-formula] A-functions

["David A. Wheeler" <dwheeler@dwheeler.com>]

> On 9/8/06, David A. Wheeler <dwheeler@dwheeler.com> wrote:
> > I think it would be DISASTROUS to spec something we KNOW
> > is not true, and will NEVER become true.  Better to make it
> > implementation-defined... which is in fact what we do.

Tomas Mecir:
> Hmm. Basically, you are suggesting to write in the spec something
> like: "Implement this function how you want" ?

No, in most cases we can be very specific.  It's only in oddball special
cases where we have to say "implementation-defined", and even in those cases,
we can limit the options greatly.  Presumably launching a nuclear
warhead isn't one of the expected options when you get text :-).
Various options include ignore text, convert to 0 (always), convert to number, error.
Consider what happens when you get text that CANNOT be converted
into a number.

> I'm not sure if we'll
> manage total compatibility that way, but ah well, seems like there
> isn't any better option.

Right.  That's the problem.  I think this is the "best we can reasonably do".

And actually, since that we're writing things down, this is very helpful
for people who create documents - they now will know what things to
NOT depend on.

I think people will be much happier with the result (in practice) this way.

> Sooo.
> Bot A and non-A treat numbers as numbers.
> If the implementation doesn't have distinct logicals, then logicals
> always get treated the same as numbers.
> If the implementation supports logicals, A version treats them as 1
> and 0, non-A is implementation specific.

Again, two cases.  For the "A" case, I believe they are converted to 0/1
BOTH if they're inline AND if they're in a reference.
Make sure you include tests for both cases.  Also, include test cases to see
if a single-cell reference is different than reference ranges;
they aren't different for Excel, but they ARE different for Pocket Excel
(PDA version), IIRC.  Yes, that IS an incompatibility between Excel
and Pocket Excel; that is NOT my fault :-).

You don't need to worry about defining the "non-A" case, that's
already defined in the spec (see "Convert to NumberSequence").

> As for strings, the behaviour is implementation-specific. A-version is
> never allowed to ignore it, it must somehow convert the string to a
> number - either parse the number, or just use 0.

For the A-versions, there are two cases, inline and in a range/array.
What do the applications do, in each case?

> Non-A version can
> either convert the string to a number, or ignore the string entirely.

No, it depends on whether or not it's in a range.  But again, the
non-A case is already specified.

> All these functions must behave in the same way for one implementation
> - ie., if SUM treats logical/strings in some way, COUNT, AVERAGE, ...,
> all must treat them the same.

Correct.

Though be careful; NOT all the "A" functions have the same functionality;
the "A" functions simply mean "not the usual NumberSequence semantics".
Certainly MINA and MAXA should have the same semantics, but don't
expect them to be the same as COUNTA (for example).  I _think_ COUNTA
is the main oddball, but there may be others - keep your eyes peeled.

> Are the rules regarding these functions good enough now ? :)
> Also, where to write them ? I think it'd be bst to write these in some
> section somewhere, and in each related function, point the reader to
> that section, so that we don't have to copy-paste these rules 20
> times.

We're WAAAY ahead of you :-).
That's the whole purpose of the "Convert to NumberSequence" etc.
implicit conversion functions - to define those semantics in one place.
Functions like SUM (etc.) accept a list of NumberSequence, with the
"normal" semantics for such functions.

So if you have a set of functions that do NOT accept a NumberSequence,
or a list of NumberSequence, then you need to define a new
"Convert to...." function for a new pseudotype, and then use that
pseudotype in the definition for input.

I think most of the "A" functions use the same semantics - do you want
to call them a "NumberSequenceA"? Then just say that they accept
a "list of NumberSequenceA", and describe what they do.
See "Convert to NumberSequence" for an example; you can probably
just copy that text, and then describe the differences.

WARN me if you make changes outside your section, though, or it'll be
quietly ignored (NOT copied) when I merge the files...!  I'm guessing you'll
want to add a new "Convert to..." section, which I expected you to do, just
tell me what you call it...!

--- David A. Wheeler