@PatrickT Using your original timing example, I get this (Windows XP, Core2 Duo, Maple 14):

restart:
A := Matrix(5,5,(i,j) -> a||i||j):
B := Matrix(5,5,(i,j) -> b||i||j):
t := time():
for i from 1 to 1000 do
   LinearAlgebra:-KroneckerProduct(A,B);    
end do:
time() - t;
                             1.313

restart:
KPKP:=proc(A,B)
local m,n,p,q,i,j,res,CC,
      offi_l,offi_u,offj_u,offj_l;
  m,n:=op(1,A);
  p,q:=op(1,B);
  res:=Matrix(m*p,n*q);
  CC:=Matrix(p,q);
  for i from 1 to m do
    offi_l,offi_u:=p*(i-1)+1,p*i;
    for j from 1 to n do
      offj_l,offj_u:=q*(j-1)+1,q*j;
      ArrayTools:-Copy(p*q,B,0,1,CC,0,1);
      map2['inplace'](`*`,A[i,j],CC);
      res[offi_l..offi_u,offj_l..offj_u]:=CC;
    end do;
  end do;
  res;
end proc:
A := Matrix(5,5,(i,j) -> a||i||j):
B := Matrix(5,5,(i,j) -> b||i||j):
t := time():
for i from 1 to 1000 do
   KPKP(A,B);    
end do:
time() - t;
                             0.860

Thanks, Joe.

Yes, sometimes ArrayTools:-Alias is preferred. But sometimes it is not. One problematic case in when the rtable (Vector, Matrix, Array) has an indexing function or non-rectangular storage (eg. sparse) -- which Alias doesn't support.

Another problem case is where the `f` acts in-place. That's not so relevent here but may pertain more to the parent post from which this post was branched.

Another problem case may be when the `f` passes the object externally and is not designed to somehow figure out and communicate externally any offset of the Aliased object (w.r.t the original data object like V).

And then there whole range of related issues when the original data object is a Matrix. Then the Alias offset may be a problem (possible worked around in other ways). Of course in that case Copying, if done in many function calls, may be more expensive.

The theme is really how to avoid rtable creation & collection, if it can be avoided. Absolutely, there are other ways and means for that. It well be that different situations' particulars make some ways of approaching the memory use issue better than others. No size fits all!

Dave Linder
Mathematical Software, Maplesoft

Right! `KP` is what LinearAlgebra:-KroneckerProduct does for the exact case. So it's hardly surprising that it too is much slower than the full LinearAlgebra:-_Main:-KroneckerProduct routine when dealing with float Matrices. You haven't done anything 'wrong". This just illustrates what differences there are in approach.

Consider: LinearAlgebra:-KroneckerProduct calls LinearAlgebra:-LA_Main:-KroneckerProduct. And that latter routine splits according to the case of exact versus float. If the data is exact, it uses code just like `KP`. If the data is float then it is free to convert the data to float[8], construct a much lighter float[8] result container, and then do the entire computation in external compiled C.

All the posted versions at top are much slower than LinearAlgebra:-KroneckerProduct for float Matrices. And they consume much more memory since -- unlike LinearAlgebra:-KroneckerProduct -- they havn't been designed to return a float[8] matrix as the result. They use fundamentally different approaches from what LinearAlgebra:-KroneckerProduct does in the float case. It doesn't make much sense to compare them in that way -- except of course for the purpose of seeing how different they behave.

It might make sense to compare LinearAlgebra:-KroneckerProduct to new versions of the posted codes, redesigned for floats.

Or it might make sense to to compare the posted routine `KP` to the others originally posted (ideally for exact examples), since that looks like the exact case code inside LinearAlgebra:-KroneckerProduct. I guess it might be kinda sorta interesting to compare `KP` against the others originally posted on large float examples, just as an experiment (while ackowledging that was not the designed purpose, but at least it's a "fair" comparison).

It makes sense to compare `KP` against the posted versions. Or to compare LinearAlgebra:-KroneckerProduct against the posted versions for exact examples (large of small). It doesn't make a lot of sense to compare LinearAlgebra:-KroneckerProduct against the posted codes (or `KP`), for float examples.

The `KPKP` routine posted ran ok for me, without accessing out of range. Is it actually fastest on the original small exact symbolic test example?

Dave Linder
Mathematical Software, Maplesoft

@Axel Vogt Thanks, Axel. I'll enter it now.

I hope that Mapleprimes encourages submission of SCRs, in an ongoing and visible way.

So far, I recall only seeing a single post to the new Mapleprimes with 8 thumbs up votes, and only a couple of posts with 7 up votes. There are relatively few posts with more than 4 up votes, so far. On that scale, this post's 7 thumbs up and 0 down votes indicates that the active voting community is strongly in favour.

Dave Linder

@John Fredsted Please, repeated construction of lists like this is a bad thing to do, especially when there are alternatives which are just as easy. It's a classic mistake. It's using the wrong data structure for the job.

@John Fredsted Please, repeated construction of lists like this is a bad thing to do, especially when there are alternatives which are just as easy. It's a classic mistake. It's using the wrong data structure for the job.

The version of MKL used in Maple 14 was updated, for both 64bit and 32bit Maple on MS-Windows. See the first section (when expanded) of the What's New efficiency help page.

Dave Linder
Mathematical Software, Maplesoft

@herclau, see also a little more on the benefit, from an original post (before it got implemented within SingularValues).

Also, you are doing floating-point calculations, so SmithForm is not really appropriate. The SVD is what you want here.

@all, John's cylon icon was made using an image approximation based on SVD computations.

Dave Linder
Mathematical Software, Maplesoft

@herclau, see also a little more on the benefit, from an original post (before it got implemented within SingularValues).

Also, you are doing floating-point calculations, so SmithForm is not really appropriate. The SVD is what you want here.

@all, John's cylon icon was made using an image approximation based on SVD computations.

Dave Linder
Mathematical Software, Maplesoft

I will record these details (SCR), including the other erroneous result of 0.

Dave Linder
Mathematical Software, Maplesoft

I am reminded to update these two help pages (1, 2).

Dave Linder
Mathematical Software, Maplesoft

I am reminded to update these two help pages (1, 2).

Dave Linder
Mathematical Software, Maplesoft

I submitted an SCR (bug report) for this topic this afternoon, including the details.

Best regards,
Dave Linder
Mathematical Software, Maplesoft