Add endpoint parameter to linspace

[AKnassa]

Proposed changes

Fixes #4152.

mx.linspace always includes the stop value. numpy, jax and the array API all
let the caller drop it and space the samples over the half-open interval
[start, stop) instead. This adds the same option:

mx.linspace(0, 10, 5)                  # [0, 2.5, 5, 7.5, 10]
mx.linspace(0, 10, 5, endpoint=False)  # [0, 2, 4, 6, 8]   (matches numpy)

The implementation is the one-line change it looks like: divide by num instead
of num - 1 when the endpoint is excluded.

endpoint defaults to true, so existing behaviour is unchanged.

Placement of the argument

I put endpoint after dtype and before the stream, both in the C++ signature
and in the Python binding, so the stream stays last as it is everywhere else in
the API. That does shift the position of StreamOrDevice in the C++ signature,
but no in-tree caller passes the stream positionally to linspace, and the
Python stream argument is keyword-only in practice. Happy to move it if you
would rather it went elsewhere — the array API puts endpoint keyword-only
after dtype/device, while numpy has it fourth positional, so there is no
single obvious answer.

Testing

• test_linspace_endpoint in python/tests/test_ops.py, checked against numpy
  for num in {0, 1, 2, 5, 50}, for negative ranges, and with an integer
  dtype. It fails before this change and passes after.
• Extended the existing test linspace case in tests/ops_tests.cpp, since the
  C++ signature changed, including the num == 1 and num == 0 edges.
• Full Python suite: 820 tests, no new failures.
• Full C++ suite: 247 cases, all pass.
• Docstring updated; the generated .pyi picks the new signature up on build.

Built CPU-only (MLX_BUILD_METAL=OFF); the GPU suite was not run on my machine.

Checklist

• I have read the CONTRIBUTING document
• I have run pre-commit run --all-files to format my code / installed pre-commit prior to committing changes
• I have added tests that prove my fix is effective or that my feature works
• I have updated the necessary documentation (if needed)

[zcbenz]

endpoint parameter should be before dtype

[AKnassa]

Done. moved endpoint before dtype in both the C++ signature and the Python binding, so the order now matches numpy:

linspace(start, stop, num=50, endpoint=True, dtype=float32, stream=None)

Updated the in-tree callers that passed dtype positionally (test_ops.py, test_double.py, ops_tests.cpp). One heads-up: external calls that passed dtype as the fourth positional argument, e.g. mx.linspace(0, 1, 5, mx.float16), now raise a TypeError rather than being silently reinterpreted — same positional layout as numpy, but flagging it in case you'd prefer a deprecation path.

While there I extended the tests with a few more numpy-checked edges: positional endpoint, decreasing ranges, start == stop, integer-dtype truncation of fractional steps, and float64. Both suites pass (247 C++ cases; 820 Python tests, no new failures).

[zcbenz]

should it be arange(0, denominator)? jax seems to do so https://github.com/jax-ml/jax/blob/457c65e19bfe5693c16300b1cfd95a49bea318f2/jax/_src/numpy/array_creation.py#L620

[AKnassa]

Thanks for the pointer to the JAX implementation. I believe arange(0, num) is what we want here, though please correct me if I'm missing something.

If I'm reading the JAX code right, its iota can start at div because it appends the endpoint explicitly a few lines below the linked one (lines 625-627):

if endpoint:
    out = lax.concatenate([out, lax.expand_dims(broadcast_stop, (axis,))], ...)

so the iota produces num - 1 samples and the concatenate brings it up to num. If we changed only the arange bound here without also adding a concatenate, endpoint=True would return num - 1 samples and drop the last one (for example, linspace(0, 10, 5) would give [0, 2.5, 5, 7.5]).

For what it's worth, numpy's own implementation uses the same shape as this PR: div = (num - 1) if endpoint else num with arange(0, num) divided by div, followed by a y[-1] = stop fixup because its additive form can miss the endpoint due to rounding. The lerp form used here doesn't need that fixup, since the last t is (num - 1) / (num - 1) = 1.0 exactly, so the final sample lands exactly on stop. For endpoint=False the two spellings are equivalent anyway, since denominator == num in that case.

I also checked numerically that the JAX formulation and the current one produce bit-identical float32 results for num > 1 across increasing, decreasing, and degenerate ranges. That said, I'm happy to switch to the iota(div) plus concatenate structure if you would prefer it. It would just add a concatenate for the same values.

[zcbenz]

That makes sense, thanks for checking!