[Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods
Stefan van der Walt
stefanv at berkeley.edu
Tue Apr 16 01:57:10 EDT 2019
I thought this was simply a slot to store the NumPy version of the
dispatched method, so that you could see easily call through to it and
Stephan, was there a deeper intent here that I missed?
On April 15, 2019 20:32:35 Nathaniel Smith <njs at pobox.com> wrote:
> On Mon, Apr 15, 2019 at 4:39 PM Stephan Hoyer <shoyer at gmail.com> wrote:
>> On Mon, Apr 15, 2019 at 1:21 PM Nathaniel Smith <njs at pobox.com> wrote:
>>> What's the difference between
>>> np.ndarray.__array_function__(np.concatenate, ...)
>> I can answer this technically, though this doesn't seem to be quite what
>> you're looking for:
>> - The former always succeed at dispatch, because it coerces all arguments
>> to NumPy arrays.
>> - The second will either return NotImplemented (if a non-NumPy arrays
>> implements __array_function__), or give the same result as former.
>>> More generally, I guess I'm not quite clear on how to think about what the
>>> "no dispatch" version does, because obviously it doesn't make sense to have
>>> *no* dispatch. Instead it's something like "the legacy hard-coded dispatch"?
>> __numpy_implementation__ means you skip __array_function__ dispath and call
>> the original NumPy function. In practice, this means you get legacy
>> hard-coded dispatch behavior in most cases, e.g., the result will always be
>> in the form of NumPy array(s).
>> It doesn't mean that the implementation always coerces all arguments to
>> NumPy arrays. For example, np.result_type() will pull out of .dtype
>> attributes off of its arguments, even without necessarily coercing its
>> arguments to NumPy arrays. This strange version of "the implementation for
>> NumPy arrays" turns out to be something that several libraries that want to
>> implement __array_function__ want to be able to continue to use on their
>> own array objects (namely, JAX and CuPy).
> Microsoft's "open standard"  document format, OOXML, famously
> contains tags like "autoSpaceLikeWord95" and
> "useWord97LineBreakRules". If you want to correctly interpret a Word
> document, you have to know what these mean. (Unfortunately, the
> standard doesn't say.)
> Mostly I would like the definition for numpy 1.17's semantics to be
> internally coherent and self-contained. If the documentation for
> __numpy_implementation__ is just "it does whatever numpy 1.14 did",
> then that seems not so great. Is there any way to define
> __numpy_implementation__'s semantics without incorporating previous
> versions of numpy by reference?
>  https://en.wikipedia.org/wiki/Standardization_of_Office_Open_XML
> Nathaniel J. Smith -- https://vorpus.org
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
More information about the NumPy-Discussion