Message Boards Message Boards

3 Replies
0 Total Likes
View groups...
Share this post:

Bug? Pochhammer, Gamma and FullSimplify gives a/a=2.

Posted 11 years ago
This appears to be a faulty defnition in mathematica, I'm using mathematica 8.

Using the Following code:
Product[(m + i) (m - (i + 1)/2)/2, {i, 0, m - 2}]
% /. m -> 3
I get the answers:
(-1)^m 4^(
1 - m) m (-1 + 2 m) Pochhammer[2 - 2 m, -2 + m] Pochhammer[
  1 + m, -2 + m]
(4^m Sqrt[\[Pi]]
    Gamma[-1 + 2 m])/(m (-1 + 2 m) Gamma[1/2 - m] Gamma[
    1 + m] Pochhammer[2 - 2 m, -2 + m] Pochhammer[1 + m, -2 + m])
The original form is correct, the simplified version contains an incorrect factor of 2. If non-integers are used in the replace the ratio becomes equal to 1 only because both sides are then incorrect by the same factor (Should be 15, not 30). Using "Assume m is an integer... " does not simplify to Gamma functions and therefore doesn't have the same problem.

This feels like a faulty defintion in mathematicas simplify commands, or have I missed something?
3 Replies
I'm not familiar enough to guarantee whether this is correct or not without looking much deeper. That said, this looks like a case of generic simplification doing something unexpected, but not really incorrect. This is one of the more common gotcha's about symbolic mathematics that you don't really encounter until you use a system like Mathematica.

Mathematica's simplifications are generically correct. This means that they can be wrong for isolated points, such as for the integers in some cases. Here's a simple example of that:
Integrate[x^n, x]
Everyone and Mathematica agrees that this is evaluate to x^(1 + n)/(1 + n), but that's not true because when n=-1, the result should be Log.  So when we say that the integral is equal to x^(1 + n)/(1 + n) we mean so generically. You see this as an issue appearing often when asking Integrate to work with Orthogonal functions as well. 

It's hard to work without these generic transformations, but like I said, I haven't taken an in depth look into your problem. It just looks like a case of generic simplification. 
POSTED BY: Sean Clarke
That was my first thought too, in which case there should be a warning that the solution is only valid for non integers.

The reason I dont think this is the case is two fold:

1.) The simplified function with Gamma's is continuous throughout all real values I've tried and is exactly twice the Pochhammer version at all integers tested. 30 for m=3.

2.) The Pochhammer function is primerily defined as a function on the integers, which gives a value of 15 above. Trying to input a non integer into the pochhammer version converts it to Gamma's automatically. This results in a function tending to the 30 in the limit of m=3, but having the value of 15 at m=3. This therefore gives a discontinuous function which exactly halfs its value at the integers. The only values I can test are at the integers which I'm pretty sure are correct for the Pochhammer version, and although I don't know how the function should behave, this seems particularly strange behaviour.

It just feels like whever wrote up the conversion missed a factor of two in their derivation. Interestingly this only works for this very specific equation, any variation I tried resulted in either the correct answer or indeterminate value.
I would send in this example to Woflram Technical Support ( letting them know that you think it's wrong.

They can often determine themselves if it is incorrect or not, but at very least notify the appropiate developer so they can take a look at it and resolve it in the future. 
POSTED BY: Sean Clarke
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
or Discard

Group Abstract Group Abstract