Thread Subject: changing mex input variables

Hello:

I am in the process of writing a mex interface to Michael Saunders's LUSOL that
allow updates to a sparse LU factorization. The LUSOL source package already
has an interface that returns the L and U factors, but does not allow updating.

LUSOL operates on a set of vectors, three of which are long and take up the
bulk of the storage. The updating routines operate on these vectors. Thus, I
would like to avoid having to copy these vectors at each update.

My plan was to create a matlab class with private properties. The calls to the
mex functions would change these properties. This would break the matlab
convention of functions not changing their input variables. I also came across
a warning in the Matlab documentation against this practice.

Here's how it would work:

% set up the object and factorize
>> fac = lusol(A);

lusol would then call something like lusol_mex(i,j,a), which would modify i, j,
and a. Now i, j, and a are hidden from the user inside of the Matlab class
lusol. I would like to keep these vectors around, because the user will later
call

>> fac.repcol(v,3)

to replace the 3rd column of A with v (there are other updates as well). This
would change the i, j, and a vectors.

Is this a terrible thing to do? Will I run into problems? Are there other
ways around this problem?

(My naive thought is that I will be ok as long as I do not pass user input to
the mex function)

Thanks so much for your help!
Nick

"Nick " <nwhsvc+matlab@gmail.com> wrote in message <he4l19$dd4$1@fred.mathworks.com>...
>
> My plan was to create a matlab class with private properties. The calls to the
> mex functions would change these properties. This would break the matlab
> convention of functions not changing their input variables.
>
> Is this a terrible thing to do? Will I run into problems? Are there other
> ways around this problem?
>
> (My naive thought is that I will be ok as long as I do not pass user input to
> the mex function)

It is not terrible, but as you have already read it is "against the rules." Neverthless, if memory is an issue then maybe this is the best choice. You will run into trouble if the variable is ever sharing memory with another variable. e.g.

>> format debug
>> A = [1 2 3]
A =
Structure address = 44b1190
m = 1
n = 3
pr = cef0760
pi = 0
     1 2 3
>> B = A
B =
Structure address = 44b81c8
m = 1
n = 3
pr = cef0760
pi = 0
     1 2 3

The pr value is the address of the double data. So here you can see that A is sharing data memory with B. If you were to pass variable A to a mex routine that changed the value "in-place", then B would also get altered ... probably not desired or intended. If you write your backend code so that nothing like this ever happens with the variables you intend to modify in-place (don't do anything that will cause them to share data with another variable), then you can get away with it.

James Tursa