Hi Regina,

On Monday, 2009-04-13 22:42:07 +0200, Regina Henschel wrote:

> besides the UI-name problem I come across two other questions.

For clarification: we're talking about ODF FDIST here, as opposed to
LEGACY.FDIST

> (1)
> If the numerator degrees of freedom (r1) is 1, then the density function  
> has a pole at x=0. The draft spec does not define the return value in  
> that case.

So it should mention to return an error in that case.

> For x<0 it defines that the return value is 0. For x>=0 it  
> defines it with a term which has a subterm x^(r1/2-1). And x^(-1/2) is  
> not defined for x=0.
> I can set the result to 0 or set "illegal argument" or perhaps set  
> "infinity". Please decide.

I think letting the calculation just run into an error the same as
occurs for the expression =0^-1 in ScInterpreter::ScExp() is fine, which
should result in #NUM! being displayed.


> (2)
> The algorithm is not stable for large values of the degrees of freedom.  
> [...]
> Therefore I would like to restrict the degrees of freedom to be lower  
> than 1.0E15, where I do not saw any problems. The current implementation  
> (=cumulative right tail) has a restriction of <1.0E10. Excel and  
> Gnumeric have restriction to about <1.0E10 too. Are larger values really  
> needed in "real live"?

No idea.

> Please decide about a restriction.

I will bring that to the attention of the OASIS committee. I'm all for
introducing the restriction.

Thanks
  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD

Attachment: pgpArdsRJU7Sk.pgp
Description: PGP signature

Reply via email to