Re: [R] Why a list of NULL's are reduced to NULL?
On Dec 11, 2009, at 4:56 PM, Peng Yu wrote: > On Fri, Dec 11, 2009 at 3:49 PM, Steve Lianoglou > wrote: >> >> On Dec 11, 2009, at 4:45 PM, Peng Yu wrote: >> >>> On Fri, Dec 11, 2009 at 2:37 PM, Charlie Sharpsteen >>> wrote: On Fri, Dec 11, 2009 at 10:24 AM, Peng Yu wrote: > > How do you figure out all the possibilities? Well, the "Value" section of the third party function's help page should outline the return types it produces. If it doesn't cover all cases, write a letter to the package maintainer. If you are using third party functions that are not packaged with help pages, then this sort of uncertainty is part of using unpublished code. >>> >>> A document may not document all the corner cases. Even if it is so, >>> you can never be sure unless all the possibilities are examined . >> >> No, you can be sure. Just look at the code of the function that is ill >> behaved. > > One purpose of packaging code is to shield the user from necessarily > knowing the details. This practice clear break this purpose. This is an age old problem that you'll find in every programming language: no matter how good a programming language is, people will find ways to write bad code in it. And, "this practice" is something that you can't avoid given the choices of (i) static vs. dynamic and (ii) strong vs. weak typing that R has taken. If you're interested in arguing the pros and cons of each, you can find endless debates about this elsewhere on the internet that you can contribute to. > I'm not > saying that I can not read the source code if it is really needed. But > relying on users to read the code in order to use the package is not a > good software engineering practice. So we can agree that a package that relies on the user to read its function code vs. having its implementation follow what is described in its documentation needs to be improved. You can do you part to help by emailing the author of the library to let them know about the corner case you found. >> As Don asked: are you actually experiencing this problem with a library on >> CRAN? > > Not the particular the 'NULL' problem. But the different return types > of many functions have already caused a lot of headache to me. That's unfortunate. Can you please let us know which ones have caused you trouble so we can help get the author's attention? Thanks, -steve -- Steve Lianoglou Graduate Student: Computational Systems Biology | Memorial Sloan-Kettering Cancer Center | Weill Medical College of Cornell University Contact Info: http://cbio.mskcc.org/~lianos/contact __ 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.
Re: [R] Why a list of NULL's are reduced to NULL?
On Dec 11, 2009, at 4:56 PM, Peng Yu wrote: On Fri, Dec 11, 2009 at 3:49 PM, Steve Lianoglou wrote: On Dec 11, 2009, at 4:45 PM, Peng Yu wrote: On Fri, Dec 11, 2009 at 2:37 PM, Charlie Sharpsteen wrote: On Fri, Dec 11, 2009 at 10:24 AM, Peng Yu wrote: How do you figure out all the possibilities? Well, the "Value" section of the third party function's help page should outline the return types it produces. If it doesn't cover all cases, write a letter to the package maintainer. If you are using third party functions that are not packaged with help pages, then this sort of uncertainty is part of using unpublished code. A document may not document all the corner cases. Even if it is so, you can never be sure unless all the possibilities are examined . No, you can be sure. Just look at the code of the function that is ill behaved. One purpose of packaging code is to shield the user from necessarily knowing the details. This practice clear break this purpose. I'm not saying that I can not read the source code if it is really needed. But relying on users to read the code in order to use the package is not a good software engineering practice. As Don asked: are you actually experiencing this problem with a library on CRAN? Not the particular the 'NULL' problem. But the different return types of many functions have already caused a lot of headache to me. I think you lost a lot of sympathy within this audience when you not only admitted that you did not read the help pages, but insisted that your failure to do so was somehow the responsibility of the authors for not have written it in exactly the format you preferred. -- David Winsemius, MD Heritage Laboratories West Hartford, CT __ 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.
Re: [R] Why a list of NULL's are reduced to NULL?
On Fri, Dec 11, 2009 at 3:49 PM, Steve Lianoglou wrote: > > On Dec 11, 2009, at 4:45 PM, Peng Yu wrote: > >> On Fri, Dec 11, 2009 at 2:37 PM, Charlie Sharpsteen >> wrote: >>> On Fri, Dec 11, 2009 at 10:24 AM, Peng Yu wrote: How do you figure out all the possibilities? >>> >>> Well, the "Value" section of the third party function's help page should >>> outline the return types it produces. If it doesn't cover all cases, write >>> a letter to the package maintainer. If you are using third party functions >>> that are not packaged with help pages, then this sort of uncertainty is part >>> of using unpublished code. >> >> A document may not document all the corner cases. Even if it is so, >> you can never be sure unless all the possibilities are examined . > > No, you can be sure. Just look at the code of the function that is ill > behaved. One purpose of packaging code is to shield the user from necessarily knowing the details. This practice clear break this purpose. I'm not saying that I can not read the source code if it is really needed. But relying on users to read the code in order to use the package is not a good software engineering practice. > As Don asked: are you actually experiencing this problem with a library on > CRAN? Not the particular the 'NULL' problem. But the different return types of many functions have already caused a lot of headache to me. __ 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.
Re: [R] Why a list of NULL's are reduced to NULL?
On Dec 11, 2009, at 4:45 PM, Peng Yu wrote: > On Fri, Dec 11, 2009 at 2:37 PM, Charlie Sharpsteen > wrote: >> On Fri, Dec 11, 2009 at 10:24 AM, Peng Yu wrote: >>> >>> How do you figure out all the possibilities? >> >> Well, the "Value" section of the third party function's help page should >> outline the return types it produces. If it doesn't cover all cases, write >> a letter to the package maintainer. If you are using third party functions >> that are not packaged with help pages, then this sort of uncertainty is part >> of using unpublished code. > > A document may not document all the corner cases. Even if it is so, > you can never be sure unless all the possibilities are examined . No, you can be sure. Just look at the code of the function that is ill behaved. As Don asked: are you actually experiencing this problem with a library on CRAN? -- Steve Lianoglou Graduate Student: Computational Systems Biology | Memorial Sloan-Kettering Cancer Center | Weill Medical College of Cornell University Contact Info: http://cbio.mskcc.org/~lianos/contact __ 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.
Re: [R] Why a list of NULL's are reduced to NULL?
On Fri, Dec 11, 2009 at 2:37 PM, Charlie Sharpsteen wrote: > On Fri, Dec 11, 2009 at 10:24 AM, Peng Yu wrote: >> >> How do you figure out all the possibilities? > > Well, the "Value" section of the third party function's help page should > outline the return types it produces. If it doesn't cover all cases, write > a letter to the package maintainer. If you are using third party functions > that are not packaged with help pages, then this sort of uncertainty is part > of using unpublished code. A document may not document all the corner cases. Even if it is so, you can never be sure unless all the possibilities are examined . __ 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.
Re: [R] Why a list of NULL's are reduced to NULL?
On Fri, Dec 11, 2009 at 2:50 PM, Don MacQueen 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
>> 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@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
> --
>
__
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.
Re: [R] Why a list of NULL's are reduced to NULL?
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?
-Don
At 12:24 PM -0600 12/11/09, Peng Yu wrote:
On Fri, Dec 11, 2009 at 12:05 PM, hadley wickham 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@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
__
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.
Re: [R] Why a list of NULL's are reduced to NULL?
On Fri, Dec 11, 2009 at 10:24 AM, Peng Yu wrote: > > How do you figure out all the possibilities? Well, the "Value" section of the third party function's help page should outline the return types it produces. If it doesn't cover all cases, write a letter to the package maintainer. If you are using third party functions that are not packaged with help pages, then this sort of uncertainty is part of using unpublished code. -Charlie [[alternative HTML version deleted]] __ 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.
Re: [R] Why a list of NULL's are reduced to NULL?
On Fri, Dec 11, 2009 at 12:05 PM, hadley wickham 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?
__
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.
Re: [R] Why a list of NULL's are reduced to NULL?
> 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.
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.
Hadley
--
http://had.co.nz/
__
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.
Re: [R] Why a list of NULL's are reduced to NULL?
On Fri, Dec 11, 2009 at 11:43 AM, William Dunlap 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
>> 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.
Re: [R] Why a list of NULL's are reduced to NULL?
> -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
> 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.
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@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.
Re: [R] Why a list of NULL's are reduced to NULL?
On Fri, Dec 11, 2009 at 11:01 AM, William Dunlap 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?
>> > 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.
Re: [R] Why a list of NULL's are reduced to NULL?
> -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)})
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@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.
