API for variable number of returns in linalg

Feedback from @mruberry: it may be nice to support always returning the same type from functions like Cholesky, with tensors accessed by names. That way frameworks could return additional tensors and there wouldn’t be BC-compatibility issues if more tensor returns are added later. This suggestion, however, comes from a place of “it’d be nice if people wanted to use this API”, as opposed to the perspective of, “this API is a lowest common denominator only intended for library writers.”

cholesky always return a single array, so I thought it’d be fine - but the comment may be related to https://github.com/pytorch/pytorch/issues/47608 (desire to return an error code rather than raise a RuntimeError for failures). For qr, svd and perhaps some more functions there’s the related issue of different returns based on keywords. Using a class to stuff all return values in is a common design pattern for, e.g., scipy.optimize. I’m not convinced it’s a good idea for the linalg functions here, but worth considering at least.

[rgommers]

I re-read https://github.com/pytorch/pytorch/issues/46187, and PyTorch deviated on purpose from NumPy in the new design by always return a tuple with the max number of elements if there’s a boolean keyword to control number of returns in NumPy (e.g., svd(x, compute_uv=False) return an array in NumPy and a tuple (tensor([]), S, tensor([]) in PyTorch. The rationale is that this is much easier for the JIT; doing overloads on the boolean keyword is a pain.

The conclusion from that issue was that indeed dataclasses would be desirable long-term.

[asmeurer]

I don’t understand the technical details of that pytorch issue. Does it mean that any API that raises an exception is potentially problematic?