Thanks Jake, To everyone else: I was one of the people that helped review gh-15359 and I'd also added a docstring for scipy.special.binom that pointed out this unexpected behavior in gh-15279 https://github.com/scipy/scipy/pull/15279. I'm +1 for deprecating this behavior and want to add the considerations I have. There are some things I think need to be settled before deciding to merge this. Decision: What was decided here was that once the deprecation period ends, to have comb return NaN for non-integral arguments when exact=True, while displaying a warning. This is what is mentioned in the deprecation warning in the PR currently. Tirth Patel (tirthasheshpatel) suggested this behavior. Rationale: Although comb cannot currently handle array inputs when exact=True, we may want to add such support in the future. The expected behavior for ufuncs seems to be to return NaN for entries input array(s) that would error in a scalar version. Note: Updating comb to work for arrays when exact=True seems like it would be difficult, but not impossible. Important consideration: One consideration is that whatever behavior that is decided on here, should ideally be the default behavior for each of the factorial functions detailed in h-vetinari's excellent issue gh-15600 https://github.com/scipy/scipy/issues/15600. So I think this is a bigger decision than it first appears. Ideally we are also deciding what the default behavior should be for all of these cases. Currently, the behavior specified to occur after the deprecation period in this PR is not what occurs for any of the factorial functions when exact=True. In this case factorial raises a ValueError stating that only integral values are accepted, although the message is somewhat confusing since it doesn't mention anything about exact=True, as h-vetinari points out in gh-15600. The other factorial like functions raise TypeError's because internally they assume that the inputs are integers. This is also what happens with scipy.special.perm. It seems that only comb has the confusing behavior where the inputs are truncated to integers. Beyond comb, perm, and the different factorial functions, I don't think there are any functions in scipy.special that have an exact=True option like this. Suggestion: We should decide on the behavior when exact=True for comb, perm, and the factorial functions together, because ideally they should all have consistent behavior. I'm not sure the discussion has ended yet for gh-15600. I would appreciate any input on whether others think returning NaN for non-integral inputs and displaying a warning is a good policy for exact=True for each of comb, perm, and the factorial functions. I think I'm +1 but I'm not sure if there's anything I'm missing. Thanks, Albert On Thu, Feb 24, 2022 at 6:44 AM Jake Bowhay <jb9.bowhay@gmail.com> wrote:

Hi,

I currently have gh-15359 (https://github.com/scipy/scipy/pull/15359) open to deprecate casting to integers for exact calculation in the special.comb function.

Due to this behaviour it is possible to get a less exact answer by setting `exact=True` which is misleading. See the example bellow: ```

...

...

...

x, y = 3.9, 2.8 (comb(x, y), comb(x, y, exact=True)) (4.2071983565457955, 3)

Any comments and discussion welcome.

Thanks,
Jake
_______________________________________________
SciPy-Dev mailing list -- scipy-dev@python.org
To unsubscribe send an email to scipy-dev-leave@python.org
https://mail.python.org/mailman3/lists/scipy-dev.python.org/
Member address: albert.steppi@gmail.com