From: Jan Simon on 14 May 2010 11:27 Dear Fabio! > tree->n_nearest(query,k,result); Are you sure that you have to deliver "result" and not a pointer to it? Can you find the line inside n_nearest, which causes the crash? Jan
From: Fabio Pinna on 14 May 2010 11:52 Dear Jan, The line which causes n_nearest to crash is a logic check and from the stack trace it seems like a vector has been asked to retrieve a data out of its bounds. Indeed at that line I have something like if (p[i]>r[i] ) About the "result" to deliver I guess that if I had this problem this should happen for every data set and not just for some of them ... or maybe I didn't understand completely your point. Fabio "Jan Simon" <matlab.THIS_YEAR(a)nMINUSsimon.de> wrote in message <hsjq4a$hf1$1(a)fred.mathworks.com>... > Dear Fabio! > > > tree->n_nearest(query,k,result); > > Are you sure that you have to deliver "result" and not a pointer to it? > Can you find the line inside n_nearest, which causes the crash? > > Jan
From: Jan Simon on 14 May 2010 12:40 Dear Fabio! > For some particular input data the mex file is causing matlab to crash. What is p, r and i in your example? Any confusions between the 0-based indexing of C++ and 1 based indexing of Matlab? What is so particular for the input data? An even or uneven number of elements? Large arrays? Jan
From: Fabio Pinna on 14 May 2010 13:31 Sorry "p" and "r" are just a two dumb vectors I used as an example. This was just a simpllified way to show the expression that I have in my code Regarding the size I have still to verify if something special is going on. I made test with bigger/smaller data sets and nothing happened. Anyway as data come from a space partioning algorithm the way I patch the space could maybe give a local bigger data set to process. I need to check that Anyway do you think that a too big matrix could give a problem in matlab but not in c++? Actually in the special data set I found out that the computation doesn't stop immediately, it runs through the same command again and again and then it stops. Actually the issue of 0-based indexing came to my mind but the transformation has been taken in account in the file I posted before, and as the command is hit several time before crashing it means that just one index should be wrong or one element of the data set corrupted (it is not the case as you will see in the 2 test I made). I made also two tests 1) I used the same data set but in a "shrinked" way, cutting away either the first 200 elements or the last 200 . In both cases the command ran succesfully. 2) I exported the MATLAB workspace. Then I used the save function to save the data I need as text file and then I imported them in a c++ file to use my code as pure c++. So those data are coming directly from matlab and they are the same as the ones causing the mex to crash. Fab
First
|
Prev
|
Pages: 1 2 Prev: Colormap "direction" Next: Problems with different versions of Matlab |