Re: [office-comment] ODFF: more suggestions

[Eike Rathke <erack@sun.com>]

--qoTlaiD+Y2fIM3Ll
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi David,

On Wednesday, 2008-06-25 08:32:32 +0100, David King wrote:

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

Hmm.. x should be Integer, yes (done for draft11), but lambda?


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

Done for draft11.


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

Put on the TODO list. However, in case of CORREL(), if both sequences
are evaluated in equal order, there should be no difference whether it
is row-wise or column-wise, or am I mislead?


> CORREL:
>  - NumberSequence could be generated by ignoring eg text.

Like it is defined in "Conversion to NumberSequence".

>  Say 2=20
> columns of numbers with some text entries, in different rows. As=20
> currently defined CORREL would happily correlate that nonsensical=20
> data, as long as the lengths were the same. Should be defined to=20
> return an error.

This indeed will need some additional semantics. Put on the TODO list.


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

Put on the TODO list.


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

Done for draft11.


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

Something, yes, probably. Put on the TODO list.


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

CHOOSE() is exceptional, similar to IF(). Both functions execute jump
paths, and paths not executed are not evaluated. One can easily verify
by inserting an explicit error to an unchosen path, such as
=3DCHOOSE(1;1;1/0), which behaves similar to =3DIF(TRUE();1;1/0)

Added two sentences for draft11.

> All rather nitty gritty stuff I'm afraid.=20

Nevertheless important.

Thanks
  Eike

--=20
 OpenOffice.org / StarOffice Calc core developer and i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS

--qoTlaiD+Y2fIM3Ll
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJTra/Zcn5tYf41BIRAjVfAJ45Ih0Nxg0jXV7YNTAtQ0sLQyY/ywCfU2gL
dI3NwOLO50JHcifeaYpxFEM=
=l8lJ
-----END PGP SIGNATURE-----

--qoTlaiD+Y2fIM3Ll--