More fixes for torch linalg extension

[asmeurer]

Mostly minor stuff, like incorrect type promotion or some functions not supporting integer dtypes.

[lezcano]

Just left a general note, but it's not directly related to this PR.

[lezcano]

These semantics allow for a weird construction like vecdot(xp.randn(1,4,5,6), xp.randn(6), axis=0) which would be equivalent to xp.randn(1,4,5,6) * xp.randn(6). This may be a discussion for the general broadcasting rules for the API, but perhaps you want that to assert that all(x.ndim - 1 >= axis for x in input_tensors) (perhaps with some special treatment for 0-dim tensors).

[asmeurer]

Now that I think about it, I wonder if this sort of thing should already be disallowed by the spec. https://data-apis.org/array-api/latest/API_specification/generated/array_api.vecdot.html#array_api.vecdot

I've been working on the assumption that axis refers to the dimension after broadcasting ("Must be an integer on the interval [-N, N), where N is the rank (number of dimensions) of the shape determined according to Broadcasting."). But it also says "The contracted axis (dimension) must not be broadcasted."

I had been interpreting that as meaning you shouldn't allow something like vecdot(empty((3, 3)), empty((1, 3)), axis=0). But I suppose it could also be taken to mean that broadcasting shouldn't "broadcast up" to the contracted dimension either. Something more along the lines of

if axis >= 0:
    ndim = max(x.ndim for x in inputs)
    if any(axis < ndim - x.ndim for x in inputs):
        raise ValueError("Contracted axis cannot be broadcasted")

(e.g., vecdot(empty((1, 2, 3, 4, 5)), empty((3, 4, 5)), axis=2) is fine but vecdot(empty((1, 2, 3, 4, 5)), empty((3, 4, 5)), axis=0) is not)

[lezcano]

I think disallowing both (not broadcast along the reduced dimension and ask for the axis to be well defined in the sense you just described) would be the safer thing to do, as otherwise you end up with these funny constructions, which is not great.

[asmeurer]

This is an issue in all the other implementations too, and arguably the spec as well. I'm going to deal with it in a separate PR.