On Thu, Mar 8, 2018 at 1:52 AM, Gregor Thalhammer <gregor.thalham...@gmail.com> wrote: > > Hi, > > long time ago I wrote a wrapper to to use optimised and parallelized math > functions from Intels vector math library > geggo/uvml: Provide vectorized math function (MKL) for numpy > > I found it useful to inject (some of) the fast methods into numpy via > np.set_num_ops(), to gain more performance without changing my programs. > > While this original project is outdated, I can imagine that a centralised > way to swap the implementation of math functions is useful. Therefor I > suggest to keep np.set_num_ops(), but admittedly I do not understand all the > technical implications of the proposed change.
The main part of the proposal is to merge the two libraries; the question of whether to deprecate set_numeric_ops is a bit separate. There's no technical obstacle to keeping it, except the usual issue of having more cruft to maintain :-). It's usually true that any monkeypatching interface will be useful to someone under some circumstances, but we usually don't consider this a good enough reason on its own to add and maintain these kinds of interfaces. And an unfortunate side-effect of these kinds of hacky interfaces is that they can end up removing the pressure to solve problems properly. In this case, better solutions would include: - Adding support for accelerated vector math libraries to NumPy directly (e.g. MKL, yeppp) - Overriding the inner loops inside ufuncs like numpy.add that np.ndarray.__add__ ultimately calls. This would speed up all addition (whether or not it uses Python + syntax), would be a more general solution (e.g. you could monkeypatch np.exp to use MKL's fast vectorized exp), would let you skip reimplementing all the tricky shared bits of the ufunc logic, etc. Conceptually it's not even very hacky, because we allow you add new loops to existing ufuncs; making it possible to replace existing loops wouldn't be a big stretch. (In fact it's possible that we already allow this; I haven't checked.) So I still lean towards deprecating set_numeric_ops. It's not the most crucial part of the proposal though; if it turns out to be too controversial then I'll take it out. -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
