Thread Subject:

Bug or feature in mex32 ?

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

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

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

"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

 
> 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...

"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