Re: Struve functions
- To: mathgroup at smc.vnet.net
- Subject: [mg75667] Re: [mg75626] Struve functions
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Tue, 8 May 2007 05:52:05 -0400 (EDT)
- References: <200705070929.FAA28003@smc.vnet.net>
dimitris wrote:
> Hello.
>
> $VersionNumber
> 5.2
>
> Consider the indefinite integral of the functions StruveH[n, x] and
> StruveL[n, x]
>
> strs = HoldForm[Integrate[{StruveH[n, x], StruveL[n, x]}, x]]
>
> ReleaseHold@strs
> {Integrate[StruveH[n, x], x], Integrate[StruveL[n, x], x]}
>
> It seems that Mathematica can't get the antiderivative of these
> functions.
>
> However,
>
> strs /. Integrate[f_, o_] :> Integrate[f, {o, 0, t}, Assumptions -> n
>
>>-2]//
>
> ReleaseHold//FunctionExpand
> {(t^(2 + n)*HypergeometricPFQ[{1, 1 + n/2}, {3/2, 2 + n/2, 3/2 + n}, -
> (t^2/4)])/(2^n*((2 + n)*Sqrt[Pi]*Gamma[3/2 + n])), (t^(2 +
> n)*HypergeometricPFQ[{1, 1 + n/2}, {3/2, 2 + n/2, 3/2 + n}, t^2/4])/
> (2^n*((2 + n)*Sqrt[Pi]*Gamma[3/2 + n]))}
>
> which are indeed antiderivatives of the functions
>
> FunctionExpand[D[ints, t]]
> {StruveH[n, t], StruveL[n, t]}
>
> Am I the only one that see an incosistency here or not?
> How is it possible, since Mathematica failes to get the indefinite
> integrals,
> to evaluate the definite ones (of course I am aware of the table look-
> up possibility
> and the Marichev-Adamchik Mellin transform methods but I think here is
> not the case).
>
> Any insight/explanations?
>
> Dimitris
>
In version 5.2 Mathematica computes the definite integral via the Mellin
transform approach, using a product of MeijerG representations, one for
the StruveH (I didn't try the second example; presumably a similar
story) and one to represent the UnitStep "cutoff".
In version 6 Mathematica can handle the indefinite integral and derives
substantially the same "definite" integral using Newton-Leibniz on the
indefinite integral.
Let me address your question regarding the inability to do the
indefinite integral in 5.2, in tandem with the fact that it can
integrate from 0 to (seemingly arbitrary) upper bound t. There are a few
reasons I can think of for not using this latter to represent the former.
One is that I suspect there may be an implicit assumption, not placed in
explicit proviso, to the effect that t is (real valued and) greater than
0. Hence this method could make silent simplifying assumptions that
could make the result not generally valid as an antiderivative.
A second reason is that, were Mathematica to use the Mellin transform
approach to do indefinite integration, then in effect the definite
integration code could undermine its own heuristics. Already definite
integration can call on indefinite integration, for the Newton-Leibniz
approach. There are situations in which it is deemed preferable to try
this BEFORE attempting the Mellin convolution. If indefinite integration
simply goes and does the Mellin stuff anyway then we gain nothing from
such heuristics.
Also note that this method requires that we have but one factor in need
of a MeijerG representation; we can only handle two such factors in the
Slater convolution and the second will be taken by the cutoff function.
Possibly some fancy switching/flagging could be used to say when to do
such things i.e. Don't do it if the "outer" caller is definite
integration. That said, some time ago we decided this tactic for
indefinite integration was just not worth the bother, given the
possibilities of wrong results, likelihood that it will not work but be
slow to fail, possibilities for recursion within the (complicated)
Integrate code, and possibility of subverting the definite integration
heuristics.
I think that over time the table lookup mechanism for indefinite
integration will simply grow to handle more such examples. That strikes
me as being a reasonable way to go, although we may need to adjust
Newton-Leibniz heuristics in preprocessing integrands, in order to catch
definite integration cases we'd prefer not be done in this way.
Daniel Lichtblau
Wolfram Resewarch
- References:
- Struve functions
- From: dimitris <dimmechan@yahoo.com>
- Struve functions