issue_comments

This sounds useful to me

I think it should be pretty reasonable to do that in a few lines, for numpy-backed arrays at least! Get the underlying numpy array, sort the .strides to get the memory order, map to dimension names, and pass them to transpose?

If it's easier, a method for "transpose these dimensions to the order which makes the data contiguous" would meet my needs.

I'm happy in principle to work on either feature, but when I've looked into contributing to xarray before, I've been a bit overwhelmed by complexity - I think I'm currently using a pretty small fragment of what it can do.

I think I see your point @takluyver — that by returning the new axes at the end it's both surprising and no longer a contiguous array.

But then +1 re your final point about unstack being unable to return a view on missing data.

I don't think it's impossible to carefully manage the dimensions order & contiguous-ness in this case. It may take someone who can champion it, though

@max-sixty - I certainly want to avoid copying the data unless it's necessary. But I'd like to present the axes in the 'real' memory order, from the largest stride to the smallest.

I appreciate that it shouldn't matter for program logic, but it can definitely matter for performance, and I know some users are going to use axes by position rather than by name, so I do consider it an important part of the API.

So I'm understanding correctly: does numpy's behavior even satisfy your reqs? https://docs.scipy.org/doc/numpy/reference/generated/numpy.swapaxes.html

then a view of a is returned

i.e. the array's underlying layout doesn't change, only the view...

This also means that either the new array is no longer C-contiguous, or the .unstack() operation has had to copy all the data to rearrange it.

The former. As a core design principle, xarray does not care about dimensions order, and any user code that implicitly relies on it should be considered a bad design. The .transpose() method mostly only exists for when people need to access the numpy .data object directly with a numpy function.

Thanks, it makes sense that dimension order conceptually doesn't matter so much once they're labelled. Though I'd say that as Xarray has public APIs for accessing dimensions by position, changing how something like .unstack() orders them probably is a breaking change.

I'm providing an API for other people to access data as a DataArray, and I'd like to have the dimensions in the order that makes it C contiguous, as a hint about what kinds of operations will be efficient. I know some users also go 'what is this complicated thing?' and extract the numpy array from it, in which case the order is more important.

So another option that would work for me would be a separate method that rearranges the dimensions to the order that makes the array C contiguous.

Thanks for the issue @takluyver

I mostly think (others should weigh in) that we don't spend much effort on dimension order. (Would a dimension order change always be a regression?). That's mostly because of one of xarray's great strengths: you don't need to worry about the order, because you can reference dimensions by name.

I imagine that unstack dimension order wasn't carefully chosen to be at the end vs in place; and we'd take a PR to make that change.