How can I mxCreateNumericArray with a fixed-point data type?

The documentation for mxCreateNumericArray has a nice table of mxClassID values for the first 10 or so built-in types like int8, uint8, single, double, etc.. However, there is no guidance for how to find the mxClassID for a fixed-point datatype.

In my case for example, the DTypeId (which is not the mxClassID) is DTypeId 14, aka "sfix16_En13". If it helps to know how I acquired this fixed-point data in the first place: the data is retrieved from a Simulink block input signal (e.g. ssGetInputPortSignal and ssGetInputPortDataType). But how do I get from DTypeId to mxClassID?

Apparently the Fortran language mxArray API has a function "mxClassIDFromClassName" which sounds very useful here. However, this function is not available in C MEX. I cannot seem to locate any references or methods that would provide mxClassID values for fixed-point datatypes... and so I cannot seem to create a numeric array of fixed-point data!

Any ideas?

Answer 1

[James Tursa]

There is a fundamental difference between the standard numeric types and fixed-point types.

The storage for standard numeric types (double,single,uint8,...,uint64,int8,...,int64) is a simple block of memory containing the values. The mxCreateNumericArray( ) API function is designed to create only these standard numeric types. (As a side note, it also works for char and logical types as well but this isn't documented).

The fixed-point types are not stored the same as the standard numeric types. Fixed-point types are actually a type of OOP object. You cannot use API functions like mxCreateNumericArray( ) to create OOP objects. Even if you fed it the custom classid for your OOP object, mxCreateNumericArray( ) would not be able to use it to create the fixed-point object.

The only way I know of to create OOP objects from within a mex routine is to use mexCallMATLAB( ) to call a constructor function for the OOP class.

Side Note: In C/C++ there is typically no need for a mxClassIDFromClassName( ) function since you can use the enumerated values directly. E.g., instead of using mxClassIDFromClassName("double") you can simply use mxDOUBLE_CLASS directly in your code.

[Keith Lundberg]

Thank you James Tursa for giving me clarity on this issue. I suppose I'm looking at some work to pass a fixed point data value from C MEX up to into a MATLAB function--- but you've given me an approach (call up into MATLAB to create an mxArray of the correct type). Thanks again!

[James Tursa]

Note that since fixed-point types are OOP objects, you won't be able to do much with them directly in a mex routine. Any manipulation involving them will probably have to be done with mexCallMATLAB( ) calls.

[Keith Lundberg]

Yes I'm having trouble even once MATLAB gives me an OOP object back (as an mxArray) I cannot seem to copy its value into a output signal buffer for my Simulink S-Function. I was hoping that mxGetData would point to an OOP object that I could just copy into a ssGetOutputPortSignal signal buffer - but alas this does not work. I'm not sure if its the source location (mxGetData), the number of bytes copied (from datatype size and number of elements), or the entire format of data that's off.

Based on your comments so far, I'll have to assume the entire data format is off. I'll search for some data value I can extract from the OOP object while in MATLAB that could then be placed into a Simulink signal buffer. Presumably I could grab data with some type of reinterpret cast to format it as integer values so the mxArray returned from MATLAB is not even an OOP object at all but rather the "raw bytes" for me to copy into the signal buffer. I cannot thank you enough for clarifying that I'm dealing with an object instead of just data values.

[Keith Lundberg]

Ah yes- a working solution is to grab the "storedInteger" value from the fixed-point type while in MATLAB and return that. The mxArray returned to C language is just data bytes that can copy into the signal buffer.

[James Tursa]

The only thing you can do with an OOP object inside a mex routine is mxGetProperty and mxSetProperty, both of which involve deep data copies. You need to know the property name to use these functions, and those properties need to be standard types to be of use to you inside the mex routine.

A workaround, as you seem to have discovered, is to do a conversion from the OOP object to a standard numeric variable outside the mex routine (either before calling it or via a mexCallMATLAB call). mxGetData on an OOP object isn't going to work to get at the underlying data. The pointer that mxGetData would give you simply points to an area of memory that contains proprietary stuff for the fixed-point object, and none of this is published. Bottom line is that pointer is useless to you.