[Numpy-discussion] Deprecate numpy.dual?

[Sebastian Berg]

On Fri, 2020-01-03 at 07:11 -0500, Warren Weckesser wrote:
> In response to some work on improving the documentation of
> `numpy.linalg` and how it compares to `scipy.linalg`, Kevin Sheppard
> suggested that the documentation of the module `numpy.dual` should
> also be improved.  When I mentioned this suggestion in the community
> meeting on December 11, it was suggested that we should probably
> deprecate `numpy.dual`.
> 
> I think some current NumPy developers (myself included at the time
> the topic came up) are unfamiliar with the history and purpose of
> this module, so I spent some time reading code and github issues and
> wrote up some notes.  These notes are available at
> 
>     
> https://github.com/WarrenWeckesser/numpy-notes/blob/master/numpy-dual.md
> 
> If you are not familiar with `numpy.dual`, you might find those notes
> useful.
> 
> Now that I know a bit more about `numpy.dual`, I'm not sure it should
> be deprecated.  It provides a hook for other libraries to selectively
> replace the use of the exposed functions in internal NumPy code, so
> if a library has a better version of, say, `linalg.eigh`, it can
> configure `numpy.dual` to use its version. Then, for example, NumPy
> multivariate normal distribution code could benefit from the use of
> that library's version of `eigh`.

That is in principle true, but I do not think we use `dual` at all
internally right now in numpy, and I doubt there is more than a hand
full uses out there.

Dual is an override mechanism for functionality on ndarrays implemented
also by numpy.

In either case, I still tend towards deprecation. It seems to have
issues and the main use case probably was to improve the situation when
NumPy was compiled without an optimized BLAS/LAPACK. That probably was
a common problem at some point, but I am not sure it is still an issue.

Overriding functionality with faster implementations is of course a
valid use-case and maybe `dual` is not a bad solution to the problem
[0]. But I think we should discuss this more generally with other
options. IMO deprecating this practically unused thing now does not
mean we cannot do something similar in the future.

- Sebastian


[0] It has its own namespace, so is opt-in for the end user. You can
only support a single backend at a time, although I am not sure that
matters too much. If overrides provide a function to override, it is
explicit to the end user as to what gets executed as well.


> The NumPy documentation of `numpy.dual` refers specifically to SciPy,
> but it could be used by any library.  Does anyone know if any other
> libraries use `register_func` to put their functions into the
> `numpy.dual` namespace?
> 
> SciPy currently registers some functions, but there is an open issue
> in which it is proposed that SciPy no longer register its functions
> with `numpy.dual`:
> 
>     https://github.com/scipy/scipy/issues/10441
> 
> This email is to start the discussion of the future of `numpy.dual`.
> Some of the options:
> 
> 1. Quietly continue the status quo.
> 2. Deprecate `numpy.dual`.
> 3. Spend time improving the documentation of this feature, and
>    perhaps even expand the functions that are supported.
> 
> What do you think?  For those who were involved in the creation of
> `numpy.dual`: is it working out like you expected?  If not, is it
> worthwhile maintaining it?
> 
> Warren
> 
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200103/d8acb1ed/attachment.sig>