octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #60539] Slow performance of betaincinv.m


From: Michael Leitner
Subject: [Octave-bug-tracker] [bug #60539] Slow performance of betaincinv.m
Date: Sat, 29 May 2021 05:18:16 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #22, bug #60539 (project octave):

Re comment 20:

I repeat what I said in comment 12: There is a difference between step and df.
step is the update to x that should be gone in order to get betainc(x) to the
correct result, df is the update that actually has been done, which is
different from step because the x that should be chosen is in general not
representable in finite-precision arithmetics. We have identified a
problematic behaviour, which is due to betainc(x) being constant over a range
of different x, which in my first implementation lead to the algorithm
updating x again and again by small increments on the order of eps (always the
same length), until finally betainc(x) made the jump, the algorithm would have
to go into the other direction, at which point it stopped. The solution was to
stop already if the step length does not decrease any more (it does not have
any more to be zero or reverse). 

However, if you condition on the behaviour of step, the following problem
could appear: step (the desired update) could decrease slowly, but the actual
update would stay the same. Then we would have again the old problem. I
*think* now that this should not happen, because the initial point is chosen
so that during convergence the derivative always decreases, thus for a
constant deficiency in function value (because betainc has this step-like
behaviour) step should actually increase (because the derivative is computed
directly in terms of exponentials and logarithms which should hopefully be
accurate to an eps). But it would be relying on extremely small differences of
finite-precision floating-point values, which I am personally quite
uncomfortable with. If you do it, please add a comment in the code that a more
defensive coding (and in my view also more obvious) would be to test on df,
the actual difference in x, if at any time it should appear that there are
still problems with the stopping condition.

Other than that, fine, please check it in. Perhaps also a few tests on the
previous bug #60528 with really extreme parameters (a/b close to 0 or in the
order of 100, y close to 0 and 1, "upper"/"lower") would be nice, always
testing whether betaincinv(betainc(x))==x up to an eps. 

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]