feature request: bindings for GSL's gsl_sf_coupling_3j() et al.

[bcrowell]

It would be helpful if SciPy could add bindings for the angular momentum coupling functions in GSL, such as gsl_sf_coupling_3j().

GSL docs: https://www.gnu.org/software/gsl/manual/html_node/Coupling-Coefficients.html

[rkern]

We cannot directly bind or adopt GSL code as the GSL is under the GPL license, which is more restrictive than our BSD-like license. If you know of a more liberally-licensed source of these functions, or are able to implement them from scratch from the Abramowitz & Stegun (or other non-code references), then we would be able to include implementations of these functions.

[bcrowell]

I see, thanks for the quick response. Seems to me that implementing this kind of thing yet again from scratch would be a last resort. There are a lot of mature and tested implementations out there. I don't know that much about your project, so I don't know what your preferences are. Pure python vs a wrapper for something fast in C or fortran? Do you care about providing any representation other than double-precision floating point? The outputs can in general be represented as square roots of rational numbers.

There is an implementation in the BSD-licensed symbolic math package SymPy, and what seems to have happened is that they found a GPL'd implementation in Sage, asked for permission to relicense it under BSD, and received permission from the authors. Then they rewrote it extensively for their purposes. However, it looks like the relicensing applies to the original code, so it seems like it would be possible to use that in SciPy. That would be a pure-python solution.

https://github.com/sagemath/sage/blob/master/src/sage/functions/wigner.py
https://groups.google.com/forum/#!topic/sage-devel/M4NZdu-7O38

There is a C++ implementation by Joey Dumont, which is LGPL. I assume LGPL is compatible with your license? Someone has already made a python wrapper.

https://github.com/joeydumont/wignerSymbols/blob/master/src/wignerSymbols-cpp.cpp
https://github.com/jeffzhen/wignerpy

Does either of these look like something you would want to use?

[WarrenWeckesser]

Seems to me that implementing this kind of thing yet again from scratch would be a last resort.

FYI: The PyGSL package (https://pypi.org/project/pygsl/) provides Python wrappers for the GNU Scientific Library. If you can use GPL software, that might be an option for you.

[rkern]

The LGPL is still more restrictive than our license. The issue is less about "compatibility" per se so much as what the maximum amount of restrictions that we want to place on code that we are releasing, and we have chosen a BSD-style license, which has fewer restrictions than even LGPL.

The Sage-derived code looks like it's using the capabilities of Sage as a symbolic computer algebra system, and SymPy likely did the same. I haven't looked close enough to guess whether one could just use Python's unbounded integers and fractions to do the same. I don't know what you'd do to port that to C/C++ without pulling in more dependencies like GMP.

Personally, I don't feel the need to be a completionist here. It looks there are already 4 different ways to make these calculations from Python, and that's the important thing. I don't feel an urgency to add a 5th. Of course, I also don't use these functions.

[bcrowell]

@WarrenWeckesser : Thanks for the suggestion about PyGSL. However, it looks to me like they haven't actually implemented any of the special functions from GSL. (The API docs for those functions just look like stubs, and I don't see the functions installed into /usr/local/lib/python3.6/dist-packages/pygsl .)

@rkern : OK, thanks for considering my request. I'll close it.

[rkern]

That said, if you try out those implementations and find them unsuitable for whatever reason and can find a way to make a BSD-licensed implementation that was suitable to your needs, we would be happy to host it in scipy.

[chrisjbillington]

FWIW py3nj is Apache licensed, and wraps a well established fortran library that is public domain.