ENH: Generalized ufunc signature expansion for frozen and flexible dimensions #11175

mhvk · 2018-05-28T00:56:37Z

EDIT: now the replacement of #11132

An alternative to #11132, much more following its logic, but (I think) clearer. Mostly for @mattip to look at. I like the use of flags, although it may seem a bit overkill if we have just one. But I do hope to have a broadcast option (tentatively n|1). For now, I also kept the frozen dimensions, as those are quite easy.

charris · 2018-05-29T00:55:16Z

Notifying @shoyer and @mrocklin for these discussions, as they are looking to expand on the array_ufunc idea and this is in the same general area.

mhvk · 2018-05-29T01:10:09Z

To get a full sense of what the ideas are, have a look at #11179 (just to be sure, all based on @mattip's work). The test cases may right now provide the best documentation...

charris · 2018-05-29T01:18:42Z

Should have @njsmith here also.

mattip · 2018-05-29T17:34:54Z

What is the way forward? Does this replace #11132 or build upon it?

mattip · 2018-05-29T18:04:12Z

After reading the comment in #11132 it seems you want to first implement fixed core dimensions and then add flexible ones?

Edit: it seems to make sense to add them both together since the changes are not really orthogonal. The fixed dimension needs tests for the cross1d function added to _umath_tests, the ones from the comment #5015 (comment)) in the original PR are a start

mhvk · 2018-05-29T19:00:45Z

Ah, partly an answer to my question in #11132 - yes, starting with ? and fixed sizes is fine too - #11132 was just to show how easy it was to add broadcasting.

mattip · 2018-05-29T19:55:20Z

@mhvk could you rebase this off master, or do you want me to do it? Also notice there are changes to umath/scalar.c.src which add matrix_multiply. They belong in the final matmul pr #11133 and should be removed from this PR

mhvk · 2018-05-29T20:56:05Z

I'm in the process of rebasing - I'll remove the matmul specific commit.

mhvk · 2018-05-30T01:01:03Z

OK, I rebased this and think it is now ready for review. In rebasing, I used @jaimefrio's original commit for frozen dimensions, so that it is still attributed properly. I similarly used @mattip's commits, but squashed to 2. Note that I rebased on top of #11173 and #11176, to avoid having another difficult rebase after those have been merged.

One note: the doc changes are just @mattip's - I've made more elaborate changes in the broadcasting follow-up, but hoped not to have to split the relevant parts out.

mhvk · 2018-05-30T15:49:19Z

Hah, the failing test from 32 bit exposed an interesting bug: previously, @mattip had implemented the flexible dimensions such that the elementary function had to check whether a dimension was zero, and then swap strides. But with matrix-multiply, this changed the behaviour of one of the test cases, in which it is called with matrix_multiply(np.ones((0, 10)), np.ones((10, 0))), i.e., with real zeros for the dimensions.

So, this was clearly fragile. But fortunately also not needed: by just passing on the strides in the correct order, this is solved and, as one would like, the elementary function doesn't have to know about whether flexible dimensions are being used. Much nicer!

A nice side benefit is that matmul now becomes even more trivial to implement, as its code does not have to change at all: it just needs wrapping as a gufunc.

mattip · 2018-05-30T18:49:55Z

numpy/core/src/umath/ufunc_object.c

@@ -2199,10 +2362,10 @@ PyUFunc_GeneralizedFunction(PyUFuncObject *ufunc,

    /* Use remapped axes for generalized ufunc */
    int broadcast_ndim, iter_ndim;
-    int core_num_dims_array[NPY_MAXARGS];
-    int *core_num_dims;
+    int core_num_dims[NPY_MAXARGS];


As per discussion in PR #11176, this should be renamed

Need to think a bit about the logic of the names, since we're copying and adjusting two arrays: core_num_dims and core_dim_sizes. In both cases, the copies represent the actual number of dimensions that the operands have and the sizes that they imply. So, long versions could be
actual_core_num_dims and actual_core_dim_sizes - or remove _core.

Alternatively, I have been wondering whether it would make sense to have a mini-struct actual that had whatever parts of the ufunc would need changing (could be expanded to include core_dim_ixs for "calculated" output indices, e.g.). So that would mean actual->core_num_dims, actual->core_dim_sizes. But this could be done in a separate PR as well.

p.s. I'm also not so happy that as is, core_num_dims gets copied even if in standard usage it never gets adjusted. But I guess it is only a few numbers, so very little overhead...

mattip · 2018-05-30T18:52:14Z

numpy/core/src/umath/ufunc_object.c

@@ -2538,7 +2715,7 @@ PyUFunc_GeneralizedFunction(PyUFuncObject *ufunc,
     */
    core_dim_ixs_size = 0;
    for (i = 0; i < nop; ++i) {
-        core_dim_ixs_size += core_num_dims[i];
+        core_dim_ixs_size += ufunc->core_num_dims[i];


Should this be precalclulated and stored as part of the ufunc struct?

I wondered about that, but it seems a bit excessive. Another thing one might do is to store it at the end of core_offsets, so that that really equal cumsum(core_num_dims)

p.s. If we want to go this route, I do think this should be a different PR -- as long as we don't have a release, we are free to change the struct even without a version number change. And my overall sense is that it is rarely really needed: even now, one can just do

core_dim_ixs_size = ufunc->core_offsets[ufunc->nargs - 1] + ufunc->core_num_dims[ufunc->nargs - 1]

mattip · 2018-05-30T18:59:14Z

tests for fixed dim signature still missing? The cross1d function is never used in tests AFAICT.

mhvk · 2018-05-30T19:41:41Z

Rebased to get rid of conflicts, and now including tests of cross1d.

mattip · 2018-05-30T20:51:51Z

@charris, @njsmith, Do you have a sense of how controversial allowing flexible/fixed gufunc core signatures is? Can we go ahead and merge this new feature soonish or does it need another round on the mailing list? Note this is the enabler for changing matmul PR #11133, which needs more work

If it is good to go, it should get an entry in Improvements in doc/release/1.15.0-notes.rst

mattip · 2018-10-10T08:46:26Z

reformatted, reworked flag, removed version from struct and docs.

mhvk · 2018-10-10T13:19:16Z

Piping in from what has become the sidelines: I actually chose the flag with some care, in that if a flag is set, it implies the code needs to do extra work. And a constant size is the obviously simpler case ;-) If the double negative is a problem, it could be UFUNC_CORE_DIM_SIZE_FREE.

Though I will add that the logic become truly obvious only when I added the broadcasting, when I also had UFUNC_CORE_DIM_CAN_BROADCAST.

mattip · 2018-10-11T05:49:54Z

I have no particular preference. Note the flag is never read in the code itself, only in tests. Perhaps removing it is another way to resolve the discussion, until the broadcast proposal arises again.

Edit: the check can be rewritten to use ufunc->core_dim_sizes[ix] >= 0 instead of the flag

mhvk · 2018-10-11T12:38:01Z

@mattip - I think I'd prefer to keep the flag since there is the other one for matmul as well. I also prefer to keep the sense that flag set means work - how about UFUNC_CORE_DIM_FLEXIBLE_SIZE or ...SIZE_FREE - it suggests that the underlying code can handle a non-fixed size.

eric-wieser · 2018-10-11T13:17:40Z

I also prefer to keep the sense that flag set means work

That's perhaps a reasonable interpretation.

I don't think it matters too much - the only reason I mention it is this is becoming our public API, so once we choose we're stuck with it.

eric-wieser · 2018-10-11T13:18:33Z

How about UFUNC_CORE_DIM_SIZE_INFERRED, which does not form a double negative, and indicates work in the way @mhvk mentions?

mattip · 2018-10-11T15:33:18Z

Updated to UFUNC_CORE_DIM_SIZE_INFERRED, and enhanced documentation to cross-reference frozen, learning about arbitrary anchors in rst in the process

eric-wieser · 2018-10-11T15:40:24Z

doc/source/reference/c-api.types-and-structures.rst

+   .. c:member:: npy_intp *PyUFuncObject.core_dim_sizes
+
+       For each distinct core dimension, the possible
+       :ref:`frozen <frozen>` size (``-1`` if not frozen)


Why are we using both -1 and UFUNC_CORE_DIM_SIZE_INFERRED to indicate this?

I think that's a leftover from the initial work by Jaime. I think it is fine to remove the guarantee that it is -1 if not frozen, as indeed the flag already indicates that (and perhaps we want to use negative numbers to indicate something else in the future).

eric-wieser · 2018-10-11T15:40:47Z

numpy/core/code_generators/cversions.txt

@@ -43,3 +43,5 @@
 # PyArray_SetWritebackIfCopyBase and deprecated PyArray_SetUpdateIfCopyBase.
 0x0000000c = a1bc756c5782853ec2e3616cf66869d8

+# Version 13 (Numpy 1.16) Size of PyUFuncObject changed


Again, this should mention the new struct member names

eric-wieser · 2018-10-12T05:39:02Z

doc/source/reference/c-api.types-and-structures.rst

+
+   - Never declare a non-pointer instance of the struct
+   - Never perform pointer arithmatic
+   - Never use ``sizof(PyUFuncObject)``


eric-wieser · 2018-10-12T05:39:14Z

doc/source/reference/c-api.types-and-structures.rst

+   of NumPy. To ensure compatibility:
+
+   - Never declare a non-pointer instance of the struct
+   - Never perform pointer arithmatic


typo: arithmetic

mattip · 2018-10-13T21:15:45Z

Fixed documentation review issues.

mattip · 2018-10-15T07:20:36Z

any more comments or should I squash this down?

mhvk

Only trivia.

mhvk · 2018-10-15T14:31:25Z

doc/source/reference/c-api.types-and-structures.rst

@@ -698,7 +715,7 @@ PyUFunc_Type
          PyUFuncGenericFunction *functions;
          void **data;
          int ntypes;
-          int reserved1;
+          int version;


I thought we were leaving this as reserved1 (at least that is what is described below).

mhvk · 2018-10-15T14:38:20Z

numpy/core/src/umath/ufunc_object.c

+ * Convert a string into a number
+ */
+static npy_longlong
+_get_size(const char* str)


Seems like the signature is still npy_int rather than npy_intp?

mhvk · 2018-10-15T14:45:55Z

numpy/core/src/umath/ufunc_object.c

@@ -2429,72 +2609,41 @@ PyUFunc_GeneralizedFunction(PyUFuncObject *ufunc,
        }
    }
    /*
-     * If keepdims is set and true, signal all dimensions will be the same.
+     * If keepdims is set and true, which means all input dimensions are


Either "which" -> "this", or better, replace the period with a comma (and lower-case "signal")

mattip · 2018-10-16T03:15:34Z

fixed comments from @mhvk

mattip · 2018-10-16T19:10:38Z

@mhvk, @eric-wieser anything I can do to move this forward?

mhvk · 2018-10-17T00:10:05Z

@mattip - you fixed my trivial comments, so I'm happy; thanks for carrying this on, after me hijacking it.

mattip · 2018-10-19T08:33:02Z

Thanks @mhvk, @eric-wieser for the patience. I merged this even though by now I am probably more considered a contributor than a reviewer, after consulting with core developers in the weekly status meeting.

mhvk · 2018-10-19T15:06:28Z

@mattip - thank you for first starting, then commenting, and finally shepparding this on! And thanks, @eric-wieser, for the as always very useful comments/critique!

I do hope to get back to working on speeding up the ufuncs... Though perhaps playing with __array_function__ first.

mhvk added 15 - Discussion component: numpy._core labels May 28, 2018

This was referenced May 28, 2018

WIP: Alternative ufunc signature expansion for flexible dimensions #11165

Closed

WIP: ENH: Expand gufunc signature to allow flexible dimension specs #11132

Closed

ENH: Further expansion of gufunc signature to allow broadcasting #11179

Closed

mhvk force-pushed the gufunc-signature-modification2 branch from ceffc80 to 517fd34 Compare May 30, 2018 00:20

mhvk changed the title ~~WIP: Another alternative ufunc signature expansion for flexible dimensions~~ ENH: Generalized ufunc signature expansion for flexible dimensions May 30, 2018

mhvk force-pushed the gufunc-signature-modification2 branch from 517fd34 to 4826b24 Compare May 30, 2018 00:56

mhvk added the 01 - Enhancement label May 30, 2018

mhvk changed the title ~~ENH: Generalized ufunc signature expansion for flexible dimensions~~ ENH: Generalized ufunc signature expansion for frozen and flexible dimensions May 30, 2018

mhvk force-pushed the gufunc-signature-modification2 branch 2 times, most recently from b71ef62 to d4c6396 Compare May 30, 2018 15:42

mhvk mentioned this pull request May 30, 2018

MAINT: avoid setting non-existing gufunc strides for keepdims=True. #11176

Merged

mattip reviewed May 30, 2018

View reviewed changes

mhvk force-pushed the gufunc-signature-modification2 branch from d4c6396 to a4d86ae Compare May 30, 2018 19:41

mhvk mentioned this pull request May 30, 2018

Wrap erfa functions with ufuncs and gufuncs astropy/astropy#7502

Merged

MAINT: formatting, remove version, rework flags

7ef2b3a

mattip force-pushed the gufunc-signature-modification2 branch from d60316d to 7ef2b3a Compare October 11, 2018 14:19

eric-wieser reviewed Oct 11, 2018

View reviewed changes

eric-wieser reviewed Oct 12, 2018

View reviewed changes

DOC: tweak docs from review

1205e19

mattip force-pushed the gufunc-signature-modification2 branch from 6ac20e2 to 1205e19 Compare October 12, 2018 07:17

mhvk commented Oct 15, 2018

View reviewed changes

MAINT: changes from review

c8e15ba

mattip mentioned this pull request Oct 16, 2018

Tracking issue for implementation of NEP-18 (__array_function__) #12028

Closed

33 tasks

mattip mentioned this pull request Oct 16, 2018

DEP: deprecate np.set_numeric_ops and friends #11916

Merged

mattip merged commit a2fb23a into numpy:master Oct 19, 2018

mhvk deleted the gufunc-signature-modification2 branch December 21, 2018 02:02

mhvk restored the gufunc-signature-modification2 branch December 21, 2018 02:06

mattip mentioned this pull request Mar 3, 2021

ENH,API: Store exported buffer info on the array #16938

Merged

Uh oh!

ENH: Generalized ufunc signature expansion for frozen and flexible dimensions #11175

ENH: Generalized ufunc signature expansion for frozen and flexible dimensions #11175

Uh oh!

Conversation

mhvk commented May 28, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

charris commented May 29, 2018

Uh oh!

mhvk commented May 29, 2018

Uh oh!

charris commented May 29, 2018

Uh oh!

mattip commented May 29, 2018

Uh oh!

mattip commented May 29, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mhvk commented May 29, 2018

Uh oh!

mattip commented May 29, 2018

Uh oh!

mhvk commented May 29, 2018

Uh oh!

mhvk commented May 30, 2018

Uh oh!

mhvk commented May 30, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mattip commented May 30, 2018

Uh oh!

mhvk commented May 30, 2018

Uh oh!

mattip commented May 30, 2018

Uh oh!

mattip commented Oct 10, 2018

Uh oh!

mhvk commented Oct 10, 2018

Uh oh!

mattip commented Oct 11, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mhvk commented Oct 11, 2018

Uh oh!

eric-wieser commented Oct 11, 2018

Uh oh!

eric-wieser commented Oct 11, 2018

Uh oh!

mattip commented Oct 11, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mhvk commented May 28, 2018 •

edited

Loading

mattip commented May 29, 2018 •

edited

Loading

mattip commented Oct 11, 2018 •

edited

Loading