Updating legendre and associated legendre functions in special to take array inputs

--===============8759690414167458602==
Content-Type: multipart/alternative; boundary="0000000000008abed50614b08eae"

--0000000000008abed50614b08eae
Content-Type: text/plain; charset="UTF-8"

Hi team,

https://github.com/scipy/scipy/pull/20320 by Irwin Zaid updates the
legendre functions of the first and second kind, lpn
<https://docs.scipy.org/doc/scipy/reference/generated/scipy.special.lpn.html>
and lqn
<https://docs.scipy.org/doc/scipy/reference/generated/scipy.special.lqn.html>
respectively, and the associated legendre functions of the first and second
kind, lpmn
<https://docs.scipy.org/doc/scipy/reference/generated/scipy.special.lpmn.html>
/clpmn
<https://docs.scipy.org/doc/scipy/reference/generated/scipy.special.clpmn.html#scipy.special.clpmn>
and lqmn
<https://docs.scipy.org/doc/scipy/reference/generated/scipy.special.lqmn.html>
respectively, to take array arguments for the parameter z. Currently lxn(n,
z) returns a tuple of arrays, each of shape (n+1, ), evaluating a legendre
function at the point z for degrees 0 through n. lxmn(m, n, z) returns a
tuple of arrays, each of shape (m+1, n+1) evaluating an associated legendre
function at the point z for orders from 0 to m and degrees from 0 to n.
#20320 updates these functions to allow z to be an ndarray, such that the
output shape of lxn(n, z) will be (n+1, ) + z.shape and the output shape of
lxmn(m, n, z) will be (m+1, n+1) + z.shape.

I think this is a highly valuable change, allowing efficient evaluation of
these functions over multiple points.

To accomplish this, Irwin worked directly with the NumPy C API to create
generalized universal functions (gufuncs
<https://numpy.org/doc/stable/reference/c-api/generalized-ufuncs.html>)
that allow the inner loops of these functions to be run in native code. His
approach extends a C++ metaprogramming approach he implemented to
streamline working with the NumPy C API to create ufuncs in
https://github.com/scipy/scipy/pull/20260.

Our hope is to make the use of gufuncs more widespread in special, and to
make them available in CuPy's special as well, along the lines of what was
discussed in https://github.com/scipy/scipy/issues/19404.

Feel free to share your thoughts either here or in #20320.

Cheers,
Albert

ps. The count of lines changed in #20320 looks imposing, but it's just
because kokkos/mdspan <https://github.com/kokkos/mdspan>, the reference
implementation of the C++23 addition mdspan,
<https://en.cppreference.com/w/cpp/container/mdspan> has been pasted into
the under development special function C++ library Irwin and I are working
on.

--0000000000008abed50614b08eae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi team,</div><div><br></div><div><a href=3D"https://=
github.com/scipy/scipy/pull/20320" target=3D"_blank">https://github.com/sci=
py/scipy/pull/20320</a> by Irwin Zaid updates the legendre functions of the=
 first and second kind, <a href=3D"https://docs.scipy.org/doc/scipy/referen=
ce/generated/scipy.special.lpn.html" target=3D"_blank">lpn</a> and <a href=
=3D"https://docs.scipy.org/doc/scipy/reference/generated/scipy.special.lqn.=
html" target=3D"_blank">lqn</a> respectively, and the associated legendre f=
unctions of the first and second kind, <a href=3D"https://docs.scipy.org/do=
c/scipy/reference/generated/scipy.special.lpmn.html" target=3D"_blank">lpmn=
</a>/<a href=3D"https://docs.scipy.org/doc/scipy/reference/generated/scipy.=
special.clpmn.html#scipy.special.clpmn" target=3D"_blank">clpmn</a> and <a =
href=3D"https://docs.scipy.org/doc/scipy/reference/generated/scipy.special.=
lqmn.html" target=3D"_blank">lqmn</a> respectively, to take array arguments=
 for the parameter z. Currently lxn(n, z) returns a tuple of arrays, each o=
f shape (n+1, ), evaluating a legendre function at the point z for degrees =
0 through n. lxmn(m, n, z) returns a tuple of arrays, each of shape (m+1, n=
+1) evaluating an associated legendre function at the point z for orders fr=
om 0 to m and degrees from 0 to n. #20320 updates these functions to allow =
z to be an ndarray, such that the output shape of lxn(n, z) will be (n+1, )=
 + z.shape and the output shape of lxmn(m, n, z) will be (m+1, n+1) + z.sha=
pe.</div><div><br></div><div>I think this is a highly valuable change, allo=
wing efficient evaluation of these functions over multiple points.</div><di=
v><br></div><div>To accomplish this, Irwin worked directly with the NumPy C=
 API to create generalized universal functions (<a href=3D"https://numpy.or=
g/doc/stable/reference/c-api/generalized-ufuncs.html" target=3D"_blank">guf=
uncs</a>) that allow the inner loops of these functions to be run in native=
 code. His approach extends a C++ metaprogramming approach he implemented t=
o streamline working with the NumPy C API to create ufuncs in <a href=3D"ht=
tps://github.com/scipy/scipy/pull/20260" target=3D"_blank">https://github.c=
om/scipy/scipy/pull/20260</a>.</div><div><br></div><div>Our hope is to make=
 the use of gufuncs more widespread in special, and to make them available =
in CuPy&#39;s special as well, along the lines of what was discussed in <a =
href=3D"https://github.com/scipy/scipy/issues/19404" target=3D"_blank">http=
s://github.com/scipy/scipy/issues/19404</a>.</div><br><div>Feel free to sha=
re your thoughts either here or in #20320.<br></div><div><br></div><div>Che=
ers,</div><div>Albert</div><div><br></div><div>ps. The count of lines chang=
ed in #20320 looks imposing, but it&#39;s just because <a href=3D"https://g=
ithub.com/kokkos/mdspan" target=3D"_blank">kokkos/mdspan</a>, the reference=
 implementation of the C++23 addition <a href=3D"https://en.cppreference.co=
m/w/cpp/container/mdspan" target=3D"_blank">mdspan,</a> has been pasted int=
o the under development special function C++ library Irwin and I are workin=
g on.</div></div>

--0000000000008abed50614b08eae--

--===============8759690414167458602==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
SciPy-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/scipy-dev.python.org/
Member address: [email protected]

--===============8759690414167458602==--