grafted the change to stable with
http://hg.savannah.gnu.org/hgweb/octave/rev/6a1f89bb969c

updated fixed release.

and of course only now do i see i mis-named the function as betainf in all of my commit messages both times. (function itself is fine though).

Looks good to me. Closing as fixed.

@nrjank re comment #8: Are you intending to graft this to stable? If you do, pls change the Fixed Release.

ok. made some small function changes and pushed
http://hg.savannah.gnu.org/hgweb/octave/rev/43d010974a89

to default.

The main change is adding shortcut paths for integer x and adding x = 0 or 1 cases to the trivial input handling.  also reduces repeat TAIL option checks and adds input validation for nonnumeric inputs, plus some BISTs

(No user visible changes, could push to stable and merge but haven't built stable to run a make check first.)

marking as ready for test.

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.

But other (even non-special) functions give a double when the input is an integer, even if the result is an integer itself

> x = int8(0);
> y = sin(x);
> z = cos(x);
> whos
Variables visible from the current scope:

variables in scope: top scope

  Attr   Name        Size                     Bytes  Class
  ====   ====        ====                     =====  =====
         x           1x1                          1  int8
         y           1x1                          8  double
         z           1x1                          8  double

Total is 3 elements using 17 bytes

@type coversion:

A design principle within octave is that the key input variable data type determines the output data type.

So if x is a float one would expect (and gets) a float as output type.

Therefore one might expect an int as output type if x has int as input type.

Note that the numerical result is 0 or 1 so an integer value even when the data type may be different.

The betainc function betainc(x,a,b, tail) seems to have a minor cosmetic bug concerning the aimed parameter input conversion when x is an integer.

## Convert to floating point if necessary
  if (isinteger (x))
    I = double (x);
  endif
  if (isinteger (a))
    a = double (a);
  endif
  if (isinteger (b))
    b = double (b);
  endif

  ## Initialize output array
  I = zeros (size (x), class (x));

The statement I = double(x) does not make much sense as I is overwritten in all cases a few lines below.



Without spending much time on it:

It appears that the numerical result is still ok. Possible allowed integers (0 <=x <= 1) can only be 0 or 1 and therefore the betainc result is still 0 (when x=0) or 1 (when x=1).

But moving the initialize section BEFORE the possible conversion and setting x to double(x) seems a more logical solution, though.

  ## Initialize output array
  I = zeros (size (x), class (x));

  ## Convert to floating point if necessary
  if (isinteger (x))
    x = double (x);
  endif
  if (isinteger (a))
    a = double (a);
  endif
  if (isinteger (b))
    b = double (b);
  endif