R help - Dec 2009 - 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?
> 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

> -----Original Message-----
> From: r-help-bounces at r-project.org 
> [mailto:r-help-bounces at r-project.org] On Behalf Of Peng Yu
> Sent: Friday, December 11, 2009 8:44 AM
> To: r-help at 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)})

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com  
> 
> > 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 at 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.
>

On Fri, Dec 11, 2009 at 2:50 PM, Don MacQueen <macq at llnl.gov>
wrote:
> I would study the third party function and learn all the types it can
> return.
>
> After all if you don't know what type it's going to return, how can
you
> possibly make *any* confident use of its output?
>
> Do you actually have this situation? A third part function that is so
poorly
> documented that you can't (1) predict the type of its return, and (2)
learn
> what its possible outputs are? Is this function from an R package
downloaded
> from CRAN?
Shouldn't there be a better solution at the language level? Perl has a
strict mode and a non strict mode. If it is always better to return
the same type, which is the case in other strong typed language, then
it might better that there is such a mode in R to enforce the same
return type.
> At 12:24 PM -0600 12/11/09, Peng Yu wrote:
>>
>> On Fri, Dec 11, 2009 at 12:05 PM, hadley wickham <h.wickham at
gmail.com>
>> wrote:
>>>>
>>>> ?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?
>>>
>>> ?It's not that common. ?It's pretty bad practice to return
different
>>> ?types from a function depending on the input parameters. ?In many
>>> ?languages this isn't even possible.
>>
>> I know this is a bad practice. But R doesn't have a way to forbid
such
>> thing happen. To program defensively, I have to test even uncommon
>> case, unless it is impossible. When you use a third party software in
>> your code, do you just ignore the possibility that a function could
>> return different types?
>>
>>> ?The solution is to write a function that takes the output from the
>>> ?first function, inspects it, and coerces all possibilities to the
same
>>> ?type.
>>
>> How do you figure out all the possibilities?
>
> You can look at its code. You can try the entire range of inputs you
> anticipate giving to it (you are in charge of the inputs, so you can do
> this). You can talk to the person who wrote it (if that person is not
> available, and the function is just some anonymous thing you got from
> somewhere, you probably shouldn't place any confidence it its
correctness).
>
>>
>> ______________________________________________
>> R-help at 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.
>
>
> --
> --------------------------------------
> Don MacQueen
> Environmental Protection Department
> Lawrence Livermore National Laboratory
> Livermore, CA, USA
> 925-423-1062
> --------------------------------------
>