Re: [Matlisp-devel] [Matlisp-commit] [matlisp-git]matlisp branch matlisp-cffi updated. 2012-02-23-57-g6173362

[Akshay S. <aks...@gm...>]

On 03/18/2012 11:15 PM, Raymond Toy wrote:
> On 3/17/12 4:09 AM, Akshay Srinivasan wrote:
> 
> -matlisp-commit
> +matlisp-devel
>> ;;Create a 4x4 matrix with random entries
>> (defvar d (make-complex-matrix 4 4))
>>
>> (dotimes (i 4)
>>   (dotimes (j 4)
>>    (setf (matrix-ref-2d d i j)
>>          (complex-coerce (complex (cl:random 10) (cl:random 10))))))
> There's a rand() function, but it currently doesn't work because
> :row-stride is unbound.
> 
> Is there a reason why these are unbound?   Isn't there some suitable
> default for this, assuming we're creating a regular full matrix?
The defaults for :row-stride and :col-stride should be ((ncols mat), 1)
for row-major and (1, (nrows mat)) for col-major. I can probably add
this into :before initialize-instance method, but I don't think that's a
good thing.

The store index is now given by:
head + row-stride * i + col-stride * j

> Can we also fix the issue in mtimes and the autoswap thing?  I'm not
> exactly sure what you're trying to do, but if you explain it to me, I
> can probably help with that.
Hmm, I'm not sure what it's doing either.
I haven't touched mtimes yet, so its very likely the same version which
is in master, the *1x1*-.. is now unbound, which will probably lead to
errors.

> 
>> ;;Submatrix of d starting at (1, 1) or size (2, 2)
>> (defvar e (sub! d 1 1 2 2))
> We should pick a better name than sub!, like maybe sub-matrix!.  And
> what does the ! mean here?  The intention for "!" is to mean a
> destructive operation so does sub! destructively modify d to make a
> submatrix?  And what would that actually mean?  If it's not destructive,
> then don't use "!".
> 
Yes, it is a bad naming convention. Can we pick some other character to
indicate that the store is shared ? The "!" was meant to indicate that
the store is essentially the same, but this contradicts with the usual
Lisp convention.

> It seems that e and d now both refer to the same storage.  So if I
> modify e, d will magically change?  That's expected, but once e is
> created, it becomes very easy to lose track of the fact that it is a
> submatrix of d, especially at the repl.  I think we need to make the
> relationship more explicit.  Maybe create a new class that is a subclass
> of matrix (or whatever) that adds a slot that holds a reference to the
> matrix.  Kind of like how in lisp you can have displaced arrays, and you
> can tell it's displaced and can chase down all the way to the final,
> non-displaced array if you want to.
That sounds reasonable, shouldn't be too hard to do.

> 
> But don't get me wrong.  Real submatrices are really, really cool!
> 
> BTW, can you merge the master branch to the matlisp-cffi branch?  There
> are a few changes that I need to build correctly.  I tried myself, but
> there's a conflict which I'm not confident in resolving on my own.
Yes this is done now. I didn't get any conflicts though ?

Akshay