[Numpy-discussion] Suggestions for GSoC Projects

[Jennifer stone]

On Wed, Feb 12, 2014 at 2:11 AM, Pauli Virtanen <pav at iki.fi> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> 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
course
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
feel
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
unexplained
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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
>
> iEYEARECAAYFAlL6iwAACgkQ6BQxb7O0pWBfOgCfYHAB12N4FWDmrqx8/ORTBRps
> pXYAoL3ufAiShe+0qTEGfEvrmDgr1X0p
> =kAwF
> -----END PGP SIGNATURE-----
>

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