Skip to content
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.

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

ENH: Add ndmax param for numpy.array #16667

Closed
wants to merge 1 commit into from
Closed

Conversation

pdnm
Copy link

@pdnm pdnm commented Jun 23, 2020

This PR implements the proposal in #5933.

The parameter makes it possible to prevent array from digging deeper into the input, even if the lengths at the the next level are all equal.

Example:

np.array([[1, 2], [3, 4]], ndmax=1)
# array([list([1, 2]), list([3, 4])], dtype=object)

@pdnm pdnm changed the title Add ndmax param for numpy.array ENH: Add ndmax param for numpy.array Jun 23, 2020
numpy/__init__.pxd Outdated Show resolved Hide resolved
@pdnm pdnm force-pushed the array-ndmax branch 3 times, most recently from 369cd27 to c4e1f02 Compare June 23, 2020 09:32
Copy link
Member

@eric-wieser eric-wieser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the patch. I'm not yet sure whether a ndmax argument to array is the right solution, but this patch does a nice job of showing it's a straighforward one.

At some point I'll read through the original issue and come back to this.

numpy/core/src/multiarray/multiarraymodule.c Outdated Show resolved Hide resolved
numpy/core/src/multiarray/ctors.c Outdated Show resolved Hide resolved
Comment on lines +1925 to +1930
PyArray_FromAny_MaxDim(PyObject *op, PyArray_Descr *newtype, int maxdims,
int min_depth, int max_depth, int flags, PyObject *context)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the difference between maxdims and max_depth?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

max_depth is like a guard, if the discovered depth is more than that, the creation fails

The ndmax param specifies the maximum depth at which the multiarray
is created from the source object.
@seberg
Copy link
Member

seberg commented Jun 23, 2020

Thanks for the PR. Sorry for being late to the party, but I realize there is not actually much overlap with my PR, so its fine.

We have to figure out what the exact API is that we want, e.g. I could imagine just fixing ndim=3 instead of ndmax (but then you have to decide whether you allow broadcasting the input to the output).

One thing that probably currently fails is if the input is already an array(-like), i.e. we should probably pass in max_depth and maxdims from python.

@seberg
Copy link
Member

seberg commented Jun 23, 2020

One API consideration. If we add this argument (whatever it is) we should deprecate ragged arrays for objects as well probably (although that can be a followup of course). That may be argument for a "maximum" as opposed to a fixed number of dims though.

@pdnm
Copy link
Author

pdnm commented Jun 24, 2020

Thanks for the PR. Sorry for being late to the party, but I realize there is not actually much overlap with my PR, so its fine.

We have to figure out what the exact API is that we want, e.g. I could imagine just fixing ndim=3 instead of ndmax (but then you have to decide whether you allow broadcasting the input to the output).

One thing that probably currently fails is if the input is already an array(-like), i.e. we should probably pass in max_depth and maxdims from python.

@seberg Indeed it currently fails if the input is an array-like.
I imagine ndim=3 could be achieved by the users with np.array(obj, ndmin=3, ndmax=3)

What "ragged arrays for objects" do you mean?

@mattip
Copy link
Member

mattip commented Aug 2, 2020

What "ragged arrays for objects" do you mean?

See NEP 34

Base automatically changed from master to main March 4, 2021 02:04
@charris charris added the triage review Issue/PR to be discussed at the next triage meeting label Feb 20, 2023
@mattip
Copy link
Member

mattip commented Feb 22, 2023

Very outdated, and mostly covered by NEP 34. We may want to continue this as an idea for consideration at some point, but would need to expose the discovery function.

@mattip mattip closed this Feb 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
01 - Enhancement component: numpy._core triage review Issue/PR to be discussed at the next triage meeting
Projects
Development

Successfully merging this pull request may close these issues.

None yet

5 participants