Compiler, interp1, superiorfloat, and strange

Here's the situation:
-Using the Matlab compiler to produce shared C++ libraries for
integrating into a C++ project on the Linux platform. I'm using
Matlab release 14 sp2
-After some fiddling/learning hard lessons (my programming experience
is mostly limited to Visual type environments) I was able to get the
example programs working properly (my experience shows that you must
use gcc version 3.2.3 exactly. v3.4 wouldn't work for me).

Now, what I'm trying to do is get a small c++ "driver" program
working that calls shared libraries produced by mcc from my own *.m
files. My library contains two functions. One function takes in a
string (a tab delimited filename) and outputs a 2D array which
contains some xy values that were in the file. The other function
takes in those xy values (and some other scaler type parameters) and
produces a vector of real feature values.

Here's the problem:
-When I tried to run the 2nd function it craps out on a call I make
to the internal matlab interpolation function 'interp1'. I am given
the following error:

Inputs to superiorfloat must be floats, namely single or double.

Superiorfloat is called in 'interp1'. When I test these functions in
Matlab only I never see this error. To fix it, I went over to the
place where I interpolate 'interp1' and added the 'double(??)'
function around all the inputs to cast them to the double format
(then recompiled the library). This change allows the driver program
to run to completion, but the values that I print for the output
feature vector TOTally don't agree with the ones I see when I run the
function in Matlab only.

Does anyone know what could be going on here? I feel like the
superiorfloat issue is related to the incorrect output.

Thanks

Stu

P.S. I debugged my driver program by printing out some of the
intermediate mxArrays that are produced and everything seems to check
out okay.

Hi Penny,
Thanks for the response. I definitely know when I step through my
code in Matlab (not C++ compiled) the workspace viewer tells me the
variable types are double. When I make the call in C++ land (as you
know I can't step into the Matlab library code) I am using an mwArray
variable called 'subarray', which is a subarray of the output (also
mwArray) from another compiled matlab library function. This is the
line where I define the subarray:

mwArray subarray(36,2,mxDOUBLE_CLASS);

I use a for loop in conjuction with the Get and Set member functions
of mwArray in order to transfer the values into 'subarray' (I have to
do this because I only want a subarray of a previous output). I
output 'subarray' to stdout just to make sure it is right, and it is.

So, you think some kind of float/double conversion issues could be
happening here? As long as I use mxDOUBLE_CLASS I should be working
with doubles in 'subarray', shouldn't I?

Any help would be appreciated.

Stu

P.S. YOu asked me what the variable types were for the compiled call
to interp, but that call is inside a compiled m file of mine... I
can't step through that code, can I?
Penny Anderson wrote:
>
>
> Stu,
>
> If you look at the class support line in the help for interp1:
> 
> INTERP1 1-D interpolation (table lookup)
> YI = INTERP1(X,Y,XI) interpolates to find YI, the values of the
> underlying function Y at the points in the array XI. X must be
> a
> vector of length N.
>
> <snip>
>
> Class support for inputs X, Y, XI:
> float: double, single
>
> See also interp1q, interpft, spline, pchip, interp2, interp3,
> interpn,
> ppval.
>
>
> you will see that the only supported inputs to interp1 are single
> and double
> precision inputs. Only the data inputs (optional X, Y and optional
> XI) need
> to be float (single or double). The inputs for METHOD, 'extrap',
> 'pp' etc.
> of course should be strings.
>
> What is the class of the inputs to your compiled call to interp1
> (before you
> cast them to double)?
>
> Penny Anderson
> The MathWorks, Inc.
>
> "Stu" <sdoherty@sympatico.ca> wrote in message
> news:ef04193.-1@webx.raydaftYaTP... 
> experience 
get
> the 
> must 
> *.m 
a 
function 
parameters)
> and 
> make 
> given 
double. 
functions
> in 
the 
format 
> program 
output 
run
> the 
> check 
>
>
>

Stu,

I guess you can't debug compiled code exactly, but you can print out the
values of

class(X)
class(Y)
class(XI)

before the call to

interp1(X,Y,XI,...)

and that might help you track down the problem.

interp1 should be able to handle both kinds of MATLAB "float" (short for
floating point data type) - both single and double. In order to trigger this
error message you should be using some other data type like integer (int8,
uint8, ...) or another datatype that is not supported by interp1.
superiorfloat will error if any of the inputs to interp1 is integer, cell,
struct, OOPS object, java object, ...

Penny Anderson
The MathWorks, Inc.

"Stu" <sdoherty@sympatico.ca> wrote in message
news:ef04193.1@webx.raydaftYaTP...
> Hi Penny,
>  Thanks for the response. I definitely know when I step through my
> code in Matlab (not C++ compiled) the workspace viewer tells me the
> variable types are double. When I make the call in C++ land (as you
> know I can't step into the Matlab library code) I am using an mwArray
> variable called 'subarray', which is a subarray of the output (also
> mwArray) from another compiled matlab library function. This is the
> line where I define the subarray:
>
> mwArray subarray(36,2,mxDOUBLE_CLASS);
>
> I use a for loop in conjuction with the Get and Set member functions
> of mwArray in order to transfer the values into 'subarray' (I have to
> do this because I only want a subarray of a previous output). I
> output 'subarray' to stdout just to make sure it is right, and it is.
>
> So, you think some kind of float/double conversion issues could be
> happening here? As long as I use mxDOUBLE_CLASS I should be working
> with doubles in 'subarray', shouldn't I?
>
> Any help would be appreciated.
>
> Stu
>
> P.S. YOu asked me what the variable types were for the compiled call
> to interp, but that call is inside a compiled m file of mine... I
> can't step through that code, can I?
> Penny Anderson wrote: 
> get 
> a 
> function 
> parameters) 
> double. 
> functions 
> the 
> format 
> output 
> run 

Okay, so I added the class(-) function call around all the inputs to
interp1 and test it out.

-In uncompiled matlab land all types were double.
-In compiled matlab/C++ land the first two types were double and the
last was int32...<-----that's a problem.

It's strange that the MCR thinks the variable is type int32 because
the line that creates the variable looks like this:
equal_space_t = [0:(N_pts*N_interp)]'*1/(N_pts*N_interp);

Where all the variables are integers. But the MCR should
automatically consider 'equal_space_t' as a double because of the
division: 1/(N_pts*N_interp)

I tried separating out the line and adding double() around each
instance of N_interp and the problem was solved. Now, why on earth
do I need to do that explicite cast. This seems like a bug type
issue to me.

Thanks for the Penny!

Stu

SoPenny Anderson wrote:
>
>
> Stu,
>
> I guess you can't debug compiled code exactly, but you can print
> out the
> values of
>
> class(X)
> class(Y)
> class(XI)
>
> before the call to
>
> interp1(X,Y,XI,...)
>
> and that might help you track down the problem.
>
> interp1 should be able to handle both kinds of MATLAB "float"
> (short for
> floating point data type) - both single and double. In order to
> trigger this
> error message you should be using some other data type like integer
> (int8,
> uint8, ...) or another datatype that is not supported by interp1.
> superiorfloat will error if any of the inputs to interp1 is
> integer, cell,
> struct, OOPS object, java object, ...
>
> Penny Anderson
> The MathWorks, Inc.

I mean, thanks for the HELP Penny! Not for the penny. :)

Stu wrote:
>
>
> Thanks for the Penny!
>
> Stu
>
> SoPenny Anderson wrote:

Stu,

The rules for MATLAB arithmetic are:

double OP double => double
integer OP integer => integer
integer OP double => integer

Note, this is opposite of C's rules for combined integer and double
operands, where the result would be double.

So if some of the operands to [0:(N_pts*N_interp)]'*1/(N_pts*N_interp) are
of integer class and some are double, then the result equal_space_t is going
to be integer class.

Penny Anderson
The MathWorks, Inc.

"Stu" <sdoherty@sympatico.ca> wrote in message
news:ef04193.3@webx.raydaftYaTP...
> Okay, so I added the class(-) function call around all the inputs to
> interp1 and test it out.
>
> -In uncompiled matlab land all types were double.
> -In compiled matlab/C++ land the first two types were double and the
> last was int32...<-----that's a problem.
>
> It's strange that the MCR thinks the variable is type int32 because
> the line that creates the variable looks like this:
> equal_space_t = [0:(N_pts*N_interp)]'*1/(N_pts*N_interp);
>
> Where all the variables are integers. But the MCR should
> automatically consider 'equal_space_t' as a double because of the
> division: 1/(N_pts*N_interp)
>
> I tried separating out the line and adding double() around each
> instance of N_interp and the problem was solved. Now, why on earth
> do I need to do that explicite cast. This seems like a bug type
> issue to me.
>
> Thanks for the Penny!
>
> Stu
>
> SoPenny Anderson wrote: