From: Mathew on
Hi all,

A kind of dummy question: we know in MATLAB .m file code, it is safe to do
2==2.0 and we can get true. My question is, does that cause problem when we compile the .m file to DLL? As it is not safe to do 2==2.00 in C/C++.

Thanks,
Mathew
From: Rune Allnor on
On 18 Mar, 19:54, "Mathew " <jhwan...(a)gmail.com> wrote:
> Hi all,
>
> A kind of dummy question: we know in MATLAB .m file code, it is safe to do
> 2==2.0 and we can get true. My question is, does that cause problem when we compile the .m file to DLL? As it is not safe to do 2==2.00 in C/C++.  
>
> Thanks,
> Mathew

http://matlabwiki.mathworks.com/MATLAB_FAQ#Why_is_0.3-0.2-0.1_not_equal_to_zero_.28or_similar.29.3F

Rune
From: Walter Roberson on
Mathew wrote:

> A kind of dummy question: we know in MATLAB .m file code, it is safe to do
> 2==2.0 and we can get true. My question is, does that cause problem when
> we compile the .m file to DLL? As it is not safe to do 2==2.00 in C/C++.

It is as safe to compare 2==2.0 in Matlab as it is in C (and vice versus.)
Which is to say that if you -calculated- the floating point 2.0 by operations
that might have rounding error, then it is not safe to compare the floating
point result to the integer result, in either language.

The normal situation with C++ is the same, but since it is allowed to overload
the == operator with an (int,double) method, 2==2.0 could mean nearly anything
in C++ ...
From: James Tursa on
"Mathew " <jhwang2k(a)gmail.com> wrote in message <hntssc$pkq$1(a)fred.mathworks.com>...
> Hi all,
>
> A kind of dummy question: we know in MATLAB .m file code, it is safe to do
> 2==2.0 and we can get true. My question is, does that cause problem when we compile the .m file to DLL? As it is not safe to do 2==2.00 in C/C++.
>
> Thanks,
> Mathew

In general, this will probably give the same result in the DLL as it did in the m-file, but there are some subtle issues that may depend on the C/C++ compiler. In the m-file, both 2 and 2.0 are double constants and MATLAB will read them in that way. In C/C++ source code, 2 is an int constant and 2.0 is a double constant, so if this were C code it will be up to the compiler to promote one of them to the other kind, in this case promoting the int to a double. What does MATLAB do with this when creating the DLL? I don't know ... maybe it turns the 2 into a 2.0 before handing it to the C compiler and maybe it doesn't. For the sake of argument, suppose it left it as 2 and handed that directly to the C/C++ compiler. Should still work for this case. But now suppose you had a large value that could not be represented exactly in double or even overflowed the largest integer value available
(e.g., 12345678901234567890). Now you get into the issues of how does MATLAB get this input into a double vs how does the C/C++ compiler turn the large integer (maybe 64-bit) into a double. Maybe they do it the same but maybe they do it slightly differently. Maybe the rounding is different. Maybe integer values that are too large for the type in C/C++ use modulo arithmetic to convert to double. Etc etc. So I could potentially see a different result. E.g., try this:

// File bigint.c
// To create the function, type mex bigint.c
#include "mex.h"
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
double d;
d = 12345678901234567890;
plhs[0] = mxCreateDoubleScalar(d);
}

And then run it. The lcc C compiler that I used did modulo arithmetic on the integer constant and actually returned a negative result. Probably not what you wanted based on the value you typed in. So if the MATLAB process for turning m-files into C code doesn't take this into account then there would be a problem. I would have to look into the doc to see if there is something there that specifies what MATLAB will do in these types of cases.

James Tursa
From: Ashish Uthama on
On Thu, 18 Mar 2010 14:54:04 -0400, Mathew <jhwang2k(a)gmail.com> wrote:

> Hi all,
>
> A kind of dummy question: we know in MATLAB .m file code, it is safe to
> do
> 2==2.0 and we can get true. My question is, does that cause problem when
> we compile the .m file to DLL?

It should not. In both cases the code is being interpreted/executed by
MATLAB. The 'compiled' MATLAB code runs against the MCR (MATLAB Component
Runtime) which should behave exactly like an interactive MATLAB session
for this case.