[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
