MathGroup Archive 1997

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Re: Another Bug in Mathematica 3.0.0 definite integration

> > >unfortunately I found another erroneous result in  a definite integral
> > >in Mathematica 3.0.0
> > >
> > >        a=Integrate[1/Sqrt[Sin[x]+Cos[x]], {x,0,Pi/2}]
> > Mathematica would give you at least a warning, suggesting to
> > carefully check the convergence.
> > 
> > Integrate::gener: Unable to check convergence
> Mathematica 3.0 gives the same messages already. This were also no
> improvement, because for this integral there is no convergence to
> check. And, in a previous post, somebody had an obviously finite
> integral which Mathemetica declined to evaluate because of that
> ´convergence test´. A response by Wolfram recommended to turn this test
> off (in general? in that case?). At least here, it is totally nonsense.
> Concerning the actual problem: The primitive of the integrand
>   1/Sqrt[Sin[x]+Cos[x]
> involves hypergeometric functions (after Simplify):
> (Cot[(Pi - 4*x)/4]*Hypergeometric2F1[1/4, 1/2, 5/4, 
>      (1 + Sin[2*x])/2]*Sqrt[2 - 2*Sin[2*x]])/
>   Sqrt[Cos[x] + Sin[x]]
> and these being multivalued in general, it is conceivable that
> Mathematica is ignoring the branching behaviour while computing the
> definite integral. This is supported by the Plot of the above
> expressiion which clearly has a jump at x=Pi/4. If you take this into
> account by hand (no comments), you get the explicit value
> (2*2^(3/4)*Sqrt[Pi]*Gamma[5/4])/Gamma[3/4] - 
>    2*2^(3/4)*HypergeometricPFQ[{1/4, 3/4}, {5/4}, -1]
> which has the correct numerical value.
> Is there anybody who has received information on this bug by Wolfram, 
> the impact of it on other integrals, possible workarounds and whether
> they are willing to provide a fix?
> Matthias Weber

One fix in this example is to change the warning message to explain the
problem more completely, so that the behavior of this example becomes:

In[4]:= Integrate[1/Sqrt[Sin[x]+Cos[x]], {x,0,Pi/2}]

   Warning: Integrate was either unable to find or compensate for
    discontinuities in the range of integration, or was unable to verify
    convergence of the integral.

            3/4                    1  3    5 Out[4]= -2 2   
HypergeometricPFQ[{-, -}, {-}, -1]
                                   4  4    4

You are correct in observing that the difficulty is in finding and
compensating for the discontinuity in the indefinite integral.  If you
would like, it would be easy to arrange for Integrate to return
unevaluated in examples like this where it has not yet been programmed
to verify the correctness of the result.

I'm not sure what you mean in saying that there is no convergence to
check, since it would seem that there is always convergence to check,
even if that check is trivial.  I'm also curious about what response,
and in what context someone recommended turning this test off (and how
they proposed to do it).

Dave Withoff
Wolfram Research

  • Prev by Date: Re: Not a machine-size real number?
  • Next by Date: Re: slow rendering on WinNT4
  • Previous by thread: Re: Another Bug in Mathematica 3.0.0 definite integration
  • Next by thread: Re: Re: Another Bug in Mathematica 3.0.0 definite integration