Re: Some bugs in Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg59579] Re: Some bugs in Mathematica
- From: Maxim <ab_def at prontomail.com>
- Date: Fri, 12 Aug 2005 03:37:56 -0400 (EDT)
- References: <ddcaga$52g$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
On Wed, 10 Aug 2005 07:31:22 +0000 (UTC), Dana DeLouis
<delouis at bellsouth.net> wrote:
>
> Hi. For your first example, I see that the equation is now:
>
> equ[n_]:=Sum[(Gamma[-k+n-1/2]*Gamma[k+1/2])/
> (Pi*Gamma[n-k]*Gamma[k+1]),
> {k,0,n-1}]
>
> It looks to me that one gets an answer of 1 only if n is a positive
> integer.
> Examples:
> equ[4]
> 1
>
> equ[7]
> 1
>
> However, if n is not a positive integer, then the answer is not 1.
> equ[8.3]
> 0.9112451645862876
>
> It appears that you have to tell Mathematica to make the assumptions
> that n
> is an integer. However, the following below was returned unevaluated. I
> tried all variations on the theme below, but could not get a return
> value of
> 1. Maybe someone can jump in and take it from here...
>
> Assuming[n>=1&&Element[n,Integers],
> Sum[(Gamma[-k+n-1/2]*Gamma[k+1/2])/
> (Pi*Gamma[n-k]*Gamma[k+1]),
> {k,0,n-1}]]
>
> <returned unevaluated...>
>
The assumption is not necessary, because generally Mathematica assumes
that Sum[expr, {k, a, b}] implies that (b - a) is integer and
non-negative. See
http://forums.wolfram.com/mathgroup/archive/2005/Jan/msg00542.html for a
discussion of certain related issues.
The sum in question is an interesting example because it illustrates some
tricky points about implicit assumptions. Suppose we try to find the value
of the sum in the following way:
In[1]:=
s = Series[Sum[Gamma[n - k - 1/2]*Gamma[k + 1/2]/
(Pi*Gamma[n - k]*Gamma[k + 1])*x^k,
{k, 0, n - 1}],
{x, 1, 0}, Assumptions -> x < 1]
Out[1]=
SeriesData[x, 1, {(Gamma[3/2 - n]*Gamma[-1/2 + n]*(-2*EulerGamma - I*Pi -
Log[-1 + x] - PolyGamma[0, 1/2] - PolyGamma[0, 1 - n]))/(Pi*Gamma[1 -
n]*Gamma[n])}, 0, 1, 1]
In[2]:=
s // Normal // FullSimplify // Simplify[#, Element[n, Integers]]& //
Limit[#, x -> 1, Direction -> 1]&
Out[2]=
0
The problem is that the result of FullSimplify contains expressions like
HarmonicNumber[-n]*Tan[Pi*n], and Simplify[HarmonicNumber[-n]*Tan[Pi*n],
Element[n, Integers]] gives 0. This is because for integer n Tan[Pi*n] is
always equal to 0, and HarmonicNumber[-n] isn't simplified to anything --
it is ComplexInfinity only for some values of n. So we have a product of
the form someexpr*0, which evaluates to 0. If we omit Normal, then the
result of FullSimplify will have a different form and we'll obtain the
answer which is correct for positive n:
In[3]:=
s // FullSimplify // Simplify[#, Element[n, Integers]]& //
Limit[#, x -> 1, Direction -> 1]&
Out[3]=
1
I suppose in some cases such implicit assumptions are unavoidable or
making them explicit would just overcomplicate the computations. For
example, the antiderivate of AppellF1[a, b1, b2, c, x, y] with respect to
x can be given as (c - 1)/((a - 1)*(b1 - 1))*AppellF1[a - 1, b1 - 1, b2, c
- 1, x, y], but one might argue that to get the complete answer we should
include the condition a != 1 && b1 != 1 && c != 1 and probably exclude
some other degenerate cases as well.
Still, there are some potential problems with this approach of returning
'generically valid' results. Consider the expression UnitStep[-x^2], which
Mathematica simplifies to 0. The first problem is that some operations
will inevitably return incorrect results. For instance, the values at
isolated points cannot be neglected if we need to find the limit:
In[4]:= Limit[UnitStep[-Sin[x]^2], x -> Infinity]
Out[4]= 0
There are points where UnitStep[-Sin[x]^2] == 1 in any neighbourhood of
Infinity, and so the limit doesn't exist. But if Limit already internally
simplified the first argument to 0, then we just get the limit of a
different function.
Second, this approach doesn't work well with assumptions (as we already
saw above):
In[5]:= FullSimplify[UnitStep[-Sin[Pi*k/2]^2], Element[k, Integers]]
Out[5]= 0
Now it is correct for odd integers and fails for even integers, so the
result can hardly be considered as generically correct.
Next, this may not interact very well with functions such as Reduce, which
should return the output which is logically equivalent to their input:
In[6]:= Reduce[Pochhammer[0, n] == 0, n]
Out[6]= True
The input is false for non-positive integers, so we can claim that Reduce
gives an incorrect result. Again, Reduce may have internally applied
FunctionExpand to the input (or some other function which converts
Pochhammer[0, n] to 0), and then we're in fact solving an entirely
different problem. So we just can't tell which operations are 'safe' to
use if we need equivalence transformations only.
Maxim Rytin
m.r at inbox.ru