wrong subs in rising_factorial

[mantepse]

Steps To Reproduce

sage: var("a, b")
(a, b)
sage: rising_factorial(a, b).subs({a:1})
gamma(b + 1)
sage: rising_factorial(-a, b).subs({a:1})
0

Expected Behavior

The result should be rising_factorial(-1, b), which is 0 only if b > 1.

Actual Behavior

The result is 0.

Additional Information

#19461

Environment

not relevant

Checklist

• I have searched the existing issues for a bug report that matches the one I want to file, without success.
• I have read the documentation and troubleshoot guide

[harith-hacky03]

@mantepse Can start working on this?

[mantepse]

No need to ask, @harith-hacky03. If you think you can do it, propose a pull request. Do you understand the mathematics behind it?

[pawani27]

@mantepse Can this be happening because gamma(-1) is infinity? To solve this can we just put a condition there that is: if a<0 and b>(-a) only then for gamma to return?
I am a new contributor, so I apologise if it sounds stupid

[harith-hacky03]

@mantepse Yes , i understand it , i got some conclusions can you let me know is it correct or anything needs to be changed ?

Thank you : )

[DaveWitteMorris]

I don't think there is actually a bug here. The basis of the issue is the claim that rising_factorial(-1, b) is not 0 unless b > 1, but that's simply not true. This function is defined for every complex number b, and it is zero everywhere except at certain integers. Thus, it can be simplified to 0, because (I think) the general rule in symbolic computation is that two expressions are considered to be equal if they are equal almost everywhere (so, for example, we simplify x/x to 1).

It might be good to have a function that only applies to integers (which seems to be what was in mind when the issue was raised), and rising_factorial would probably be a good name for it, but that's not this function. It's an enhancement request for another function. Perhaps the current function should be renamed (perhaps Pochhammer symbol?), so that the function for integers can have the good name, but that would require deprecation.

It should be noted that the proposed PR does not actually fix the reported issue: even with the PR applied, rising_factorial(-1, b) simplifies to 0. I think that's good, because I think 0 is the correct answer, but the PR should not say that it "Fixes #39406".

Another problem is that I don't think the PR is doing what it should. It adds code for certain cases where a is a nonnegative integer, but there is nothing wrong with the existing code for that case. If code is to be added, I think it should be for cases where a is a negative integer, by using this formula:

rising_factorial(x, -a) = 1/rising_factorial(x-a, a)

If this formula is going to be used for negative integers, then the documentation would need to be updated to say this. I think this might be a good enhancement, but it's not addressing the original complaint (which I think is invalid).

[mantepse]

I don't think there is actually a bug here. The basis of the issue is the claim that rising_factorial(-1, b) is not 0 unless b > 1, but that's simply not true. This function is defined for every complex number b, and it is zero everywhere except at certain integers. Thus, it can be simplified to 0, because (I think) the general rule in symbolic computation is that two expressions are considered to be equal if they are equal almost everywhere (so, for example, we simplify x/x to 1).

I don't like this answer, but I think it is completely correct :-) In fact, I never conciously realised when two expressions are supposed to be equal. I like your definition, even though it is problematic in my case.

I was trying to implement transformation of sums into standard hypergeometric form, i.e., each summand is represented as a quotient of products of rising factorials. I then wanted to do a naive check (because I had a bug), which failed, because this representation depends on $(-1)_0$ being $1$.

[DaveWitteMorris]

Thanks for your reply. After further thought, I don't think my answer is "completely correct". Although it might be true that there is no "bug" right here, there is certainly a problem. I'm pretty sure that the idea of identifying two symbolic expressions that are equal almost everywhere is stated explicitly as a principle in the documentation of ginac (but I may well be wrong that it's accepted as a general rule). It makes sense, but it can lead to mathematically incorrect results, as you have pointed out here. It is especially problematic when, as in this case, the set of measure 0 happens to contain an important part of the domain. I don't know what to do about this in general, or even in this particular case, because I think it would lead to a mess if we tried to special-case the exceptional set in these situations, but I do not like that symbolic calculations cannot be trusted to be correct everywhere.