|
From: Raymond T. <to...@rt...> - 2002-11-05 23:03:27
|
>>>>> "rif" == rif <ri...@MI...> writes:
[slow matrix-ref example snipped]
rif> This implies to me that if I need to do a LOT of manipulating the
rif> entries of vectors, I'm better off moving them to an array, doing the
Can you describe what kinds of manipulations you want to do?
rif> manipulation there, then moving them back into matrix form to do
rif> matrix operations. Is this essentially correct, or am I missing
rif> something? I guess the alternate approach is to extend matlisp myself
Yes, this is correct. matrix-ref hides the implementation details.
If we ever do packed storage, matrix-ref would hide that fact too.
The intent, however, is that, if you can, use the LAPACK routines to
do the manipulations, as you would in Matlab.
rif> to provide "unsafe" accessors that assume more --- I'm willing to tell
rif> it I'm using a real matrix to avoid the generic function dispatch, and
rif> I'm willing to just run an aref directly on the store component
rif> (although the store isn't currently exported by matlisp).
We can make store exported without any problems. :-) Store is very
unlikely to change since it's used everywhere to get at the underlying
array.
If you're operating on all of the elements of a vector, you may want
to look at matrix-map. It will run your selected function over each
element of the vector and uses store and aref to do it, so it's about
as efficient as as doing it by hand.
Ray
|