[Rd] using a factor as col argument in plot:
Dear R core team Using the following code produces an empty plot (similar to col = NA): > plot(1:9, col = factor(rep(1:3,3), labels = c("red", "blue", "black"))) My question: Shouldn't one get at least a warning (or an error) if one tries to use a factor as col argument? Thanks for an answer. Regards, Christoph Buser ------ Christoph Buser <[EMAIL PROTECTED]> Seminar fuer Statistik, LEO C13 ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND phone: x-41-44-632-4673 fax: 632-1228 http://stat.ethz.ch/~buser/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using a factor as col argument in plot:
Dear Prof. Ripley Thank you for your reply and for changing the function in R-devel. I've intended to ask my question in way 2) but I probably have chosen a ambiguous formulation. :-) Regards Christoph Buser -- Christoph Buser <[EMAIL PROTECTED]> Seminar fuer Statistik, LEO C13 ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND phone: x-41-44-632-4673 fax: 632-1228 http://stat.ethz.ch/~buser/ -- Prof Brian Ripley writes: > On Fri, 18 Nov 2005, Christoph Buser wrote: > > > Dear R core team > > and R-devel-listers. > > > Using the following code produces an empty plot (similar > > to col = NA): > > > >> plot(1:9, col = factor(rep(1:3,3), labels = c("red", "blue", "black"))) > > > > > > My question: Shouldn't one get at least a warning (or an error) > > if one tries to use a factor as col argument? > > > > Thanks for an answer. > > I can read that two ways > > 1) No, it should not give a warning, as it is programmed to take all > invalid values as 0. > > 2) Is the way it is programmed sensible (yes) or desirable (no)? > > The actual code is > > /* Convert a sexp element to an R color desc */ > /* We Assume that Checks Have Been Done */ > > unsigned int RGBpar(SEXP x, int i) > { > int indx; > if(isString(x)) { > return str2col(CHAR(STRING_ELT(x, i))); > } > else if(isInteger(x) || isLogical(x)) { > if(INTEGER(x)[i] == NA_INTEGER) > /* > * Paul 01/07/04 > * Used to be set to NA_INTEGER (see comment in name2col). > */ > return R_TRANWHITE; > indx = INTEGER(x)[i] - 1; > if(indx < 0) return Rf_dpptr(CurrentDevice())->bg; > else return R_ColorTable[indx % R_ColorTableSize]; > } > else if(isReal(x)) { > if(!R_FINITE(REAL(x)[i])) > /* > * Paul 01/07/04 > * Used to be set to NA_INTEGER (see comment in name2col). > */ > return R_TRANWHITE; > indx = REAL(x)[i] - 1; > if(indx < 0) return Rf_dpptr(CurrentDevice())->bg; > else return R_ColorTable[indx % R_ColorTableSize]; > } > return 0; /* should not occur */ > } > > but I could see no checks of type in any of the calling functions. Adding > a warning would be a good idea. > > > -- > Brian D. Ripley, [EMAIL PROTECTED] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S4: setGeneric() and setMethod() with changed argument order
Dear R devel team Using S4 classes in R I found a possible source of mistakes caused by an inattentive user. If one uses another order of the arguments for a function in the setGeneric() as in the setMethod() call, one can get undesired side effects without any warning. Would it be desirable to include a warning for such cases? Thank you for a statement. R code: ## set generic function "test1" with 3 arguments setGeneric("test1", function(object, printit = TRUE, name = "tmp") standardGeneric("test1")) ## Set method for test1 and class "numeric", but change the order od the 2nd ## and 3rd arguments -> No warning, everything works well? setMethod("test1", signature(object = "numeric"), function(object, name = "tmp", printit = TRUE) { match.call() }) ## .local is generated with the order from setGeneric(), but is called ## afterwards with the wrong order from setMethod() which can cause an error ## (if you are lucky) or strange results. selectMethod("test1", signature = signature(object = "numeric")) > Method Definition: > > function (object, printit = TRUE, name = "tmp") > { > .local <- function (object, name = "tmp", printit = TRUE) > { > match.call() > } > .local(object, printit, name) > } > > Signatures: > object > target "numeric" > defined "numeric" > ## Shows that for the argument "name" printit is used. For the argument ## "printit" name is used test1(pi) > .local(object = object, name = printit, printit = name) Best regards, Christoph Buser -- Christoph Buser <[EMAIL PROTECTED]> Seminar fuer Statistik, LEO C13 ETH Zurich 8092 Zurich SWITZERLAND phone: x-41-44-632-4673 fax: 632-1228 http://stat.ethz.ch/~buser/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] apply: new behaviour for factors in R-2.4.0
Dear R-core There is a different output for the apply function due to the change of unlist as mentioned in the R news. Newly, applying as.factor() (or factor()) in str(dat <- data.frame(x = 1:10, f1 = gl(2,5,labels = c("A", "B" (d1 <- apply(dat,2,as.factor)) newly returns a character matrix while in R-2.3.1 the same command resulted in an integer matrix that was consistent (up to the ordering of the factor levels) with data.matrix(). The change is caused by the change of unlist() that, used for a list of factors, newly returns a single factor instead of an integer. I am happy with this change, but: Is it desirable to change apply so that it does not return a character matrix in the example above or include a warning for such a case? Thank you very much for an answer. Regards, Christoph Buser ------ Christoph Buser <[EMAIL PROTECTED]> Seminar fuer Statistik, LEO C13 ETH Zurich 8092 Zurich SWITZERLAND phone: x-41-44-632-4673 fax: 632-1228 http://stat.ethz.ch/~buser/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] apply: new behaviour for factors in R-2.4.0
Dear Brian Thank you for your answer and the comment you included on the apply() help page. 1) You are correct. My data.frame is coerced into a matrix in apply() 2) I agree that the new version of unlist() is better and works correctly and that in array() (due to as.vector()) the factor "ans" is coerced into a character matrix. Nevertheless I disagree that this is "feature freeze" with R version 2.3.1: Since in R-2.3.1, unlist() on a list of factors returned an integer vector, the result of apply was an integer matrix and not a character matrix. Therefore my question is if it would be desirable to return an integer matrix by changing apply. One could include additional code to handle the case if the output "should" be a factor matrix and coerce into an integer matrix. Then the outcome would be consistent with R-2.3.1 without changing something in unlist() or array(). But in the end I am not sure if an integer matrix is better than a character matrix or a factor matrix. I am not sure what output is best if one uses as.factor in apply. Regards, Christoph ------ Christoph Buser <[EMAIL PROTECTED]> Seminar fuer Statistik, LEO C13 ETH Zurich 8092 Zurich SWITZERLAND phone: x-41-44-632-4673 fax: 632-1228 http://stat.ethz.ch/~buser/ -- Prof Brian Ripley writes: > Christoph, > > This is more complicated than your analysis. > > 1) apply takes a matrix as an argument, not a data frame, and so first > coerced 'dat' to a character matrix. > > 2) unlist is working quite correctly. The issue is array(), which > contains as.vector(data). Thus although the result could be a factor > matrix, as.vector is coercing it to a character matrix. It might be > desirable to return a factor matrix, but we are not going to do that in > feature freeze (if ever) and I really don't think it would be what you > wanted. > > Perhaps the help page should contain an explicit statement that the result > will be coerced to a basic vector type by as.vector(). > > On Mon, 25 Sep 2006, Christoph Buser wrote: > > > Dear R-core > > > > There is a different output for the apply function due to the > > change of unlist as mentioned in the R news. > > > > Newly, applying as.factor() (or factor()) in > > > > str(dat <- data.frame(x = 1:10, f1 = gl(2,5,labels = c("A", "B" > > (d1 <- apply(dat,2,as.factor)) > > > > newly returns a character matrix while in R-2.3.1 the same > > command resulted in an integer matrix that was consistent (up to > > the ordering of the factor levels) with data.matrix(). > > That's coincidence -- try x=11:20. > > > The change is caused by the change of unlist() that, used for a > > list of factors, newly returns a single factor instead of an > > integer. I am happy with this change, but: > > > > Is it desirable to change apply so that it does not return a > > character matrix in the example above or include a warning for > > such a case? > > > > Thank you very much for an answer. > > > > Regards, > > > > Christoph Buser > > > > -- > > Christoph Buser <[EMAIL PROTECTED]> > > Seminar fuer Statistik, LEO C13 > > ETH Zurich 8092 Zurich SWITZERLAND > > phone: x-41-44-632-4673fax: 632-1228 > > http://stat.ethz.ch/~buser/ > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Brian D. Ripley, [EMAIL PROTECTED] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel