Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
Bug or feature in mex32 ?

Subject: Bug or feature in mex32 ?

From: Jack

Date: 30 Jul, 2008 10:43:09

Message: 1 of 6

I've found very strange behavior of mex32:

>> mex test001.c
>> test001
32.000000 - wrong result this is not =log(1.1)
>>log(11600000)
ans =
   NaN - wrong result too....
>>

list of test001.c:
=================================================
#include "mex.h"
void mexFunction( int nlhs, mxArray *plhs[],
                  int nrhs, const mxArray *prhs[])
{
double x,y;
y=1.1;
x=log(y);
printf("%f\n", x);
}
=================================================

This was tested on 3 diffrent computers in R2008 and in R13

Subject: Bug or feature in mex32 ?

From: Rune Allnor

Date: 30 Jul, 2008 10:52:44

Message: 2 of 6

On 30 Jul, 12:43, "Jack " <jackfr...@list.ru> wrote:
> I've found very strange behavior of mex32:
>
> >> mex test001.c
> >> test001
>
> 32.000000 =A0- wrong result this is not =3Dlog(1.1)>>log(11600000)
>
> ans =3D
> =A0 =A0NaN - wrong result too....
>
>
>
> list of test001.c:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> #include "mex.h"
> void mexFunction( int nlhs, mxArray *plhs[],
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int nrhs, const mxArray *prhs[])
> {
> double x,y;
> y=3D1.1;
> x=3Dlog(y);
> printf("%f\n", x);}
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> This was tested on 3 diffrent computers in R2008 and in R13

Code cut'n pasted straight from your post, compiled with
Visual Studio 2005 and run under R2006a:

>> test001
0.095310

Rune

Subject: Bug or feature in mex32 ?

From: Jack

Date: 30 Jul, 2008 11:26:04

Message: 3 of 6

Im sorry, I forgot to tell you main thing:
to reply this bug you need to use lcc complier with -g
(debug option)

Subject: Bug or feature in mex32 ?

From: Titus

Date: 30 Jul, 2008 11:52:08

Message: 4 of 6


"Jack " <jackfrost@list.ru> schrieb im Newsbeitrag
news:g6pgjt$qah$1@fred.mathworks.com...
> I've found very strange behavior of mex32:
>
>>> mex test001.c
>>> test001
> 32.000000 - wrong result this is not =log(1.1)
>>>log(11600000)
> ans =
> NaN - wrong result too....
>>>
>
> list of test001.c:
> =================================================
> #include "mex.h"
> void mexFunction( int nlhs, mxArray *plhs[],
> int nrhs, const mxArray *prhs[])
> {
> double x,y;
> y=1.1;
> x=log(y);
> printf("%f\n", x);
> }
> =================================================
>
> This was tested on 3 diffrent computers in R2008 and in R13

Hi Jack,
that's a C problem and not a problem of mex. Adding
#include <math.h>
solves it... Rune did not see the problem because Visual Studio (depending
on properties set) always includes math.h. And if no prototype is there, a C
compiler generates one (using integers) ...

Titus

Subject: Bug or feature in mex32 ?

From: Jack

Date: 30 Jul, 2008 13:19:03

Message: 5 of 6

 
> Hi Jack,
> that's a C problem and not a problem of mex. Adding
> #include <math.h>
> solves it... Rune did not see the problem because Visual
Studio (depending
> on properties set) always includes math.h. And if no
prototype is there, a C
> compiler generates one (using integers) ...
>
> Titus
>
Many thanks!
But I already understand that "log" is a kind of function
in mex.h and it returns int type!

But why MATLAB log evaluted after test001 returns bad
value? I fixed all #includes but still have some problems
with it...

Subject: Bug or feature in mex32 ?

From: Titus

Date: 30 Jul, 2008 20:10:12

Message: 6 of 6


"Jack " <jackfrost@list.ru> schrieb im Newsbeitrag
news:g6ppo7$55v$1@fred.mathworks.com...
>
>> Hi Jack,
>> that's a C problem and not a problem of mex. Adding
>> #include <math.h>
>> solves it... Rune did not see the problem because Visual
> Studio (depending
>> on properties set) always includes math.h. And if no
> prototype is there, a C
>> compiler generates one (using integers) ...
>>
>> Titus
>>
> Many thanks!
> But I already understand that "log" is a kind of function
> in mex.h and it returns int type!
>
> But why MATLAB log evaluted after test001 returns bad
> value? I fixed all #includes but still have some problems
> with it...
>

Perhaps you could show us your new version test001 and
the output, because including the include statement
everything works as expected for me...

Titus

Tags for this Thread

No tags are associated with this thread.

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us