[R] Embedding lists in matrices and matrices in lists
Michael Kogan
michael.kogan at gmx.net
Thu Aug 20 22:01:16 CEST 2009
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.kogan at 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
>>>
>>>
>
>
More information about the R-help
mailing list