is.numeric(factor(...)) {was: bug in sample (PR#305)}
Peter Dalgaard BSA
p.dalgaard@biostat.ku.dk
02 Nov 1999 11:15:54 +0100
Martin Maechler <maechler@stat.math.ethz.ch> writes:
> Before turning this into a new bug report (not connected to sample() at all):
> { factor() behavior redesigning must be done carefully... }
> Some detective work reveals
>
> R versions from 0.50 to 0.61.3 all give
>
> is.numeric(gl(3,5,15))
> |-> FALSE
>
> Since R version 0.62.1 (June 15, 1998),
> the above gives TRUE.
>
> The NEWS for 0.62[.1] has
>
> o All internal mechanisms to support factors and data.frames have
> been removed. These are now entirely supported by interpreted
> code! `is.unordered' has been eliminated. Thanks to John
> Chambers for allowing the distribution of his StatLib code.
>
> i.e., they change occurded when we dropped the internal factor type...
>
> --
>
> Yes, my gut feeling also says that the current behavior is wrong...
We did have some debate over it at some point. The interesting thing
is that Splus has:
> mode(factor(letters[1:3]))
[1] "numeric"
> is.numeric(factor(letters[1:3]))
[1] F
> x<-1:3
> class(x)<-"foo"
> is.numeric(x)
[1] T
> attr(x,"levels")<-3:1
> is.numeric(x)
[1] T
> class(x)<-"facto"
> is.numeric(x)
[1] T
> class(x)<-"factor"
> is.numeric(x)
[1] F
...which doesn't strike me as particularly logical. I believe that we
then decided not to be bug-compatible on this issue. What are the good
reasons to behave the Splus way?
--
O__ ---- Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._