Hm I still suppose that you do not need matrix as a top level object. If you are sure there is only one level of nesting, e.g. in each node of the list there is only one level of saved matrices, you can get summary information from str, length and/or summary.
lll<-list(a=1, b=2, c=list(a=1,b=2,c=3), d=list(a=1, b=1), e=list(a=5,b=3, c=4, d=7, e=8)) lapply(lll, length) $a [1] 1 $b [1] 1 $c [1] 3 $d [1] 2 $e [1] 5 sapply(lll, length) a b c d e 1 1 3 2 5 > summary(lll) Length Class Mode a 1 -none- numeric b 1 -none- numeric c 3 -none- list d 2 -none- list e 5 -none- list Michael Kogan <michael.ko...@gmx.net> napsal dne 20.08.2009 12:48:32: > Thanks, I was already told this solution by somebody (he just forgot to > add the mailing list as CC). Well, the purpose of the whole thing is to > get something like this: > http://home.att.net/~numericana/data/polycount.htm where the numbers in > the table cells give the number of matrices saved in the corresponding > cell. The program looks like this now: Do you really want the matrices "saved" in corresponding cell? If this 466224664031 is a number of items in one cell and if the item is only one number you would need >500 GB memory (hope I computed it correctly :-) to keep only this one cell in memory which I presume you do not have. If you want just store the number of existing variations which belong to this cell then you shall rethink your procedures. Regards Petr > http://paste.ubuntuusers.de/396117/ It even runs (though errors occur if > I add th process r into the main loop, but I'm still not done with it...). > > Petr PIKAL schrieb: > > Hi > > > > > > No. It is the problem of scoping. AFAIK functions create their own > > environment and everything what is assigned inside the function does not > > affect outside objects unless you use <<- assignment operator. > > > > i<-100 > > ff<-function(x) i<-x > > ff(10) > > i > > [1] 100 > > fff<-function(x) i<<-x > > fff(200) > > i > > [1] 200 > > > > However I would distract you from this practice. Personally I used such > > assignment only when I started with S/R about 10 years ago. > > > > Why do you want a database to be a matrix? It seems to be that list > > structure is in that case more flexible and there are *apply functions for > > manipulation with lists. E.g. structure lm(...) results in list and > > summary(lm(...)) is again a list with quite complicated structure. > > > > If I understand it correctly, during your computation you will have as a > > result matrices with arbitrary dimensions. > > > > I would make a list > > > > lll<-vector("list", 1) > > > > and in simple loop > > > > for (i in 1:n) { > > > > do any computation here together with sophisticated and complicated > > functions and assign results to your list > > > > lll[[1]] <- result of functions which itself can have quite complicated > > structure > > > > } > > > > If you want nested list just add another cycle and use > > > > lll[[i]][[j]] <-some other result. > > > > With choosing appropriate structure of your date you can save yourself > > much problems. > > Regards > > Petr > > ______________________________________________ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.