[Numpy-discussion] Deprecate numpy.dual?
sebastian at sipsolutions.net
Fri Jan 3 11:29:47 EST 2020
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
> If you are not familiar with `numpy.dual`, you might find those notes
> 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
. 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.
 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`:
> 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?
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part
More information about the NumPy-Discussion