MathGroup Archive 2006

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

Search the Archive

Re: Problem with LegendreQ

  • To: mathgroup at smc.vnet.net
  • Subject: [mg67636] Re: Problem with LegendreQ
  • From: "David W.Cantrell" <DWCantrell at sigmaxi.net>
  • Date: Mon, 3 Jul 2006 06:37:38 -0400 (EDT)
  • References: <e887ju$8ti$1@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

"sashap" <pavlyk at gmail.com> wrote:
> On 7/1/06, David W. Cantrell <DWCantrell at sigmaxi.org> wrote:
> > [Message also posted to: comp.soft-sys.math.mathematica]
> >
> > "sashap" <pavlyk at gmail.com> wrote:
> > > Hi Michael,
> > >
> > > There is no problem with Mathematica's LegendreQ. In fact there is a
> > > typo is A&S.
> >
> > No. In fact, there is no typo about that in A&S. (Yes, there are still
> > mistakes even in the last printing of A&S, but that's not one of them.)
>
> By the typo, I refer to the inconsistency between AS 17.3.9 (which is
> consistent with Mathematica's definition of EllipticK) and AS 8.13.3
> (where apparently a different definition of EllipticK is used). This is
> a typo, considering the book as a whole.

I wouldn't call it a typo; I think it's _worse_ than a typo. Thanks for
pointing out that inconsistency. I had not been aware of it. One would
surely think that Stegun and Milne-Thomson could, in their respective
chapters 8 and 17, have managed to use the _same_ convention!

Regards,
David

> > > The correct identity reads:
> > >
> > > LegendreQ[-1/2, 0, 3, x] = Sqrt[2/(x+1)] * EllipticK[ 2/(x+1) ]
> >
> > That seems to be valid throughout the complex plane, except on the real
> > axis for x <= -1.
>
> Correct, but my reply should be put in the context of Michael's
> question. He refers to AS 8.13.3 stated there for Re[x] > 0, so my
> reply assumed that restriction as well.
>
> >
> > The above identity is expressed using Mathematica's notational
> > convention for elliptic integrals. The corresponding identity in A&S is
> > also correct; it merely _looks_ different due to the fact that A&S use
> > a different (and also very common) notational convention for elliptic
> > integrals. [I don't know Michael's background. If he's not an
> > experienced user of elliptic integrals, it's understandable that he
> > would be confused by the differing conventions. But I would have
> > certainly thought that any Special Functions Developer would be
> > excruciatingly well aware of the differing conventions!]
> >
> > > Notice that LegendreQ[-1/2,x] is a short form of
> > >
> > > LegendreQ[-1/2, 0, 2, x], that is LegendreQ[-1/2, x] has different
> > > branch-cut structure than LegendreQ[-1/2, 0, 3, x].
> > >
> > > The typo in A&S becomes apparent if you compare
> > >
> > > In[2]:= LegendreP[-2^(-1), x]
> > >
> > > Out[2]= (2*EllipticK[(1 - x)/2])/Pi
> > >
> > > to AS which incorrectly gives
> > >   LegendreP[-1/2,x] == (2*EllipticK[ Sqrt[ (1 - x)/2 ]  ])/Pi.
> >
> > Again, what Mathematica gives and what A&S give are equivalent. They
> > are merely expressed using two different common conventions for
> > notating elliptic integrals.
>
> My remark from above applies here as well.
>
> Oleksandr Pavlyk
> Special Functions Developer
> Wolfram Research
>
> >
> > David W. Cantrell
> >
> >
> > > Oleksandr Pavlyk,
> > > Special Functions Developer
> > > Wolfram Research
> > >
> > > mmandelberg at comcast.net wrote:
> > > > I seem to be getting incorrect numerical results for the
> > > > LegendreQ[n,x] function.  For example I get:
> > > >
> > > > LegendreQ[-1/2,5]//N     =    1.00108 -1.17142 i
> > > >
> > > > so that the imaginary part is not zero.  However, using the
> > > > identity (Abramowitz and Stegun 8.3.13):
> > > >
> > > > LegendreQ[-1/2, x] = Sqrt[2/(x+1)] * EllipticK[Sqrt[2/(x+1)]]
> > > >
> > > > The answer should be:
> > > >
> > > > Sqrt[2/(5+1)]EllipticK[Sqrt[2/(5+1)]]//N
> > > >
> > > >  1.11187
> > > >
> > > >
> > > > Michael Mandelberg
> >


  • Prev by Date: Re: Limit of an expression?
  • Next by Date: Re: Re: Re: Limit of an expression?
  • Previous by thread: Re: Problem with LegendreQ
  • Next by thread: NDSolve -- limitations and a product suggestion