[Numpy-discussion] Suggestions for GSoC Projects
jenny.stone125 at gmail.com
Sun Feb 16 16:34:35 EST 2014
On Wed, Feb 12, 2014 at 2:11 AM, Pauli Virtanen <pav at iki.fi> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> It's not so often someone wants to work on scipy.special, so you'd be
> welcome to improve it :)
> That's great! Thanks a lot for your guidance. .
> Spherical harmonics might be a reasonable part of a GSoC proposal.
> However, note that there exists also a *second* Legendre polynomial
> function `lpmv`, which doesn't store the values of the previous N
> functions. There's one numerical problem in the current way of
> evaluation via ~Pmn(cos(theta)), which is that this approach seems to
> lose relatively much precision at large orders for certain values of
> theta. I don't recall now exactly how imprecise it becomes at large
> orders, but it may be necessary to check.
> I checked lpmv and lpmn. As you rightly said, lpmv avoids the storage of
values small N's by using recursion. Why can't we first check if m and n are
n positive integers and pass them to lpmv itself rather than lpmn? lpmn does
give us the derivatives too, but sph_harm has no need for that, and of
all the values for <m and <n too are trimmed. What is the benefit of lpmn
over lpmv at present?
> Adding new special functions also sounds like an useful project. Here,
> it helps if they are something that you expect you will need later on :)
I am unable to think beyond ellipsoidal functions. As for their use, we as
students used them in problems of thermal equilibrium in ellipsoidal bodies,
and some scattering cases. Though I have no idea if its use in general is
quite prominent. And cylindrical harmonic function would be useful but I
it's quite straight forward to implement (correct me if I am wrong) .
> There's also the case that several of the functions in Scipy have only
> implementations for real-valued inputs, although the functions would
> be defined on the whole complex plane. A list of the situation is here:
> Lowercase d correspond to real-valued implementations, uppercase D to
> complex-valued. I'm not at the moment completely sure which would have
> the highest priority --- whether you need this or not really depends
> on the application.
> If you want additional ideas about possible things to fix in
> scipy.special, take a look at this file:
> The entries marked @knownfailure* have some undiagnosed issues in the
> implementation, which might be useful to look into. However: most of
> these have to do with corner cases in hypergeometric functions. Trying
> to address those is likely a risky GSoC topic, as the multi-argument
> hyp* functions are challenging to evaluate in floating point. (mpmath
> and Mathematica can evaluate them in most parameter regimes, but AFAIK
> both require arbitrary-precision methods for this.)
Yeah, many of the known failures seem to revolve around hyp2f1. An
inclination towards hypergeometric functions really tempts me to plunge
If it's too risky, I can work on this after the summers, as I would have
a lot of experience with the code here.
So I think there would be a large number of possible things to do
> here, and help would be appreciated.
> - --
> Pauli Virtanen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> -----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion