8000 Discussion: Could there be a ufunc type hierarchy? · Issue #8867 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

Discussion: Could there be a ufunc type hierarchy? #8867

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
eric-wieser opened this issue Mar 30, 2017 · 3 comments
Open

Discussion: Could there be a ufunc type hierarchy? #8867

eric-wieser opened this issue Mar 30, 2017 · 3 comments
Labels
component: numpy._core

Comments

@eric-wieser
Copy link
Member
eric-wieser commented Mar 30, 2017 •
edited
Loading

There's a bunch of fields in PyUFuncObject that don't make sense for normal ufuncs (are nulled), and most methods in ufunc_methods don't make sense for gufuncs.

What would seem like a better model for me is the following type heirarchy

  • base_ufunc
    • gufunc- actually knows about core_enabled
    • ufunc - has the reduce, accumulate, and reduce_at methods, and identity property

I'm guessing that both binary and API compatibility in C are important - so maybe this could just change from the python side?

It looks to me like it's far too late in the day to cut up PyUFuncObject into multiple pieces, but I think just letting it be viewed under different python types would be useful for hiding invalid methods and properties
@eric-wieser eric-wieser changed the title Discussion: Could there be a ufunc type heirarchy? Discussion: Could there be a ufunc type hierarchy? Mar 30, 2017
@eric-wieser eric-wieser mentioned this issue Mar 30, 2017
Closed
@njsmith
Copy link
Member
njsmith commented Mar 30, 2017 via email

@eric-wieser
Copy link
Member Author

I guess my main concern: Right now, PyUFunc_GenericFunction, which is the main code behind ufuncs, is just a massive switch between "do a ufunc thing" and "do a gufunc thing".

To me, this seems better represented with subclasses.

And anyway, shouldn't we be trying to make gufuncs and ufuncs
share more code, not less?

Yes, you're right. But right now, it's very hard to tell what they share and what they don't.

@njsmith
Copy link
Member
njsmith commented Mar 30, 2017

If you look at the code though, it's a giant copy/paste with a few things changed. I think it would be better to reduce the copy/paste instead of formalizing it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
component: numpy._core
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@eric-wieser @njsmith
0