In fact there should be just one level of nesting but the top level
object must be a matrix, not a list, since the matrices that should be
embedded in it must be grouped after their nrow _and_ ncol - thus the
container object must be two-dimensional, a matrix. The only question is
how to get rid of the "list of lists" level between the database and the
matrices - if I remove the [[1]] everywhere in the code I get an error.
But since it does work with this intermediate "list of lists" level, I
prefer not to mess around in the code until everything else is done.
Petr PIKAL schrieb:
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.
