[Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

[Nathaniel Smith]

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.concatenate.__numpy_implementation__(...)
>>
>> and
>>
>> 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" [1] 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?

-n

[1] https://en.wikipedia.org/wiki/Standardization_of_Office_Open_XML

-- 
Nathaniel J. Smith -- https://vorpus.org