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>