Should NamedArray be interchangeable with other array types? or Should we support the `axis` kwarg?

[dcherian]

What is your issue?

Raising @Illviljan's comment from #8304 (comment).

[max-sixty]

Please weigh this quite low give the amount of context I have — but I would vote "no". Arguably good APIs are limiting as well as permissive, and ideally users shouldn't rely on axis order.

(I would also vote to deprecate this from xarray)

That said, if there are real use-cases or compatibility concerns, I would override purity for practicality.

[dcherian]

Perhaps the real question is "Should NamedArray be interchangeable with other array types?" If so, we'd want to support all the various array protocols and the axis kwarg.

[max-sixty]

Perhaps the real question is "Should NamedArray be interchangeable with other array types?" If so, we'd want to support all the various array protocols and the axis kwarg.

Yes, that's very fair.

Maybe the synthesis of these is NamedArray should support it, but xarray shouldn't...?

[Illviljan]

Perhaps the real question is "Should NamedArray be interchangeable with other array types?" If so, we'd want to support all the various array protocols and the axis kwarg.

I've been thinking that's what namedarray._array_api is for. But .reduce is not a part of the array api standard so we don't have to add axis to it.

[dcherian]

But .reduce is not a part of the array api standard so we don't have to add axis to it.

Fair point.

---

Another thought: Like numpy, we could provide both an array api interface, and the Xarray type interface

So xp.mean(named_array, axis=1) or named_array.mean(dim="time") but not named_array.mean(axis=1) or xp.mean(named_array, dim="time"). That way you're explicitly choosing between unlabeled or labeled array semantics.

cc @shoyer

[TomNicholas]

Perhaps the real question is "Should NamedArray be interchangeable with other array types?"

I might be being dense, but what is the purpose of supporting xp.mean(named_array, axis=1)? You're treating a NamedArray like a numpy.ndarray by using axis integers, but the only difference between NamedArray and a numpy.ndarray is named dimensions (and perhaps carting around metadata). Why even bother using xarray at that point?

EDIT: I guess here xarray at least would be able to act as general wrapper for other array types (including chunked arrays)... But even then, why bother? The whole point of the array API standard is to make array types interchangeable, so NamedArray calls without using named dimensions are still adding nothing over using "bare" array-API-compliant types.

[dcherian]

I might be being dense,

Not at all! This is the core question. It's whether we think there's value in allowing users to seamlessly stick in NamedArray in their existing workflows. We can also punt and just stick to providing the current API (which I really like and prefer to the array API way, which seems to optimize for a library writer).

There's some precedence here in that we expect users to call np.abs(xarray_thing) which is massively confusing. "Why does a numpy function return an Xarray object?"

[TomNicholas]

It's whether we think there's value in allowing users to seamlessly stick in NamedArray in their existing workflows

What would the user really gain by replacing numpy.ndarray with NamedArray in their code, if none of the method / function calls changed to indicate dimension name? Has anyone actually seen a worthwhile use case for this?

[TomNicholas]

IMO the entire point of named dimensions has always been to remove a whole class of possible user errors: transposition errors. Supporting axis integers anywhere means code that uses xarray becomes vulnerable to such errors again, negating the benefit of using named dimensions.

[dcherian]

Has anyone actually seen a worthwhile use case for this?

There's a lot of appetite for computational functions that handle anything including DataArrays.

Example: https://github.com/NCAR/geocat-comp/blob/7b0ac8fbfe77c7a399b9a11a55076d6d02651046/geocat/comp/gradient.py#L178C26-L181

[TomNicholas]

There's a lot of appetite for computational functions that handle anything

Okay fair, now you say it I have seen that pattern also in MetPy. I have to say personally I've always viewed it as an antipattern though...

including DataArrays

Propagating a DataArray through xp.mean seems more useful than propagating a NamedArray through, because the DataArray actually carries coordinates/indexes with it. But that's not what we're proposing doing here.

@dopplershift do you want to state your case? 😁

So xp.mean(named_array, axis=1) or named_array.mean(dim="time") but not named_array.mean(axis=1) or xp.mean(named_array, dim="time"). That way you're explicitly choosing between unlabeled or labeled array semantics.

If we do choose to support axis integers then I prefer this solution, because it allows us to keep support for array-API-style functions a "hidden feature", without cluttering the xarray-method-chaining-style API.