On Fri, Jul 12, 2024 at 2:35 PM Sebastian Berg <sebast...@sipsolutions.net> wrote: > > On Fri, 2024-07-12 at 09:56 -0400, Warren Weckesser wrote: > > On Fri, Jul 12, 2024 at 7:47 AM Sebastian Berg > > <sebast...@sipsolutions.net> wrote: > > > > > > > > (You won't be able to know these relations from reading the > > > signature, > > > but I doubt it's worth worrying about that.) > > > > After creating the gufunc with `PyUFunc_FromFuncAndDataAndSignature`, > > the gufunc author could set the `core_signature` field at the same > > time that `process_core_dims_func` is set. That requires freeing the > > old signature and allocating memory for the new one. For the 1-d > > convolution example, the signature would be set to `"(m),(n)->(m + n > > - > > 1)"`: > > > > ``` > > In [1]: from experiment import conv1d_full > > > > In [2]: conv1d_full.signature > > Out[2]: '(m),(n)->(m + n - 1)' > > ``` > > > I have to look at the PR, but the ufunc parses the signature only once?
Yes. The ufunc doesn't need to save the signature string once it has parsed it. As the comment about it in `ufuncobject.h` says, the `core_signature` field (type `char *`) is "for printing purposes". Updating the `core_signature` is optional. I hadn't thought about it until you mentioned it above, but it doesn't seem like a bad idea. I added this to the `experiment` module at https://github.com/WarrenWeckesser/experiments/blob/main/python/numpy/gufunc-process_core_dims_func/experiment.c, where I now have a helper function `reset_core_signature(PyUFuncObject *gufunc, char *new_signature)` to update the field. This is not part of the pull request. I'm not sure if that is something we would suggest as the recommended practice for this feature. > That solution seems very hacky, but allowing to just replace the > signature may make sense. > (Downside is, if someone else wants to parse the original signature, > but I guess it is unlikely.) > > In either case, the only other thing to hook into would be the > signature parsing itself with the full shapes available. But then you > may need to deal with `axes=`, etc. as well, so I think your solution > that only adjusts shapes seems better. > It's much simpler and should cover most or even all relevant things. Yes, for the use-cases that I can think of, all that matters are the values of the core dimensions of the input and output arrays when the gufunc is called. Warren > > - Sebastian > > > > > > > Warren > > _______________________________________________ > > NumPy-Discussion mailing list -- numpy-discussion@python.org > > To unsubscribe send an email to numpy-discussion-le...@python.org > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > > Member address: sebast...@sipsolutions.net > > > _______________________________________________ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: warren.weckes...@gmail.com _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
