2012-01-24 11 views
6

Tengo un archivo de Mex (compilado en VS2010, Matlab 2010b) que acepta una variable, y cambiarlo. Por ejemplo, en el archivo mex que parece:variables de Matlab muestran un comportamiento 'de referencia como' cuando se copian y se pasa a un archivo mex

double *fp = (double *)mxGetPr (prhs[0]); 
*fp = someDoubleValue; 

Con el fin de comparar la aplicación Matlab y la implementación mex, hago una copia de la variable antes de llamar al archivo de mex:

var_mex = var; 
mymex (var_mex); 

para mi sorpresa, tanto var_mex y var cambio (en el mismo valor, por supuesto), como si crea una referencia a var y no una copia de la misma.

Es éste un problema conocido? ¿Cómo puedo convencer a Matlab para que copie la variable?

EDITAR

Desde que sospechaba que esta cuestión es el resultado de Matlab optimizar su gestión de memoria, he hecho un poco de cálculo "no hacer nada" en la var antes de llamar al archivo de mex, es decir

var=var+1; 
var=var-1; 

y, de hecho, resuelve el problema. Todavía estaría contento de obtener algo de información (u otras sugerencias) sobre esto, si alguien lo encontraba también.

+2

Parece ser por diseño pasando por [esta página] (http://www.mit.edu/~pwb/matlab/). Quizás puedas modificar el var_mex antes de pasarlo, como multiplicarlo por 1. O agregar 1 y luego restar 1 en dos pasos discretos. – tinman

+0

sí, eso es exactamente lo que probé (y funcionó, ver mi edición). –

+2

¿Ha leído la documentación de Matlab sobre [la gestión de la memoria de Matlab] (http://www.mathworks.co.uk/help/techdoc/matlab_prog/brh72ex-2.html)? Eso explica este comportamiento. – tinman

Respuesta

7

En MATLAB, la mayoría de las variables se pasan alrededor de como si se pasasen por valor. La excepción notable a esto es que las instancias de clases que heredan de handle se pasan explícitamente por referencia.

Hay una blog entry here la que entra en algunos detalles sobre esto.

Por lo tanto, cuando se ejecuta

var_mex = var; 

Se termina con var_mex refiriéndose a los mismos datos que var.

Cuando está escribiendo en un mxArray dentro de una función mex, tiene un gran poder para romper cosas porque se le da la dirección subyacente de los datos. Si modifica un elemento de la matriz prhs, es posible que inadvertidamente termine modificando otras variables que comparten los mismos datos. Entonces, no hagas eso. De hecho, el mex doc explícitamente le dice que no haga eso.

La razón por la que funciona el var + 1 truco es que mediante la modificación de los datos, que está obligando a MATLAB para hacer una copia de los datos.

+1

"Así que no hagas eso. De hecho, el doc de mex explícitamente te dice que no hagas eso" +1 :) – Jonas

+0

¿Hay alguna razón específica por la cual el mecanismo mex no te impida cambiar las variables de entrada? –

+0

Bueno, la interfaz mex especifica que los punteros de prhs son const. La única manera factible de que la interfaz de mex pudiera garantizar que no causó modificaciones visibles a las prhs sería si se duplicaran en el camino a la función mex, lo que sería muy ineficiente. – Edric

0

Todas las variables en Matlab se pasan por valor.

Realizar cualquier cambio directamente en el lateral derecho argumentos en un mexfunction Matlab no está soportado oficialmente. Si está convirtiendo una función de Matlab del formulario A = func(A), entonces se le "requiere" que haga una copia de la matriz pasada A dentro de la función mexfunction.

+4

En el lenguaje MATLAB en sí, las variables se pasan * como si estuvieran por valor * usando la semántica de copiar y escribir. Esto explica por qué al agregar las cosas de "suma" de suma/resta, el valor se modifica y, por lo tanto, se debe realizar una copia. Una vez que esté en el mundo de los archivos MEX, estará solo y puede subvertir la administración de memoria estándar de MATLAB hasta cierto punto. – Edric

+2

@Edric: ¿Por qué no expandes el comentario en una respuesta? – Jonas

Cuestiones relacionadas