On Fri, Dec 11, 2009 at 11:43 AM, William Dunlap <wdun...@tibco.com> wrote:
>> -----Original Message-----
>> From: r-help-boun...@r-project.org
>> [mailto:r-help-boun...@r-project.org] On Behalf Of Peng Yu
>> Sent: Friday, December 11, 2009 9:18 AM
>> To: r-h...@stat.math.ethz.ch
>> Subject: Re: [R] Why a list of NULL's are reduced to NULL?
>>
>> On Fri, Dec 11, 2009 at 11:01 AM, William Dunlap
>> <wdun...@tibco.com> wrote:
>> >> -----Original Message-----
>> >> From: r-help-boun...@r-project.org
>> >> [mailto:r-help-boun...@r-project.org] On Behalf Of Peng Yu
>> >> Sent: Friday, December 11, 2009 8:44 AM
>> >> To: r-h...@stat.math.ethz.ch
>> >> Subject: [R] Why a list of NULL's are reduced to NULL?
>> >>
>> >> The following examples are confusing to me. It is OK, to
>> assigned NULL
>> >> to one element in a list. The result is still a list.
>> However, a list
>> >> of NULL's are reduced to NULL. I don't understand how this
>> conversion
>> >> occurs. Could somebody let me know what is going on?
>> >
>> > The "simplification" algorithm for reformatting
>> > the output of apply and sapply is handy in the
>> > common case when you know that FUN will return
>> > the same sort of thing each time it it called.
>> > The algorithm is not very useful when FUN may return
>> > objects of various classes or lengths. sapply has
>> > a simplify=FALSE argument to avoid the simplification
>> > (so it acts like lapply) but apply doesn't.
>> >
>> > I suggest you either change your function to always
>> > return one class and length of object or use lapply()
>> > or sapply(simplify=FALSE,...) when you must use a function
>> > with variable output type. E.g., instead of
>> > apply(X, 1, function(row){f(row)})
>> > use
>> > lapply(seq_len(nrow(X)), function(rowIndex){f(X[rowIndex,])})
>> > or
>> > lapply(split(X, row(X)), function(row){f(row)})
>>
>> Change my function to always returning one class may not always be
>> possible as I may call a third party R package that is not made by me
>> and does this kind of wired things of trying to 'simplify'. And I may
>> not know all the cases where the third party R package 'simplify' the
>> results, which does not always return the same type. In this case, I
>> can not be sure the return type is always the same. How do you deal
>> with this problem?
>
> I don't understant your constraints. You say you cannot control
> what FUN returns and you cannot control whether apply or lapply
> is called. A reproducible set of examples would help.
A very common situation is that the users don't know all the possible
return types of 'some_third_party_function()'. If the users don't know
all the return types, he/she can not make sure the return type of
function(x) {...} be always the same. How do you deal with this case?
apply(X, 1, function(x) {
do something...
some_third_party_function(x)
}
)
>> >> > X=matrix(1:8, nr=4)
>> >> > apply(X,1, function(x) {if(x[[1]]==3){NULL}else{x[[1]]}})
>> >> [[1]]
>> >> [1] 1
>> >>
>> >> [[2]]
>> >> [1] 2
>> >>
>> >> [[3]]
>> >> NULL
>> >>
>> >> [[4]]
>> >> [1] 4
>> >>
>> >> > apply(X,1, function(x) {NULL})
>> >> NULL
>> >>
>> >> ______________________________________________
>> >> 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.
>> >>
>> >
>>
>> ______________________________________________
>> 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.
>>
>
______________________________________________
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.
