[Numpy-discussion] Suggestions for GSoC Projects

Jennifer stone 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:

> Hash: SHA1
> Hi
> 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:
>     https://github.com/scipy/scipy/blob/master/scipy/special
>     /generate_ufuncs.py#L85
> 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:
>     https://github.com/scipy/scipy/blob/master/scipy/special/tests
>     /test_mpmath.py#L648
> 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
into this.
If it's too risky, I can work on this after the summers, as I would have
gained quite
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
> Version: GnuPG v1.4.14 (GNU/Linux)
> pXYAoL3ufAiShe+0qTEGfEvrmDgr1X0p
> =kAwF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140217/1bfcb911/attachment.html>

More information about the NumPy-Discussion mailing list