[Octave-bug-tracker] [bug #64726] Current betainc function has a minor (more cosmetic) bug

[Nicholas Jankowski]

Follow-up Comment #6, bug #64726 (project octave):

i suspect some cases of function-to-function differences are as much a product
of attempted compatibility as deliberate design intent. checking that for
betainc:

matlab 2023b:

>> betainc([0 1], 1, 2)
ans =
     0     1
>> betainc(int32([0 1]), 1, 2)
Error using betainc
Inputs must be real, full, and double or single. 


So no specific compatibility concern here, nor a requirement that we even
accept non-float inputs. 

So, regarding function intent: it performs the integral from 0 to x of a
nontrivial function. But because the matlab and octave definition of the
incomplete beta function normalizes it by the full beta function (beta(a,b),
same integral from 0 to 1), this changes the output values for the valid int
inputs.

x must be [0,1], so the only valid int values for x are 0 and 1.  x=0 reduces
the integral from 0 to 0 which is always 0.  x=1 reduces the integral to
beta(a,b), and the function to beta(a,b)/beta(a,b) = 1.

So it appears that for x = 0 or 1, always I = x. I can't see any example input
that would deviate from this. Separate from the integer class issue, I'd
suggest x= 0 or 1 be added to the trivial cases list that currently only looks
at a and b. 

For integer class input, the multiplications, etc., that would produce odd
results for non integer valued a or b would normally have me recommending
conversion to double, but those calculations are irrelevant due to the math
above. 

So I'd recommend current behavior be maintained if input class of x is int, so
is output class, and as long as x range is [0,1], then use trivial shortcut
path.


    _______________________________________________________

Reply to this item at:

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

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