"The documentation aims to be accurate, not necessarily clear." !!!
I hope that is not the case! Accurate documentation that is confusing is not very useful. I understand that it is challenging to write docs that are both clear and accurate; but I hope that is always the goal. Cheers, Bert Bert Gunter "The trouble with having an open mind is that people keep coming along and sticking things into it." -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) On Mon, Apr 11, 2016 at 6:09 PM, Duncan Murdoch <murdoch.dun...@gmail.com> wrote: > On 11/04/2016 8:25 PM, Paulson, Ariel wrote: >> >> Hi Jeff, >> >> >> We are splitting hairs because R is splitting hairs, and causing us >> problems. Integer and numeric are different R classes with different >> properties, mathematical relationships notwithstanding. For instance, the >> counterintuitive result: > > > The issue here is that R has grown. The as() function is newer than the > as.numeric() function, it's part of the methods package. It is a much more > complicated thing, and there are cases where they differ. > > In this case, the problem is that is(1L, "numeric") evaluates to TRUE, and > nobody has written a coerce method that specifically converts "integer" to > "numeric". So the as() function defaults to doing nothing. > It takes a while to do nothing, approximately 360 times longer than > as.numeric() takes to actually do the conversion: > >> microbenchmark(as.numeric(1L), as(1L, "numeric")) > Unit: nanoseconds > expr min lq mean median uq max neval > as.numeric(1L) 133 210 516.92 273.5 409.5 9444 100 > as(1L, "numeric") 51464 64501 119294.31 99768.5 138321.0 1313669 100 > > R performance is not always simple and easy to predict, but I think anyone > who had experience with R would never use as(x, "numeric"). So this just > isn't a problem worth fixing. > > Now, you might object that the documentation claims they are equivalent, but > it certainly doesn't. The documentation aims to be accurate, not > necessarily clear. > > Duncan Murdoch > > >> >>> identical(as.integer(1), as.numeric(1)) >> >> [1] FALSE >> >> >> Unfortunately the reply-to chain doesn't extend far enough -- here is the >> original problem: >> >> >>> sapply(1, identical, 1) >> >> [1] TRUE >> >>> sapply(1:2, identical, 1) >> >> [1] FALSE FALSE >> >>> sapply(1:2, function(i) identical(as.numeric(i),1) ) >> >> [1] TRUE FALSE >> >>> sapply(1:2, function(i) identical(as(i,"numeric"),1) ) >> >> [1] FALSE FALSE >> >> These are the results of R's hair-splitting! > > > >> >> Ariel >> >> ________________________________ >> From: Jeff Newmiller <jdnew...@dcn.davis.ca.us> >> Sent: Monday, April 11, 2016 6:49 PM >> To: Bert Gunter; Paulson, Ariel >> Cc: Rolf Turner; r-help@r-project.org >> Subject: Re: [R] [FORGED] Re: identical() versus sapply() >> >> Hypothesis regarding the thought process: integer is a perfect subset of >> numeric, so why split hairs? >> -- >> Sent from my phone. Please excuse my brevity. >> >> On April 11, 2016 12:36:56 PM PDT, Bert Gunter <bgunter.4...@gmail.com> >> wrote: >> >> Indeed! >> >> Slightly simplified to emphasize your point: >> >> class(as(1:2,"numeric")) >> [1] "integer" >> >> class(as.numeric(1:2)) >> [1] "numeric" >> >> whereas in ?as it says: >> >> "Methods are pre-defined for coercing any object to one of the basic >> datatypes. For example, as(x, "numeric") uses the existing as.numeric >> function. " >> >> I suspect this is related to my ignorance of S4 classes (i.e. as() ) >> and how they relate to S3 classes, but I certainly don't get it >> either. >> >> Cheers, >> Bert >> >> >> >> Bert Gunter >> >> "The trouble with having an open mind is that people keep coming along >> and sticking things >> into it." >> -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) >> >> >> On Mon, Apr 11, 2016 at 9:30 AM, Paulson, Ariel <a...@stowers.org> wrote: >> Ok, I see the difference between 1 and 1:2, I'll just leave it as one of >> those "only in R" things. >> >> But it seems then, that as.numeric() should guarantee a FALSE outcome, >> yet it does not. >> >> To build on what Rolf pointed out, I would really love for someone to >> explain this one: >> >> str(1) >> num 1 >> >> str(1:2) >> int [1:2] 1 2 >> >> str(as.numeric(1:2)) >> num [1:2] 1 2 >> >> str(as(1:2,"numeric")) >> int [1:2] 1 2 >> >> Which doubly makes no sense. 1) Either the class is "numeric" or it >> isn't; I did not call as.integer() here. 2) method of recasting should not >> affect final class. >> >> Thanks, >> Ariel >> >> >> -----Original Message----- >> From: Rolf Turner [mailto:r.tur...@auckland.ac.nz] >> Sent: Saturday, April 09, 2016 5:27 AM >> To: Jeff Newmiller >> Cc: Paulson, Ariel; 'r-help@r-project.org' >> Subject: Re: [FORGED] Re: [R] identical() versus sapply() >> >> On 09/04/16 16:24, Jeff Newmiller wrote: >> I highly >> recommend making friends with the str function. Try >> >> str( 1 ) >> str( 1:2 ) >> >> Interesting. But to me counter-intuitive. Since R makes no distinction >> between scalars and vectors of length 1 (or more accurately I think, since >> in R there is *no such thing as a scalar*, only a vector of length >> 1) I don't see why "1" should be treated in a manner that is >> categorically different from the way in which "1:2" is treated. >> >> Can you, or someone else with deep insight into R and its rationale, >> explain the basis for this difference in treatment? >> >> for the clue you need, and then >> >> sapply( 1:2, identical, 1L ) >> >> cheers, >> >> Rolf >> >> -- >> Technical Editor ANZJS >> Department of Statistics >> University of Auckland >> Phone: +64-9-373-7599 ext. 88276 >> >> ________________________________ >> >> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see >> 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. >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see >> 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 -- To UNSUBSCRIBE and more, see 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.
