Hi Niklas,
Niklas Nebel schrieb:
On 09/27/08 20:06, Regina Henschel wrote:
In the ODFF draft spec of CHISQDIST is a constraint for the parameter
'degrees of freedom' to be integer.
Shouldn't the argument type be "integer" instead?
It seems to be an open ToDo, see remark at the end of part 6.2.5.
Should I implement it:
(1) break with an "illegal argument" error, if the value is not an
integer
or
(2) round the value to an integer.
The current implementation of the complement function CHIDIST rounds
the incoming value, but the spec has the same constraint for
LEGACY.CHIDIST.
I would prefer version (2) to make it consistent with existing
CHIDIST. And changing CHIDIST too, I consider to dangerous, because
existing documents might no longer work.
Yes, for the implementation, let's stay consistent with the other
functions, that is, truncate (not round) the value.
Current implementation of CHIDIST has
::rtl::math::approxFloor(GetDouble());
I'll copy it in that way in CHISQDIST in CHISQINV.
The current implementations of CHIDIST and CHIINV have a constraint
'degrees of freedom < 1.0E5'. The spec don't have such restriction nor
mention that they might be necessary. The code has no comment, why
this constraint has been introduced. Can you tell me? Huge values
might overflow oder underflow somewhere, but is that reason enough to
reject them from the beginning?
The old implementation (before issue 90703) looks like it couldn't
handle large values. If you're confident that the current implementation
is better, I think that constraint can be removed.
When degrees of freedom is large and x-values is a little bit smaller
than degrees of freedom, you get a "no convergence" error. When x-value
is a little bit greater you get a value, but that is less accurate than
for small values of degrees of freedom (but more accurate than the old
implementation for largest possible values). That would be something to
be mentioned in the Wiki. If x-value is not so near to degrees of
freedom, you will get 0 or 1, which are correct values in that cases. So
I see now reason, not to remove the constraint.
kind regards
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
