Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2007
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2007

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

Search the Archive

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





  • Prev by Date: Re: Re: Re: Re: [Mathematica 6] What happened to the
  • Next by Date: Re: Format->Magnification does not work on notebook
  • Previous by thread: Struve functions
  • Next by thread: Struve functions