ODFF: more suggestions

["David King" <openoffice@drking.plus.com>]

Hello folks
From draft 2008-06-18::

POISSON:
 - I suggest further Constraints: 'x and lambda should be 
integer'.

FORECAST:
 - parameters given in the wrong order (at least for Calc, Excel)

NumberSequence:
 - is a type, but undefined. There ought to be a plain list of 
parameter types in the index - section 6.2.6 defines conversion 
to this type, not the type itself. In other words, the function 
descriptions should give parameter types which can be looked up 
in one place in the index. 
 - 6.2.6 makes no reference to how the sequence is generated - 
rows before columns? columns before rows? Order is vital for 
example in CORREL.

CORREL:
 - NumberSequence could be generated by ignoring eg text. Say 2 
columns of numbers with some text entries, in different rows. As 
currently defined CORREL would happily correlate that nonsensical 
data, as long as the lengths were the same. Should be defined to 
return an error.

ZTEST:
 - Calc has had a bug - with 3 parameters it simply gave an 
incorrect result. Excel produces a result which I contend is 
'one-sided' (not 'one-tailed'). It's a ridiculous result, but can 
be used. There's a back-to-basics review at
http://qa.openoffice.org/issues/show_bug.cgi?id=90759
that might help to put this one to rest.

MATCH:
 - Doesn't currently say anything about what type of error is 
returned. Shouldn't a failed search always return #N/A, which is 
testable?  From Section 4.5: "one error value in particular is 
distinct: #N/A"

DDE:
 - "mode 0 - Data converted to number(s) using the default cell 
style" - actually data is only converted to number (singular I 
think) if possible, otherwise text is returned.
 - Is it converted using VALUE, or some other way? 
 - The "default cell style" is mentioned here for the first and 
only time - does this imply this function is only for 
spreadsheets? Shouldn't there be a bit more about the "default 
cell style"?

CHOOSE:
In 3.1 Expression Syntax: " 3a The values of all argument 
expressions are computed, that is, formulas are normally 
"eagerly" evaluated. Exceptions to eager evaluation are noted in 
the function or operation's specification;"
=CHOOSE(1;SQRT(4);STYLE("Heading")) in Calc does *not* evaluate 
the STYLE function. Might be a problem with Calc, but I suspect 
that we need to note an exception to eager evaluation for CHOOSE. 
(STYLE is specific to Calc - it's simply the example I found.)

All rather nitty gritty stuff I'm afraid. 


David King