Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Passing of integer (index) arrays to C-based MEX file

84 views
Skip to first unread message

Mark

unread,
Jun 28, 2009, 10:25:02 AM6/28/09
to
Hi All,

I am writing some C-based MEX files including input parameters which contain indices to arrays. My codes should compile both on 32-bit and 64-bit Windows.

In the code, I have been using the "type" mwIndex - it seems this should be helpful when compiling for either 32/64-bit.

The Mathworks example "mxcalcsinglesubscript.c" takes input indices as double's, then typecasts them to mwIndex in a new local variable. This seems rather inefficient, especailly when my arrays of indices become very large.

Could someone please describe how best to directly pass integer arrays intended for indexing?
It appears that I can "cast" the arrays as e.g. uint32 in the Matlab call and then use the mwIndex type in the C code. If this is an appropriate method, is there anyway for Matlab to automatically know what integer type corresponds to mwIndex during run-time on a particular machine?

My other question is:
At present, I am using mwIndex throughout my C-code, i.e. in all the sub-routines. However, besides the gateway function, I would like the sub-routines to be independent of mex.h, for use in other non-Matlab work. At the same time, if I use int I guess the same code will not run properly on both 32-bit and 64-bit (is that right?)
What is the preferred method in C to use the correct integer type for a given platform, to avoid mwIndex (yes...sorry, I should probably post this on a C forum!)

Many thanks, MT

Rune Allnor

unread,
Jun 28, 2009, 11:10:19 AM6/28/09
to
On 28 Jun, 16:25, "Mark" <markie_thom...@yahoo.de> wrote:
> Hi All,
>
> I am writing some C-based MEX files including input parameters which contain indices to arrays.  My codes should compile both on 32-bit and 64-bit Windows.
>
> In the code, I have been using the "type" mwIndex - it seems this should be helpful when compiling for either 32/64-bit.

That's why the type is there: So that you as coder don't have
to worry about exact formats. That's the job of the compiler.

> The Mathworks example "mxcalcsinglesubscript.c" takes input indices as double's, then typecasts them to mwIndex in a new local variable.  This seems rather inefficient, especailly when my arrays of indices become very large.

It might be, but maybe not as large as you think. Keep in
mind that you are working with C, which is a compiled lanuage.
Matlab is an interpreted language. The difference is that
a compiler can optimize away a lot of stuff at compile
time, whereas matlab needs to check all kinds of options
at run-time. So expect matlab to work orders of magnitude
faster than matlab.

But yes, the double -> int conversion takes time.

> Could someone please describe how best to directly pass integer arrays intended for indexing?
> It appears that I can "cast" the arrays as e.g. uint32 in the Matlab call and then use the mwIndex type in the C code.  If this is an appropriate method, is there anyway for Matlab to automatically know what integer type corresponds to mwIndex during run-time on a particular machine?

That knowledge isn't used at run-time, but at compile-time.
The conversion int32 -> int64 might be a bit quicker than the
double -> int conversion, but it's still a conversion.

> My other question is:
> At present, I am using mwIndex throughout my C-code, i.e. in all the sub-routines.  However, besides the gateway function, I would like the sub-routines to be independent of mex.h, for use in other non-Matlab work.  At the same time, if I use int I guess the same code will not run properly on both 32-bit and 64-bit (is that right?)

You are taking chances, yes.

> What is the preferred method in C to use the correct integer type for a given platform, to avoid mwIndex  (yes...sorry, I should probably post this on a C forum!)

I don't know what is common in C, but in C++ I would use
ptrdiff_t from the <cstddef> header for indexing variables.
With a little bit of luck the header is also available in C.

Rune

Mark

unread,
Jun 28, 2009, 12:23:01 PM6/28/09
to
Hi Rune,

Thanks for the reply. I guess this is just the first situation where typecasting (either in Matlab before the call, or double->something in C) is going to arise (e.g. I will probably want to use single precision for the data in my codes).
I will try to use the correct type in Matlab to begin with...

> > It appears that I can "cast" the arrays as e.g. uint32 in the Matlab call and then use the mwIndex type in the C code. ?If this is an appropriate method, is there anyway for Matlab to automatically know what integer type corresponds to mwIndex during run-time on a particular machine?


>
> That knowledge isn't used at run-time, but at compile-time.
> The conversion int32 -> int64 might be a bit quicker than the
> double -> int conversion, but it's still a conversion.
>

Here I meant in Matlab when making the mex call. Now I use the matlab function cast, e.g. "cast(indices,inttype)", where "inttype='uint32'" is defined at the top of my Matlab code. I guess I change this to 'uint64' onthe 64-bit system?
I was looking for a Matlab function to read the system info and determine this automatically..

Regards, MT

Bruno Luong

unread,
Jun 28, 2009, 12:47:01 PM6/28/09
to
"Mark" <markie_...@yahoo.de> wrote in message <h285d5$1l5$1...@fred.mathworks.com>...

You might use COMPUTER() to determine if your system.

If you want to avoid casting, you might want to create your data in int64 or int32 classes under Matlab. The problem I see is it's still not possible to perform any arithmetic operations on int64 within MATLAB.

>> uint64(0)+uint64(1)
??? Undefined function or method 'plus' for input arguments of type 'uint64'.

int32 range might be large enough for your application. You might want to just to copy just the first 32-bits into mxIndex array instead of rigorous casting. In any case if you start to optimize this kind of thing, it might be good to think about how to avoid developing your application under Matlab all together.

Bruno

0 new messages