Matt J

@Jens:
Incidentally, if you are now happy with the reimplementation I've made of the DISPLAY method, I would appreciate it if you would change your rating. One star out of five is, in any case, a harsh rating just because you don't like 1 out of the 92 methods offered by the class.

@Jens: The reason I don't store my own tables is because then I couldn't piggy back on the fast sparse arithmetic routines of MATLAB's underlying 2D sparse class. I would have to implement my own.

In any case, the problem with displaying that you mention is probably not strictly related to data storage. It is related to the fact that the ndSparse DISPLAY method mimics the display method for full arrays and tries to print all "sheets" of the form A(:,:,i,j,k,...) to the screen. Since you have 37^5 sheets, naturally this is going to take some time to disaply to the screen.

Upon reflection, I admit that a sparser display would be more appropriate for an ndSparse class. For example, I could modify the DISPLAY method so that it only displays non-zero sheets.

On the other hand, as a designer, I can't really anticipate how every end-user would like their data displayed. Would a display of 2D sheets
A(:,:,i,j,k,...) offer meaningful information to someone working in 7-dimensional space, like yourself, even if I trimmed it down to the non-zero ones? And would every end-user prefer this?

Also, if you only want to display the non-zero data, why not use FIND? Or create your own wrapper for FIND which displays the data the way you want?

Hi Sandro,

I'm not having any such difficult in R2011a, so perhaps you need to upgrade. Here is the test that I ran, and no errors resulted

>> [a,b,ae,be]=vert2lcon(eye(20));
>> V=lcon2vert(a,b,ae,be);
>> norm(V'*V-eye(20))

ans =

  5.7516e-015

@Jens:
You talked me into it. I've now updated the distribution so that DISPLAY will print only those A(:,:,i,j,k,...) containing non-zero data.

For displaying purposes, at least, this should solve your problem. Mimicing the data you described, I'm now able to generate the following 37x37x37x37x37x37x37 data set on a 64-bit platform and get a reasonably instantaneous display:

 A=ndSparse.sprand(37*ones(1,7),400/37^7)

However, I am vaguely concerned that you are pushing the limits of the class by having such a large array volume, even on a 64-bit platform. The class wasn't designed to handle arbitrarily large numel(A), just as ordinary MATLAB 2D sparse matrices were not.

I now clarify this a bit more in the description section of the FEX page.

Hey Matt

Nice idea, but bad implementation. I am working with a parameter study and data is extremely sparse, dimensions are 37x37x37x37x37x37x37, but I have less than 400 non-zero elements. The display function takes more than 10 hours to execute.

Why not simple store tubles and use an intelligent search?