-
|
Hi! I don't get how pythoncall handles the different memory layout when converting between julia and numpy arrays. The reported array shapes are not what I would expect. Let's look at following example: arr = jl.rand(1,2,3)
arr_np = np.array(arr)
arr_np.shape # (1,2,3)As julia has column major memory layout and python is row-major I would expect the array shape one the python side to be (3,2,1). Why is it not? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
While you're right about the memory layout by default, both Julia and Numpy can happily handle arrays with other layouts - in particular they can both handle arrays with arbitrary strides. Hence PythonCall does the most obvious thing and preserves the array's shape and order of dimensions by representing a Julia column-major array as a strided array in Numpy. In practice it's common that you do actually want to reverse the order of the dimensions when going between Julia and Python precisely because of this ordering difference, which you can do with basically no overhead by transposing the array either before or after the conversion. |
Beta Was this translation helpful? Give feedback.
-
|
That makes sense. Thank you. Inspecting the strides reveals that they are (8, 8, 16) indeed for the above example. |
Beta Was this translation helpful? Give feedback.
While you're right about the memory layout by default, both Julia and Numpy can happily handle arrays with other layouts - in particular they can both handle arrays with arbitrary strides.
Hence PythonCall does the most obvious thing and preserves the array's shape and order of dimensions by representing a Julia column-major array as a strided array in Numpy.
In practice it's common that you do actually want to reverse the order of the dimensions when going between Julia and Python precisely because of this ordering difference, which you can do with basically no overhead by transposing the array either before or after the conversion.