MathGroup Archive 2010

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

Search the Archive

Re: Possible bug: Integrate[(u - t)*BesselY[0, 2*t], {t,

  • To: mathgroup at smc.vnet.net
  • Subject: [mg108477] Re: Possible bug: Integrate[(u - t)*BesselY[0, 2*t], {t,
  • From: Daniel Lichtblau <danl at wolfram.com>
  • Date: Fri, 19 Mar 2010 02:49:01 -0500 (EST)

Leo Alekseyev wrote:
> Consider the following symbolic expression, evaluated with Mathematica 7:
> Integrate[(u - t)*BesselY[0, 2*t], {t, 0, u}]
> 
> I am seeing a behavior where the symbolic results of this integration
> are different depending on the name of the symbol 'u'.  In particular,
> if I use something that precedes 't' in the alphabet, such as 's', the
> result is
> (-Pi^(-1) + s*(Pi*s*BesselY[0, 2*s]*
>      StruveH[-1, 2*s] + BesselY[1, 2*s]*
>      (-1 + Pi*s*StruveH[0, 2*s])))/2
> 
> however, if 'u' is used, the result is
> 
> If[u > 0, (1/2)*
>   (-MeijerG[{{1}, {1/2}}, {{1, 1},
>       {0, 1/2}}, u^2] +
>    Pi*u^2*(BesselY[0, 2*u]*StruveH[-1,
>        2*u] + BesselY[1, 2*u]*
>       StruveH[0, 2*u])),
>  Integrate[(-t)*BesselY[0, 2*t] +
>    u*BesselY[0, 2*t], {t, 0, u},
>   Assumptions -> u <= 0]]
> 
> Note that if I now use Assumptions->{u > 0} in the integration, the
> two symbolic answers become the same.  Numerical evaluation of the two
> symbolic answers also yield the same result.  Nonetheless, I find it
> alarming that the symbolic result is sensitive to variable naming.
> 
> In fact, using Trace[] I can see that the integration routine receives
> slightly different inputs for the two cases:
> 
> Integrate[Times[Plus[Times[-1, t], u], BesselY[0, Times[2, t]]],
> List[t, 0, u]] vs
> Integrate[Times[Plus[s, Times[-1, t]], BesselY[0, Times[2, t]]], List[t, 0, s]]
> 
> However, the fact that the output is sensitive to whether the input
> contains Plus[foo,bar] or Plus[bar,foo] is unexpected.
> 
> It is plausible that two different (but equivalent) input forms yield
> two different (but equivalent) output forms.  In this case, however,
> it doesn't look like the output forms are equivalent.

It is certainly possible that one or both results have problems, e.g. 
they may require provisos that integrte was not able to ascertain.

As for why one gets different forms of result, that follows from the 
fact that the flow of control is quite different. Integrate first tries 
to break up the sum, and it orders the terms differently so in one case 
it is first working with constant times Bessel, and in the other is is 
variable time Bessel that is seen first.

One of these, in evaluation, receives a proviso. I think when that 
happens, the code takes a new path, retrying the full expression at one 
go, and succeeding via Newton-Leibniz (that is, evaluating the 
antiderivative and taking appropriate limits). This, it turns out, needs 
no assumption on that parameter. For the other variant, the sum succeeds 
and there is a proviso at the end (because one summand used a 
convolution method that demanded it, perhaps in lieu of a sacrifice). 
This, by the way, is why including the assumption makes the results 
effectively the same; we no longer have a proviso issued when that 
assumption is present, hence no longer have a change of mind based on 
which summand is handled first.

I probably have some of the details not quite right, as these are 
lengthy computations to track. But this does give the basic idea of how 
and why the results differ.

The general situation is that many functions in Mathematica depend, to a 
small extent, on lexical ordering of "variables". In a function like 
Integrate there can be many such dependencies, and they can (and do, as 
you saw) conspire to give seemingly different results for mathematically 
equivalent and indeed programmatically isomorphic inputs. Whether one 
regards this as disturbing or a simple fact of computational life 
depends on outlook, I suppose.

For those with an interest in such pathology: I don't think this 
particular issue is raised in the material at the URL below, but there 
are several that are similar in the sense of being very sensitive to 
heuristics in the algorithm, details of simplification, etc.

http://library.wolfram.com/infocenter/Conferences/5832/

Daniel Lichtblau
Wolfram Research






  • Prev by Date: Re: Rule
  • Next by Date: Re: Import html
  • Previous by thread: Re: Alignment -> Full not working in GraphicsColumn
  • Next by thread: blobs functions