8000 ENH: Add np.asanycontiguousarray by pitrou · Pull Request #7217 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

ENH: Add np.asanycontiguousarray #7217

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

Closed
wants to merge 1 commit into from

Conversation

pitrou
Copy link
Member
@pitrou pitrou commented Feb 9, 2016

Numpy has np.ascontiguousarray() and np.asfortranarray(), but doesn't have
a function to return an array of either contiguity depending on the input,
making a copy only when necessary.

Numpy has np.ascontiguousarray() and np.asfortranarray(), but doesn't have
a function to return an array of either contiguity depending on the input,
making a copy only when necessary.
@jakirkham
Copy link
Contributor

Probably should post it to the NumPy mailing list if you haven't already. If you have, maybe a link to the mailing list entry would be nice and vice versa.

if is_f_contiguous:
return array(a, dtype, copy=False, order='F', ndmin=1)
else:
return array(a, dtype, copy=False, order='C', ndmin=1)
Copy link
Member

Choose a reason for hiding this comment

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

Not sure, I like the idea too much, but that is not a deal breaker (also the any has a bit of a name clash with asanyarray). But I think you can simplify this to a single line function:

return array(a, dtype, copy=False, order="A", ndmin=1)

(not that I like the ndmin=1 either, what is so bad about 0-D arrays? But I guess the ascontiguousarray functions do that too). The whole f_contiguous stuff should be handled by "A" is my guess.

@charris charris added 01 - Enhancement component: numpy._core 56 - Needs Release Note. Needs an entry in doc/release/upcoming_changes labels Feb 13, 2016
@charris
Copy link
Member
charris commented Feb 14, 2016

Needs release note.

@njsmith
Copy link
Member
njsmith commented Feb 14, 2016

If @seberg is right that this is just copy=False, order="A", then I'm -0.5. No need to clutter the top level namespace with unique aliases for every combination of arguments that can passed to array. (This also avoids the sticky question of whether people actually want ndmin=1.)

@charris
Copy link
Member
charris commented Feb 14, 2016

I'm also -0.5 for this. We need to limit the growth of small functions at some point.

@seberg
Copy link
Member
seberg commented Feb 14, 2016

Unfortunatly, I am not right. "A" typically works like that, so I
assumed, but it seems for the no-copy case, it is happy to allow non
-contiguous arrays here.

@njsmith
Copy link
Member
njsmith commented Feb 14, 2016

Can we fix A?

@seberg
Copy link
Member
seberg commented Feb 15, 2016

If it is not really used much, I guess it is an option. It is
documented as not caring about contiguity at all for non-copy mode. But
there seems little to no reason in giving "A" when None/not giving
anything will do the same thing.

@pitrou
Copy link
Member Author
pitrou commented Feb 15, 2016

Well, "A" typically means "any layout", so I'm not sure why changing it to "any contiguous layout" in a single API would make things easier for the user.

@pitrou
Copy link
Member Author
pitrou commented Feb 15, 2016

(I certainly wouldn't guess that calling np.array with order "A" would ensure a contiguous array is returned, myself :-))

@njsmith
Copy link
Member
njsmith commented Feb 15, 2016

Another option would be to add another order value, like order="C-or-F" or order="either".

@seberg
Copy link
Member
seberg commented Feb 15, 2016

None of the options sound very convincing to me on first sight :(. "A" stands for any, that is true, but it seems (almost?) only used in the "fortran if not C (and actually fortran)" sense, though sometimes in terms of iteration order and not memory layout (we have "K" as a weaker "A"). "ForC" or variations of this, may make some sense since we use it in arr.flags.forc. It might also make sense for that wonky "require" function, which I could not remember though I looked it up 2 minutes ago ;).

@charris
Copy link
Member
charris commented Mar 15, 2016

This is looking like a reasonable addition. Does anyone object? @pitrou Needs mention in 1.12.0 release notes.

@njsmith
Copy link
Member
njsmith commented Mar 15, 2016

I'm still -0 I guess since it isn't clear to me how this could have broad utility for multiple users (what is the use case, BTW?), and because it isn't clear that adding a new function is better than adding a new option to np.array (which would be more orthogonal and reduce doc/namespace clutter). But only -0 :-)

@pitrou
Copy link
Member Author
pitrou commented Mar 17, 2016

The use case we have in mind is writing wrappers for third-party libraries such as BLAS, which often accept either C- or F-ordered arrays, but not non-contiguous arrays.

@homu
Copy link
Contributor
homu commented May 6, 2016

☔ The latest upstream changes (presumably #7539) made this pull request unmergeable. Please resolve the merge conflicts.

@efiring
Copy link
Contributor
efiring commented May 22, 2016

I think the name conflict with asanyarray is a serious drawback. The only way to keep the name and solve the clash would be to include the subok=True kwarg in the calls to array.

@efiring
Copy link
Contributor
efiring commented May 22, 2016

A better way to add the desired functionality would be via adding a kwarg to ascontiguousarray.

@seberg
Copy link
Member
seberg commented May 22, 2016

Good point, giving that an order keyword argument should be pretty uncontroversial. @pitrou maybe that would be a solution to continue here?

@charris
Copy link
Member
charris commented Dec 17, 2020

@pitrou I'm going to close this. @efiring's suggestion looks like a good one.

@charris charris closed this Dec 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants
0