On Wed, Feb 12, 2014 at 2:11 AM, Pauli Virtanen <p...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion