MLX compatibility: Creation functions

[aaishwarymishra]

Array API	MLX Analog	Status	Blame / Notes	Upstream	Test Node	Result
arange(start, /, stop=None, step=1, *, dtype=None, device=None)	arange(start, stop, step, dtype=None, *, stream=None)	partial	stop=None now accepted. Remaining failure: integer args larger than signed 32-bit (e.g. step=2**31) — the nanobind binding uses C++ int, so xp.arange(n-1, n+3) with n = iinfo(int32).max raises TypeError. Still no device.	ml-explore/mlx#3982 (merged); int32 limit not yet reported	test_arange	Failed
asarray(obj, /, *, dtype=None, device=None, copy=None)	asarray(a, dtype=None, *, copy=None)	partial — won't fix	copy=False raises even for an MLX array already of the requested dtype. Fix was proposed and closed unmerged. No device; dtype not keyword-only.	ml-explore/mlx#4036 (closed, not merged)	test_asarray_arrays	Failed
empty(shape, *, dtype=None, device=None)	empty(shape, dtype=float32, *, stream=None)	undocumented	Implemented (pure alias) but still absent from MLX docs. No device.	ml-explore/mlx#3729 (merged)	test_empty	Passed
empty_like(x, /, *, dtype=None, device=None)	empty_like(a, /, *, dtype=None, stream=None)	undocumented	dtype now accepted — empty_like aliases zeros_like, so it inherited the fix. Still undocumented; no device.	ml-explore/mlx#4028 (merged); #4037 (closed, superseded)	test_empty_like	Passed
eye(n_rows, n_cols=None, /, *, k=0, dtype=None, device=None)	eye(n, m=None, k=0, dtype=float32, *, stream=None)	partial	eye(0) fixed upstream; the too-large-k failure was a test-suite issue, fixed at the tip of array-api-tests. Remaining failure: GPU scatter does not support uint64, so identity creation fails for that dtype.	ml-explore/mlx#3952 (merged); uint64 case not yet reported	test_eye	Failed
from_dlpack(x, /, *, device=None, copy=None)	from_dlpack(x, /, *, copy=None)	Incompatible	Test fails before reaching from_dlpack: MLX has no x.device and does not have device parameter in the signature	-	test_dlpack.py::test_from_dlpack	Failed
full(shape, fill_value, *, dtype=None, device=None)	full(shape, vals, dtype=None, *, stream=None)	signature mismatch	fill_value is named vals; dtype not keyword-only; no device.	—	test_full	Passed
full_like(x, /, fill_value, *, dtype=None, device=None)	full_like(a, vals, dtype=None, *, stream=None)	signature mismatch	fill_value is named vals; dtype not keyword-only; no device.	—	test_full_like	Passed
linspace(start, stop, /, num, *, dtype=None, device=None, endpoint=True)	linspace(start, stop, num=50, dtype=float32, stream=None)	partial — in progress	endpoint still unsupported, so endpoint=False fails. Draft PR open. No device.	ml-explore/mlx#4152 (issue, open), #4184 (draft PR, open)	test_linspace	Failed
meshgrid(*arrays, indexing="xy")	meshgrid(*arrays, sparse=False, indexing="xy", stream=None)	return mismatch — in progress	MLX returns a list; Array API 2025.12 requires a tuple.	ml-explore/mlx#4034 (issue, open)	test_meshgrid	Failed
ones(shape, *, dtype=None, device=None)	ones(shape, dtype=float32, *, stream=None)	signature mismatch	dtype not keyword-only; no device. Behavior passes.	—	test_ones	Passed
ones_like(x, /, *, dtype=None, device=None)	ones_like(a, /, *, dtype=None, stream=None)	signature mismatch	dtype added upstream as a keyword-only arg. No device.	ml-explore/mlx#4001 (issue, closed) → #4028 (merged)	test_ones_like	Passed
tril(x, /, *, k=0)	tril(x, k, *, stream=None)	signature mismatch	k accepted positionally; spec makes it keyword-only. Behavior passes.	—	test_tril	Passed
triu(x, /, *, k=0)	triu(x, k, *, stream=None)	signature mismatch	k accepted positionally; spec makes it keyword-only. Behavior passes.	—	test_triu	Passed
zeros(shape, *, dtype=None, device=None)	zeros(shape, dtype=float32, *, stream=None)	signature mismatch	dtype not keyword-only; no device. Behavior passes.	—	test_zeros	Passed
zeros_like(x, /, *, dtype=None, device=None)	zeros_like(a, /, *, dtype=None, stream=None)	signature mismatch	dtype added upstream as a keyword-only arg. No device.	ml-explore/mlx#4001 (issue, closed) → #4028 (merged)	test_zeros_like	Passed

[aaishwarymishra]

I wasn't able to run tests on this file mainly because,

• By default mlx arrays are on gpu stream and they dont support float64, many tests failed because of that.
• some tests were checking different datatypes the complex bug also affected these tests.
• No device parameter or method signature mismatch

[ev-br]

No device parameter

This is systemic and is worth noting indeed. Does not block testing at this stage, not more than cupy which does not have device arguments either.

By default mlx arrays are on gpu stream and they dont support float64, many tests failed because of that.

This is a nice observation and runs into a systemic problem in the test suite (cf data-apis/array-api-tests#440).
Meanwhile, can you run tests with set_default_device to CPU? https://ml-explore.github.io/mlx/build/html/python/_autosummary/mlx.core.set_default_device.html
That'd be similar to JAX, data-apis/array-api-tests#368 (comment)

---

Your table is very useful, but is a tad hard to read because the "notes" column runs into the page width, could swap with "Test node" and "result" columns.

And it'd be useful to continue compiling a compatibility table for the rest of the spec in this same issue.

[ev-br]

By default mlx arrays are on gpu stream and they dont support float64, many tests failed because of that.

In addition / as an alternative to setting the MLX default device to CPU, you may run the test suite with the environment variable ARRAY_API_TESTS_SKIP_DTYPES=float64,complex128. Skipping float64 mostly works: if a test fails with this skip and MLX, it'd be helpful to double-check the test failure with the skip and array_api_compat.numpy. If it still fails, the problem is with the test suite (please report it in data-apis/array-api-tests#431). If it passes with numpy and fails with MLX, then report the failure here.

[aaishwarymishra]

• arange: MLX rejects the valid three-argument form when stop=None, e.g. arange(0, None, 1).

• asarray: copy=False fails even when the input is already an MLX array with the requested dtype; MLX claims it cannot
  avoid copying.

• empty_like: MLX does not accept the standard dtype keyword—even dtype=None. The error mentioning zeros_like also
  suggests empty_like is internally aliased or misrouted.

• eye: two issues:

  • Zero-sized dimensions such as eye(0) are rejected.
  • Large valid diagonal offsets such as k=2147483648 overflow or fail MLX’s argument binding.

• linspace: MLX does not implement the endpoint keyword.

• meshgrid: MLX returns a list, but Array API 2025.12 requires a tuple.

• ones_like: MLX does not accept the standard dtype keyword.

• zeros_like: Same missing dtype keyword support.

what I found was the empty and empty_like was implemented on new release, but the docs wasn't updated so I marked them as missing, I will update that, out of 16, 8 passed and 8 failed.

For the from_dlpack its's test is in a separate file and it didn't ran It tried to determine which device to use in two ways:

1. With copy=False, it reads x.device, but MLX arrays do not have that attribute.
2. Otherwise, it call xp.array_namespace_info().devices(),but MLX does not implement array_namespace_info.
   Even if I manually hardcode the MLX device test will fail as mlx does not have device parameter which it is passing.

The two passing tests were:

• test_dlpack.py::test_dlpack_device
• test_dlpack.py::test_dunder_dlpack

Only test_dlpack.py::test_from_dlpack failed.

Details

FAILED array_api_tests/test_creation_functions.py::test_arange - TypeError: arange(): incompatible function arguments. The following argument types are supported:
FAILED array_api_tests/test_creation_functions.py::test_asarray_arrays - ValueError: Unable to avoid copy while creating an array as requested.
FAILED array_api_tests/test_creation_functions.py::test_empty_like - TypeError: zeros_like(): incompatible function arguments. The following argument types are supp...
FAILED array_api_tests/test_creation_functions.py::test_eye - ExceptionGroup: Hypothesis found 2 distinct failures. (2 sub-exceptions)
FAILED array_api_tests/test_creation_functions.py::test_linspace - TypeError: linspace(): incompatible function arguments. The following argument types are suppor...
FAILED array_api_tests/test_creation_functions.py::test_meshgrid - AssertionError: assert <class 'list'> == <class 'tuple'>
FAILED array_api_tests/test_creation_functions.py::test_ones_like - TypeError: ones_like(): incompatible function arguments. The following argument types are suppo...
FAILED array_api_tests/test_creation_functions.py::test_zeros_like - TypeError: zeros_like(): incompatible function arguments. The following argument types are supp...

[ev-br]

Thanks @aaishwarymishra , this is very helpful! Quick triage:

• {empty,zeros,ones}_like not accepting a dtype argument: this looks like a simple enhancement in MLX
• eye(0) : it's a simple edge case yes, an annoying one to run into, and a simple one to fix at the source
• arange(1, None, 1) : likewise, this shouldn't be a hard fix in MLX
• linspace(...., endpoint={True,False}: likewise

Of these, linspace I would very much prefer to not meddle with in the compat layer, as it's not intrinsically hard but is prone to small inconsistencies, and will need rather extensive testing to avoid mlx and _compat.mlx divergencies.

The other ones, one strategy could be to write small wrappers in a -compat fork/PR, make sure they pass the test suite, and then submit to MLX. When you do, feel free to link back here or ping me :-).
The wrappers ideally are temporary and are needed to see if there are other issues masked by a first problem.

• meshgrid returning lists not tuples: this was a deliberate change in 2025.12; NumPy changed in in 2.0, CuPy followed up in ENH: make broadcast_arrays, meshgrid return a tuple not list cupy/cupy#9582. I think there were no loud compaints about either change, which probably means the backwards compatibility effect is not serious in practice, so I'd advocate to just change it despite that it's a backcompat break.

These all are small-ish issues, would be nice to fix for user experience. In principle can fix in the compat layer, but even if we do, I'd very much prefer to have some strategy for adding them to MLX and dropping them from the compat layer.

• asarray(copy=False) failure is pointing at some deeper problem. Would be nice to understand in more details, could you provide an standalone MRE?

• the lack of .device array attribute is something which 1) we cannot work around in the -compat layer at all (we do not touch the array object); 2) is likely to be a tripping hazard going forward, as we improve the device support and work towards device-dependent dtype subsets, cf [RFC]: Updates for float16/bfloat16 and for dtypes that are lacking full support in libraries array-api#998

Working around the lack of .device attribute is brittle, cf

array-api-compat/src/array_api_compat/common/_helpers.py

Lines 781 to 792 in bbfe8c2

	# FIXME Jitted JAX arrays do not have a device attribute
	# https://github.com/jax-ml/jax/issues/26000
	# Return None in this case. Note that this workaround breaks
	# the standard and will result in new arrays being created on the
	# default device instead of the same device as the input array(s).
	x_device = getattr(x, "device", None)
	# Older JAX releases had .device() as a method, which has been replaced
	# with a property in accordance with the standard.
	if inspect.ismethod(x_device):
	return x_device()
	else:
	return x_device

so it would be really great if MLX could add the attribute, even if it's not used internally.

[rgommers]

I'll link to ml-explore/mlx#3484 (comment) as the recent comment with the MLX devs's stance. I'd suggest starting with the upstream changes that are most concrete, uncontroversial, and won't require separate kernel's. The first four bullets in the comment above could be a good start? eye(0) for example I'd expect to work well. meshgrid is simple but don't start with a backwards compat break; it's trivial to work around in this repo. .device definitely leave to the end, I don't expect that to be well-received.

[aaishwarymishra]

@ev-br Hi, I have made some pr's mainly focusing on bugs and non breaking changes :)