[BUG] `Invalid type ndarray` for complex, non-contiguous `np.array` input to `mx.array`

[charlesbmi]

Describe the bug Cannot initialize mx.array from a complex, non-contiguous np.array, and the error message is confusing.

To Reproduce

import numpy as np
import mlx.core as mx

contiguous_array = np.random.rand(10, 10).astype(np.complex64)

# Make the array non-contiguous by transposing it
non_contiguous_array = contiguous_array.T

# Ensure the array is non-contiguous
assert not non_contiguous_array.flags["C_CONTIGUOUS"]

# Attempt to move the non-contiguous array to the GPU
gpu_array = mx.array(non_contiguous_array)
# Perform a simple operation just to check
result = mx.sum(gpu_array)

Expected behavior Expected to run without errors.

Actual error:

Traceback (most recent call last):
  File ".../mlx_complex.py", line 14, in <module>
    gpu_array = mx.array(non_contiguous_array)
ValueError: Invalid type  ndarray received in array initialization.

Note: workarounds are:

• forcing the array to be contiguous with np.ascontiguousarray, which works, but took me a while to figure out that this is a requirement
• use real-valued array (okay in this toy example, but I am interested in using this for complex data)

Desktop (please complete the following information):

• OS Version: Sonoma 14.6.1 (23G93)
• Version: 0.16.3

  ❯ pip list | grep mlx
  mlx                                               0.16.3
  ❯ pip list | grep numpy  
  numpy                                             1.26.4

Additional context Add any other context about the problem here.

[awni]

This looks like a Nanobind issue. FIled here https://github.com/wjakob/nanobind/issues/709, let's see if it is something they can fix.

[awni]

This is fixed in nanobind on the main branch. Since there is a work-around using ascontiguousarray I will wait until the next Nanobind release, then we can bump MLXs nanobind dependency and close this. The Nanobind release cycle is about 3 months so it could be a couple months before this is closed.

If it's more urgent we could always discuss versioning our own Nanobind on PyPi.. but I don't think it's merited just for this.

[charlesbmi]

Sounds good, thanks!

[charlesbmi]

Thanks!