Originally, these functions were placed in umath_tests module for no particular reason. They are not test functions by any means

They were put there for a very particular reason - they were a simple way to test the internals of ufuncs, and that third party modules could define their own. They were definitely intended as functions to be used internally in numpy's own tests.

Having said that, you're right that an inner1d gufunc may be a useful addition to the public API. It would be helpful if you could list all the functions that you would like to see re-added publicly.

The generalized ufuncs were external contributions to NumPy. See:

• Add tests [patch by Wenjie Fu and Hans-Andreas Engel].
• Give credit for the generalised ufunc infrastructure.
• Framework for generalised ufuncs [patch by Wenjie Fu and Hans-Andreas Engel].

The gufuncs were native in Perl Data Language and we wanted to add them to NumPy. It was a difficult process, with NumPy developers being reluctant about it. As a compromise, obviously non-test function ended up in a test module.

For the list of functions, I think all but matrix_multiply are good: inner1d, innerwt, euclidean_pdist, cross1d, and even cumsum (as a gufunc).

Thanks for digging up the history!

It was a difficult process, with NumPy developers being reluctant about it.

It sounds like this was before my time, and presumably before numpy moved to GitHub. Are those conversations lost to time?

I was not a first party to those conversations. But there's some memory left, #1485 for example. And then there are threads in the mail archives. The long one is https://www.mail-archive.com/[email protected]/msg11837.html

IIRC, Travis did the merge of the infrastructure, looks like @stefanv wrote the testing implementations (2008). IIRC, the actual implementations for linalg, came in later from ContinuumIO (Anaconda) (2012-13), because some of their customers wanted them. I don't recall much list discussion when they first appeared.

Some of these could probably go into np.linalg (e.g. as Eric said, inner1d, since it cannot be reached through matmul, OTOH, it should probably use a similar technique to go through BLAS, which the current version does not). The other option is to use this as an excuse to make an additional (g)ufuncs package in the numpy repo to house a few of these, which may also make it easier to overlook potential holes (i.e. I do not know whether those ufuncs are defined for all dtypes, such as objects).

euclidian_pdist sounds like something that scipy already has for example.