Converting Matlab code to C code

I'm trying to convert the following matlab code to c code, I did it both in windows and in linux systems by using Visual Studio in windows and gcc in linux as the compiler. However I couldn't get correct results by running the generated c code. Can anyone have a idea how to modify this matlab code in order to generate the matched c code? I would appreciate that!

function  matc(n)
val = 0;
for i = 1:n
    x = 2*rand(3,1);
        val = val + f(x);    
end
val = 2^3*val/n

[Friedrich]

What is f ?

[AW]

function y = f(x)

y = sin(x(1) + x(2)^2 +x(3)^3);

[James Tursa]

Please format your code so it is readable. Is the function supposed to return val? Are you looking for a mex function, or just a C-language code snippet?

[AW]

Right, return val. I was trying to generate a c executable by initializing n with a value(for example, adding n=1000 to the code). Thanks.

function matc(n)

val = 0;

for i = 1:n

x = 2*rand(3,1);

val = val + f(x);

end

val = 2^3*val/n

function y = f(x)

y = sin(x(1) + x(2)^2 +x(3)^3);

[Kaustubha Govind]

How exactly do the results vary?

[AW]

Sometimes I got val=4.94066e-324, sometimes I got val=0. I use the following code in file main.c:

#include <stdio.h>

#include <stdlib.h>

#include <math.h>

#include "matc.h"

int main()

{

printf("matc=%g\n", matc());

return 0;

}

I'm not sure if it's because of the main.c file, I have modified it to several different versions, but still couldn't get the matched c code.

Any idea? Thanks for your help!

Answer 1

[Kaustubha Govind]

To expand's on Walter's answer, your MATLAB code should look like this:

function val = matc(n)

val = 0;
for i = 1:n
x = 2*rand(3,1);
val = val + f(x);
end
val = 2^3*val/n

function y = f(x)
y = sin(x(1) + x(2)^2 +x(3)^3);

(Note how 'val' is being returned from the function by adding it to the "function" line).

And your C code should look like this:

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include "matc.h"
int main()
{
  printf("matc=%g\n", matc(0.2));
  return 0;
}

Note how an input value needs to be passed into matc.

Answer 2

[Walter Roberson]

You are not passing any value from the C code to the matc() routine. The initial value of an undefined parameter is undefined, so any result could occur.

Answer 3

[AW]

Thanks for your replying. I defined n as double(1x1) while I was creating a project using matlab coder. Is that fine?

[Walter Roberson]

Yes, having it declared as type double is fine, but you still need to pass a specific variable in to matc() when you make the call to matc()

printf("matc=%g\n", matc(42.));

Answer 4

[AW]

Thanks a lot! I tested it with your suggestions, still get a result of 0. I use the following command for generating c code, codegen -config cfg matc -args {1000}

[Walter Roberson]

What does your code look like at present?

[AW]

function val = matc(n) %#codegen

val = 0;

for i = 1:n

x = 2*rand(3,1);

val = val + f(x);

end

val = 2^3*val/n

function y = f(x)

y = sin(x(1) + x(2)^2 +x(3)^3);

in file main.c,

#include <stdio.h>

#include <stdlib.h>

#include <math.h>

#include "matc.h"

int main()

{

printf("matc=%g\n", matc(1000));

return 0;

}

[Walter Roberson]

Looks plausible. I would put a line in matc() displaying the value of n at the beginning, to cross-check that you are getting the input you expect.

[AW]

Thank you for the suggestion. I did it with adding n=1000, but still got a 0.

[Kaustubha Govind]

Try putting a statement "disp(val)" at the bottom of your "matc" function and recompile the code. Does the MATLAB code display a zero too?

[AW]

I got an error message shows that "Function 'disp' is not supported for code generation. Consider using coder.extrinsic('disp') to bypass code generation.". So I added "coder.extrinsic('disp')" associated with "disp(val)". But still get a zero.

[Walter Roberson]

So somehow the argument isn't getting passed in correctly, I don't know why at the moment.

Say, what does matc.h contain?

[AW]

/*

* matc.h

*/

#ifndef __MATC_H__

#define __MATC_H__

/* Include files */

#include <math.h>

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include "rt_nonfinite.h"

#include "rtwtypes.h"

#include "matc_types.h"

/* Type Definitions */

/* Named Constants */

/* Variable Declarations */

/* Variable Definitions */

/* Function Declarations */

extern real_T matc(real_T n);

extern void matc_initialize(void);

extern void matc_terminate(void);

#endif

[Walter Roberson]

Hmmm, I wonder if real_T is single or double precision?

And I wonder if the code generator is treating 1000 as integer?

Could I ask you to indulge my curiosity and try 1000. (with the perod to force syntactic floating point) ? And to also try with

single(1000) and double(1000) ?

[AW]

I did the tests with 1000., single(1000) and double(1000). All come with zero results.

Answer 5

[AW]

Anyone has an idea? Thanks.

[Kaustubha Govind]

AW: I would recommend using a "disp" command in your script. Since disp is not supported for code-generation, you need to add this line at the top of your function:

coder.extrinsic('disp');

%eml.extrinsic('disp') for older versions of MATLAB

Then, generate a MEX-file from your code (instead of standalone C code). You can use the command:

>> codegen -config:mex matc.m

Then run the generated MEX-file in MATLAB. What does the disp command show?

Answer 6

[AW]

Thanks all for your suggestions!

Finally the code was generated to C successfully. Updated matc.m and main.c are listed as following.

% matc.m

function val = matc(n)   %#codegen

val = 0;

for i = 1:n

      x  = 2*rand(3,1);
      val = val + f(x);

end

val = 2^3*val/n;

end

function y = f(x)

y = sin(x(1) + x(2)^2 +x(3)^3);

end

------------------------------------------

/*
** main.c
*/

#include <stdio.h>

#include <stdlib.h>

#include <math.h>

#include "matc.h"

#include "matc_initialize.h"

#include "matc_terminate.h"

int main()

{

    matc_initialize();
    printf("matc=%lf\n", matc(1000));
    matc_terminate();
    return 0;
}

[Kaustubha Govind]

Thanks for posting back your answer, AW. So what exactly was the error you were making before?

[Walter Roberson]

The difference seems to be the %#codegen