[Octave-bug-tracker] [bug #65230] Poor accuracy of betaln for high ratios of a/b

[Rik]

Follow-up Comment #6, bug#65230 (group octave):

On point #2, you're quite right.  There was no reason to be so particular
about the inputs.  It was so easy I immediately fixed that in this changeset
https://hg.savannah.gnu.org/hgweb/octave/rev/4fb466fb717e.

On point #3, we don't necessarily have to follow Matlab, but their betaln
function only accepts real, nonnegative arguments.  Perhaps the easiest thing
to do would be to keep that restriction.  As far as I know, there haven't been
bug reports or requests for extending this function to accept complex values. 
The current implementation of betaln in Octave uses gammaln which accepts
negative arguments, but not complex ones.  So there is no problem with
nonnegative arguments.

On point #1, I think the answer is generally that more accuracy is certainly
desirable as long as the trade-off in computational time isn't too excessive. 
I benchmarked the current implementation with


octave:1> x = 1:1000;
octave:2> y = x';
octave:3> tic; z = betaln (x,y); toc
Elapsed time is 0.020807 seconds.


This calculates 1e6 values and took 20.8 milliseconds which is effectively
instantaneous compared to human reaction times.  I would think even 100
milliseconds would be a worth trade-off.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65230>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/