Submission of Matrix Kronecker Product for calc

Submission of Matrix Kronecker Product for calc

[Vincent Belaïche]

[-- Attachment #1: Type: text/plain, Size: 4514 bytes --]


Hello,

I am new to this list (I have just subscribed). I have just written a 
function for CALC that computes the Kronecker product of two matrices.

Maybe this can be useful to somebody else. I am not sure that this is 
the correct forum to submit that. Sorry if I bothered anybody.

BR,
     Vincent.

PS-1 : I think that this is perfectible to the following extent
   a) I use reverse instead of nreverse, which is more memory consuming. 
Not knowing the internals of Emacs I was unsure how the garbage 
collector free the memory if you nreverse a list not passing to nreverse 
the pointer of the first element (ie the point to the list itself). This 
is why I used reverse.

    b) I started from a template created by the "ZP" key for creating a 
permanent user function. The starting point was a simple multiplication. 
Then I modified the function to make a Kronecker product. However I 
don't know how to set the 'calc-user-defn property (what is there is 
still what there was originally after "ZP" keystroke in calc mode.
   

PS-2 : The function works on two dimensional matrices. I had no need to 
make it generic for n-dimensional (and maybe I was not proficient enough 
in Lisp to do it... ;-/ ).

PS-3 : Code below the --- line :
--------------------------------------------------
;;; Definition of Kronecker matrix product
(put 'calc-define 'calc-kron '(progn
 (defun calc-kron nil (interactive) (calc-wrapper (calc-enter-result 2 
"kron" (cons (quote calcFunc-kron) (calc-top-list-n 2)))))
 (put 'calc-kron 'calc-user-defn 't)
 (defun calcFunc-kron (x y)
   "Kronecker product of matrices x and y.
If x and y are not matrices then they are first embedded into matrices 
before computation.
After computation the result may be desembedded from matrix so that the 
Kronecker product
of two scalars is a scalar,
of one scalar and a vector or vice verse is a vector, or
of two vectors is a vector.
"
     ;; (matrix-backet-level x) returns 0 if x is not a matrix,
     ;;                                 1 if x is a vector that is not a 
matrix
     ;;                                 2 if x is a matrix
     (defun matrix-backet-level (x)
       (let ((returned-value 0) (x-sub x))
         (while
            (and (Math-vectorp x-sub) (< returned-value 2))
            (setq x-sub (elt x-sub 1))
            (setq returned-value (1+ returned-value))
         )
         returned-value
       ))
     ;; (matrix-embed x n) return x embeded in n level of brackets
     ;; (matrix-embed x 0) returns x
     ;; (matrix-embed x 1) returns (vec x)
     ;; (matrix-embed x 2) returns (vec (vec x))
     (defun matrix-embed (x n)
       (let ((returned-value x) (n-ctr 0))
         (while
            (< n-ctr n)
            (setq returned-value (list 'vec returned-value))
            (setq n-ctr (1+ n-ctr))
         )
         returned-value
       ))
     ;; evaluate level of bracketting of arguments x and y
     (let
         (
          (bl-x (matrix-backet-level x))
          (bl-y (matrix-backet-level y))
          prod-val
         )
       (let
           (
            (emb-x (matrix-embed x (- 2 bl-x)))
             (emb-y (matrix-embed y (- 2 bl-y)))
          prod-next-row
            )
         (dolist (x-row (reverse (cdr emb-x)) prod-val)
           (dolist (y-row (reverse (cdr emb-y)))
                 (setq prod-next-row nil)
                 (dolist (x-col (reverse (cdr x-row)) prod-next-row)
                   (dolist (y-col (reverse (cdr y-row)))
                     (setq prod-next-row (cons (math-mul x-col y-col) 
prod-next-row))
                     )
                   )
                 (setq prod-next-row (cons 'vec prod-next-row))
                 (setq prod-val (cons prod-next-row prod-val))
             )
           )
         (setq prod-val (cons 'vec prod-val))
         )
         (cond
          ((and (eq bl-x 0) (eq bl-y 0)) (elt (elt prod-val 1) 1))
          ((and (< bl-x 2) (< bl-y 2)) (elt prod-val 1))
          (t prod-val)
          )
       )
     )
 ;; I don't know how to set this property ... this statement does not 
implement the Kronecker product
 (put 'calcFunc-kron 'calc-user-defn '(* (var x var-x) (var y var-y)))
 (define-key calc-mode-map "zk" 'calc-kron)
))






_________________________________________________________________
Nouveau ! Créez votre profil Messenger !
http://home.services.spaces.live.com/

[-- Attachment #2: Type: text/html, Size: 4979 bytes --]

Re: Submission of Matrix Kronecker Product for calc

[Jay Belanger]

Vincent Belaïche <vincent.b.1@hotmail.fr> writes:
...
> Maybe this can be useful to somebody else.

Yes.  Would there be a problem if I tidied it up a bit?
Altogether, it would end up 20 lines or so; to be included in Calc,
we would need legal papers from you.

> (defun calcFunc-kron (x y)
> "Kronecker product of matrices x and y.

If x and y are not explicitly matrices, I take it they will be
implicitly considered matrices.  

> After computation the result may be desembedded from matrix so that
> the Kronecker product of two scalars is a scalar,
...

Why should the result not be a matrix?  Is it useful?

Jay

Re: Submission of Matrix Kronecker Product for calc

[Vincent Belaïche]

[-- Attachment #1: Type: text/plain, Size: 2376 bytes --]


Dear Jay,

1) No problem if you like to tidy up. Please do as you like.

2) For the legal paper, no problem either. Please send me the form and 
make me know whether I can fill it electronically, or if I need a postal 
real paper send.

3) Concerning whether the result should or should not be a matrix, I am 
not sure that this is 100% useful. My intent was not to add extra 
useless bracketing. However the counterpart of this is that if you use 
the calc-Funckron in Lisp you would may need in the sequel extra testing 
in order to know into what level of bracketing it has resulted. Maybe 
some extra optional argument telling whether to minimize bracketing or 
not would therefore be useful.

However, not being a Lisp expert I did not know how to make this on the 
Lisp function on the one hand, and have it compatible with Stack 
manipulation on the other hand (in case of Stack manipulation some "C-u 
+ digit" before calling function could serve telling whether bracketing 
is to be minimized or not).

In fact, for my own purpose (I wanted to computed some Walsh codes by 
"kron"-ing some 2x2 Hadamard matrices together) and having 
systematically matrices and not vectors was sufficient.

4) note that the function name "kron" has already some publicity as it 
is borrowed from Matlab and Scilab (a license-free equivalent made by 
INRIA and ENPC France). So I suggest to keep the same.

BR,
       Vincent.



Jay Belanger a écrit :
> Vincent Belaïche  writes:
> ...
>   
>> Maybe this can be useful to somebody else.
>>     
>
> Yes.  Would there be a problem if I tidied it up a bit?
> Altogether, it would end up 20 lines or so; to be included in Calc,
> we would need legal papers from you.
>
>   
>> (defun calcFunc-kron (x y)
>> "Kronecker product of matrices x and y.
>>     
>
> If x and y are not explicitly matrices, I take it they will be
> implicitly considered matrices.  
>
>   
>> After computation the result may be desembedded from matrix so that
>> the Kronecker product of two scalars is a scalar,
>>     
> ...
>
> Why should the result not be a matrix?  Is it useful?
>
> Jay
>
>
>   



_________________________________________________________________
Microsoft vous offre un logiciel pour classer, retoucher et partager vos photos !
http://www.windowslive.fr/galerie/

[-- Attachment #2: Type: text/html, Size: 2738 bytes --]

Re: Submission of Matrix Kronecker Product for calc

[Jay Belanger]

Vincent Belaïche <vincent.b.1@hotmail.fr> writes:
...
> 2) For the legal paper, no problem either.

Thanks.  I've sent you (off-list) a copy of request-disclaim.changes.

Jay

Re: Submission of Matrix Kronecker Product for calc

[David Kastrup]

Jay Belanger <jay.p.belanger@gmail.com> writes:

> Vincent Belaïche <vincent.b.1@hotmail.fr> writes:
> ...
>> 2) For the legal paper, no problem either.
>
> Thanks.  I've sent you (off-list) a copy of request-disclaim.changes.

Please use request-assign.future instead.  Disclaimed software does not
give the FSF the possibility to defend the code against assimilation
into non-free software.  A disclaimer is a last resort when assignments
can't be obtained, and probably should not be settled for by a
maintainer without explicitly checking with the FSF copyright clerk that
it can be accepted for a contribution.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Submission of Matrix Kronecker Product for calc

[Jay Belanger]

David Kastrup <dak@gnu.org> writes:
> Jay Belanger <jay.p.belanger@gmail.com> writes:
...
>> Thanks.  I've sent you (off-list) a copy of request-disclaim.changes.

I sent that because the Information For Maintainers of GNU Software, in
the section on Copyright papers, states:
   For medium to small changes, request a personal disclaimer 
   by sending per the file request-disclaim.changes.

> Please use request-assign.future instead.

Okay; I'll send a follow-up with that file.

Jay

Re: Submission of Matrix Kronecker Product for calc

[David Kastrup]

Jay Belanger <jay.p.belanger@gmail.com> writes:

> David Kastrup <dak@gnu.org> writes:
>> Jay Belanger <jay.p.belanger@gmail.com> writes:
> ...
>>> Thanks.  I've sent you (off-list) a copy of request-disclaim.changes.
>
> I sent that because the Information For Maintainers of GNU Software, in
> the section on Copyright papers, states:
>    For medium to small changes, request a personal disclaimer 
>    by sending per the file request-disclaim.changes.

Well, when one knows that no more contributions will ever follow up and
one can estimate the size to be small, it is a possibility.  But since
it is a hassle for all involved parties to ask again, an assignment is
usually the first recourse.  When this does not work out, there are
situations when a disclaimer will fit the bill.

>> Please use request-assign.future instead.
>
> Okay; I'll send a follow-up with that file.

Thanks,

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Submission of Matrix Kronecker Product for calc

[Richard Stallman]

    I sent that because the Information For Maintainers of GNU Software, in
    the section on Copyright papers, states:
       For medium to small changes, request a personal disclaimer 
       by sending per the file request-disclaim.changes.

What you did was correct.

Re: Submission of Matrix Kronecker Product for calc

[Richard Stallman]

For a medium-size contribution, a disclaimer is just fine.
It is only for large amounts of code that we prefer an assignment.

Also, if someone wants to keep contributing, the past-and-future
assignment has the advantage that it will cover future work.
But if someone doesn't expect to contribute more later,
thns advantage doesn't apply.

Re: Submission of Matrix Kronecker Product for calc

[Glenn Morris]

Richard Stallman wrote:

> For a medium-size contribution, a disclaimer is just fine.
> It is only for large amounts of code that we prefer an assignment.
>
> Also, if someone wants to keep contributing, the past-and-future
> assignment has the advantage that it will cover future work.
> But if someone doesn't expect to contribute more later,
> thns advantage doesn't apply.

Isn't there something to be said for: i) assuming that contributors
will want to continue contributing; and ii) trying to minimize the
number of pieces of paper people have to sign? I've always offered
assign-past-and-future for the whole of Emacs as a default option to
contributors, no matter how much they contribute initially. Should I
stop doing this? Is there some reason to actually _prefer_ a
disclaimer for smaller changes?

Re: Submission of Matrix Kronecker Product for calc

[Richard Stallman]

    Isn't there something to be said for: i) assuming that contributors
    will want to continue contributing; and ii) trying to minimize the
    number of pieces of paper people have to sign?

If someone thinks he may want to contribute more
then he might prefer to sign the future assignment.
The form for disclaimers mentions this option.

     I've always offered
    assign-past-and-future for the whole of Emacs as a default option to
    contributors, no matter how much they contribute initially. Should I
    stop doing this? Is there some reason to actually _prefer_ a
    disclaimer for smaller changes?

The disclaimer is not better for us, but it is smaller and simpler so
some contributors may prefer it.  That seems like a reason to suggest
both options, in the case of a medium contribution from someone who
may not want to contribute more.  request-disclaim.changes does that.