[WP34s] Regularized incomplete Beta function

[Dieter]

(05-05-2014 02:20 AM)Paul Dale Wrote:  The one df case is implemented as tan(pi(x-1/2)) which loses digits in cases like these.

If this really got implemented it should quit with an error message as soon as x resp. p is small enough so that 0,5–p equals 0,5. E.g. p=1E-50 becomes tan(pi/2) which is not defined. But since there is no exact n-digit value for pi/2, the result becomes meaningless: my 34s returns t^–1(1E–50, 1) as +1,7924 E+33. Yes, a positive result. For comparison, the true result is –3,1831 E+49. Actually +1,7924 E+33 is returned for any (!) input below 1E-34. Arguments below 0,1 lose one digit per magnitude. That's why t^–1(1E–10, 1) has merely 34–10 = 24 valid digits. And so the result is bogus for any input below 1E–34. In other words, the current implementation is not just inaccurate, it's simply buggy. Sorry. ;-)

Quote:I missed the transformation to -cot(pi x) when I implemented this I'm pretty sure TAN is up to the task.

That's exactly why the Normal and now the Student QF code use two different ways of evaluating CDF(x) – p. A special one for cases close to the center and the straightforward method otherwise.

Likewise, if the Student dof=1 case is calculated directly, two different methods should be used as well:

if p ≤ p_crit: t = –cot(pi · p)
if p > p_crit: t = tan(pi · (p – 1/2))

Where p_crit can be anything between 0,1 and 0,4.

Quote:More usefully, your QF implementation isn't much longer than the current one and it avoids the generic solver. I might see if I can substitute it on the 34S too. It isn't all that straightforward because several functions you use are implemented in XROM and can be used directly. Rather, they have to be called using XEQ and they'll mess the stack up.

I see. Please also do your own tests. And I would love to know how fast this might run in compiled C code, e.g. on a 31s. ;-)

Dieter