Re: Kronecker products as objects?

[Jaroslav Hajek]

On Tue, Mar 23, 2010 at 9:02 PM, Søren Hauberg <address@hidden> wrote:
> Hi All
>
> I get the impression that Kronecker products are becoming more and more
> popular in Machine Learning research. However, people only seem to be
> using Kronecker products as part of their derivations, while the actual
> programs don't use them. I don't really like this, as the resulting code
> is often hard to follow.
>
> The reason why people don't use Kronecker products in their code is that
> the resulting matrices often are huge when you are working on real world
> problems. So, I'm thinking: why not just have Kronecker products as a
> special type of matrix, just like we have for diagonal matrices?
>
> The attached code is a simple m-file implementation of such a class
> ('kronprod'). It implements the following functions (besides trivial
> stuff like 'size', 'numel', 'display', ...):
>
>        ctranspose
>        transpose
>        uplus
>        uminus
>        rank
>        trace
>        det
>        mtimes
>        mldivide
>        mpower
>        inv
>        eig
>        svd
>
> This is just a prototype, but it seems to work quite well (it has no
> error checking, documentation or fancy stuff like that, though). As an
> example, I can do
>
>  A = rand (200, 300);
>  B = rand (400, 500);
>  v1 = rand (rows (A)*rows (B), 1);
>
>  tic, r1 = kronprod (A, B) \ v1; toc
>
> which gives me
>
>  Elapsed time is 0.601284 seconds.
>
> If I use the current 'kron' function
>
>  tic, r2 = kron (A, B) \ v1; toc
>
> I instead get
>
>  error: memory exhausted or requested size too large for range of
> Octave's index type -- trying to return to prompt
>
> In general, the code is quite simple as it is just an application of
> properties of Kronecker products.
>
> My question is then: is it worth the effort of trying to integrate this
> properly into Octave (which would require putting corresponding C++ code
> in 'liboctave') or should I just finish the class and stuff it in the
> 'linalg' package?
>
> Søren
>


Brilliant idea. I say commit this to linear-algebra for the time being.


-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz