np.linalg.pinv of a DataArray results in mismatched coordinates

[brsr]

What happened?

In general, np.linalg.pinv takes an array of shape (..., n, m) and returns an array of shape (..., m, n). Something isn't recognizing that the last two axes get switched around, so it incorrectly retains the coordinates in the same order.

In the attached example, m1 is an DataArray with shape (3,4) and defined coordinates, and m2 is the result of np.linalg.pinv(m1). m2 has shape (4,3), but maintains the coordinates from m1, which are 3 and 4 in length.

>>> m1
<xarray.DataArray (foo: 3, bar: 4)> Size: 96B
...
Coordinates:
  * foo      (foo) <U1 12B 'x' 'y' 'z'
  * bar      (bar) <U1 16B 'a' 'b' 'c' 'd'
>>> m2
<xarray.DataArray (foo: 4, bar: 3)> Size: 96B
...
Coordinates:
  * foo      (foo) <U1 12B 'x' 'y' 'z'
  * bar      (bar) <U1 16B 'a' 'b' 'c' 'd'

What did you expect to happen?

That the coordinates of m2 would have the same length as their respective axis's shape. Or at least an error message or warning or something.

Minimal Complete Verifiable Example

# /// script
# requires-python = ">=3.11"
# dependencies = [
#   "xarray[complete]@git+https://github.com/pydata/xarray.git@main",
#   "numpy"
# ]
# ///
#
# This script automatically imports the development branch of xarray to check for issues.
# Please delete this header if you have _not_ tested this script with `uv run`!

import xarray as xr
xr.show_versions()
# your reproducer code ...
import numpy as np
m1 = xr.DataArray(np.arange(12).reshape(3,4), 
                  coords={'foo': ['x', 'y', 'z'],
                          'bar': ['a', 'b', 'c', 'd']})
m2 = np.linalg.pinv(m1)

Steps to reproduce

No response

MVCE confirmation

• Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
• Complete example — the example is self-contained, including all data and the text of any traceback.
• Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
• New issue — a search of GitHub Issues suggests this is not a duplicate.
• Recent environment — the issue occurs with the latest version of xarray and its dependencies.

Relevant log output

Anything else we need to know?

This probably affects np.linalg.inv too, although less visibly.

Environment

Details

INSTALLED VERSIONS ------------------ commit: None python: 3.13.14 (tags/v3.13.14:fd17997, Jun 10 2026, 13:03:48) [MSC v.1944 64 bit (AMD64)] python-bits: 64 OS: Windows OS-release: 11 machine: AMD64 processor: Intel64 Family 6 Model 140 Stepping 1, GenuineIntel byteorder: little LC_ALL: None LANG: None LOCALE: ('English_United States', '1252') libhdf5: None libnetcdf: None

xarray: 2026.4.0
pandas: 3.1.0.dev0+140.gcc9e131258
numpy: 2.5.0
scipy: 1.18.0
netCDF4: None
pydap: None
h5netcdf: None
h5py: None
zarr: None
cftime: None
nc_time_axis: None
iris: None
bottleneck: None
dask: None
distributed: None
matplotlib: 3.11.0
cartopy: None
seaborn: None
numbagg: None
fsspec: None
cupy: None
pint: None
sparse: None
flox: None
numpy_groupies: None
setuptools: 82.0.1
pip: 26.1.2
conda: None
pytest: 9.1.1
mypy: None
IPython: 9.14.1
sphinx: 9.1.0

[welcome]

Thanks for opening your first issue here at xarray! Be sure to follow the issue template!
If you have an idea for a solution, we would really welcome a Pull Request with proposed changes.
See the Contributing Guide for more.
It may take us a while to respond here, but we really value your contribution. Contributors like you help make xarray better.
Thank you!

[dcherian]

ouch, i suspect this is using some kind of generic wrapper that doesn't know about linalg. A PR would be welcome

[keewis]

most likely __array_wrap__, in which case this is will be pretty tricky to implement (not sure if the context contains enough information)