Re: [sc-dev] Implementation details for FDIST
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 x0 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 pgpArdsRJU7Sk.pgp Description: PGP signature
Re: [sc-dev] Implementation details for FDIST
Hi, On Sunday, 2009-04-19 20:35:09 +0200, Eike Rathke wrote: 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. Blah, that's of course ScPow() and not ScExp(). Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgp441LJXtqRg.pgp Description: PGP signature
[sc-dev] Implementation details for FDIST
Hi, besides the UI-name problem I come across two other questions. (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. For x0 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. (2) The algorithm is not stable for large values of the degrees of freedom. There are some critical parts in the term, for example BETA(r1/2;r2/2) in the denominator which is near 0 then, and x^(r1/2-1) which will overflow or underflow. I can of cause alter the way the term is calculated, but I found, that there are always critical subterms. The problem is, that the calculating as a whole does not abort with an error, but returns some values which are wrong. You see that they are wrong, if you calculate a series of values, but you do not notice it, when you calculate a single value. I notice such problems, when I create large tables of example values. 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? Please decide about a restriction. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
