You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 27, 2021. It is now read-only.
While MATLAB's normal array format works wonderfully with numpy, complex data is a different matter. MATLAB stores the real and complex portions of an array in separate blocks of data (accessible via mxGetData and mxGetImagData). A 2x2 array might look like RRRR.....IIII (they aren't necessarily adjacent). This representation has some nice properties: It's trivial to pull out the real or imaginary part of a number, any numeric type can have imaginary parts of the same type, and if you need to upcast a real to a complex, it's a simple matter of tacking a zero array into the ImagData slot. (In fact, I recall hearing that if any numeric argument to a function is complex, then all the numerics will be coerced to complex. I could be misremembering that, though.)
Python (or at least NumPy) represents complex numbers as specific packed types. So the array is layed out like RIRIRIRI. This is also a perfectly reasonable layout. The real and imaginary portions could probably be accessed individually by creating views with specific striding. You could also imagine it (and possibly recast it) as an array with one extra dimension of size 2. It is a tad less convenient to upconvert a real to a complex, but that's life.
Anyway, for real numbers we take advantage of the fact that MATLAB's numeric datatypes have direct equivalents in NumPy and that NumPy is quite happy to work with Fortran-shaped arrays. Using numpy.asarray or similar along with mx.Array's __array_struct__ implementation, a NumPy array object can share data space with a MATLAB array. This is largely why the mltypes._numeric type doesn't currently provide any way to access the data - why worry about it when numpy.ndarray works so well already? The complex types sort of screw that idea up, though, and I'm not sure of the best way to resolve this. Since I don't presently have any need for complex support this is sort of on the backburner, though it is a bit of a glaring omission.
While MATLAB's normal array format works wonderfully with numpy, complex data is a different matter. MATLAB stores the real and complex portions of an array in separate blocks of data (accessible via
mxGetDataandmxGetImagData). A 2x2 array might look like RRRR.....IIII (they aren't necessarily adjacent). This representation has some nice properties: It's trivial to pull out the real or imaginary part of a number, any numeric type can have imaginary parts of the same type, and if you need to upcast a real to a complex, it's a simple matter of tacking a zero array into the ImagData slot. (In fact, I recall hearing that if any numeric argument to a function is complex, then all the numerics will be coerced to complex. I could be misremembering that, though.)Python (or at least NumPy) represents complex numbers as specific packed types. So the array is layed out like RIRIRIRI. This is also a perfectly reasonable layout. The real and imaginary portions could probably be accessed individually by creating views with specific striding. You could also imagine it (and possibly recast it) as an array with one extra dimension of size 2. It is a tad less convenient to upconvert a real to a complex, but that's life.
Anyway, for real numbers we take advantage of the fact that MATLAB's numeric datatypes have direct equivalents in NumPy and that NumPy is quite happy to work with Fortran-shaped arrays. Using
numpy.asarrayor similar along withmx.Array's__array_struct__implementation, a NumPy array object can share data space with a MATLAB array. This is largely why themltypes._numerictype doesn't currently provide any way to access the data - why worry about it when numpy.ndarray works so well already? The complex types sort of screw that idea up, though, and I'm not sure of the best way to resolve this. Since I don't presently have any need for complex support this is sort of on the backburner, though it is a bit of a glaring omission.