Prev: Random`DistributionVector
Next: Alignment -> Full not working in GraphicsColumn
From: Daniel Lichtblau on 19 Mar 2010 03:39
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





 | 
Pages: 1
Prev: Random`DistributionVector
Next: Alignment -> Full not working in GraphicsColumn