similar to: [bug] droplevels() also drop object attributes (comment…)

>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>> on Tue, 16 May 2017 11:01:23 +0200 writes: >>>>> Serge Bibauw <sbibauw at gmail.com> >>>>> on Mon, 15 May 2017 11:59:32 -0400 writes: >> Hi, >> Just reporting a small bug? not really a big deal, but I >> don?t think that is

* Be careful with "contrasts" attribute. If the number of levels is reduced, the original contrasts matrix is no longer valid. Example case: x <- factor(c("a", "a", "b", "b", "b"), levels = c("a", "b", "c")) contrasts(x) <- contr.treatment(levels(x), contrasts=FALSE)[, -2, drop=FALSE] droplevels(x) *

>>>>> Serge Bibauw <sbibauw at gmail.com> >>>>> on Mon, 15 May 2017 11:59:32 -0400 writes: > Hi, > Just reporting a small bug? not really a big deal, but I don?t think that is intended: droplevels()?also drops all object?s attributes. Yes. The help page for droplevels (or the simple definition of 'droplevels.factor') clearly

>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel at r-project.org> >>>>> on Fri, 2 Sep 2016 16:10:00 +0000 writes: > I am basically fine with the change. > How about using just the following? > if(!is.character(exclude)) > exclude <- as.vector(exclude, typeof(x)) # may result in NA > x <- as.character(x)

>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel at r-project.org> >>>>> on Sat, 27 Aug 2016 03:17:32 +0000 writes: > In R devel r71157, 'droplevels' documentation, in "Arguments" section, says this about argument 'exclude'. > passed to factor(); factor levels which should be excluded from the result even if

Hi, Just reporting a small bug? not really a big deal, but I don?t think that is intended: droplevels()?also drops all object?s attributes. Example: > > test <- c("hello", "something", "hi") > > test <- factor(test) > > comment(test) <- "this is a test" > > attr(test, "description") <- "this is another

I am basically fine with the change. How about using just the following? if(!is.character(exclude)) exclude <- as.vector(exclude, typeof(x)) # may result in NA x <- as.character(x) It looks simpler and is, more or less, equivalent. In factor.Rd, in description of argument 'exclude', "(when \code{x} is a \code{factor} already)" can be removed. A larger

In R devel r71124, if 'x' is a factor, droplevels(x) gives factor(x, exclude = NULL) . In R 3.3.1, it gives factor(x) . If a factor 'x' has NA and levels of 'x' doesn't contain NA, factor(x) gives the expected result for droplevels(x) , but factor(x, exclude = NULL) doesn't. As I said in https://stat.ethz.ch/pipermail/r-devel/2016-May/072796.html , factor(x,

In R devel r71157, 'droplevels' documentation, in "Arguments" section, says this about argument 'exclude'. passed to factor(); factor levels which should be excluded from the result even if present. Note that this was implicitly NA in R <= 3.3.1 which did drop NA levels even when present in x, contrary to the documentation. The current default is compatible with x[ ,

Dear all, Today I figured out that there is a neat function called droplevels, which, well, drops unused levels in a data frame. I tried the function with some of my data sets and it turned out that not only the unused levels were dropped but also the contrasts I set via "C". I had a look into the code, and this behaviour arises from the fact that droplevels uses simply factor to drop

>>>>> Suharto Anggono Suharto Anggono >>>>> on Thu, 30 May 2019 14:45:22 +0000 writes: >>>>> Suharto Anggono Suharto Anggono >>>>> on Thu, 30 May 2019 14:45:22 +0000 writes: > Here is a patch to function 'stopifnot' that adds 'evaluated' argument and makes 'exprs' argument in 'stopifnot'

>>>>> Suharto Anggono Suharto Anggono <suharto_anggono at yahoo.com> >>>>> on Mon, 26 Sep 2016 14:51:11 +0000 writes: > By "an argument named 'use.names' is included for concatenation", I meant something like this, that someone might try. >> c(as.Date("2016-01-01"), use.names=FALSE) > use.names >

>>>>> Suharto Anggono Suharto Anggono >>>>> on Tue, 5 Mar 2019 17:29:20 +0000 writes: > Another possible shortcut definition: > assert <- function(exprs) > do.call("stopifnot", list(exprs = substitute(exprs), local = parent.frame())) Thank you. I think this is mostly a matter of taste, but I liked your version using eval()

>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel at r-project.org> >>>>> on Thu, 18 May 2017 16:27:09 +0000 writes: >> From an example in >> http://www.uni-muenster.de/ZIV.BennoSueselbeck/s-html/helpfiles/nargs.html >> , number of arguments in '...' can be obtained by > (function(...)nargs())(...) .

>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel at r-project.org> >>>>> on Fri, 11 Aug 2017 17:11:06 +0000 writes: >>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel at r-project.org> >>>>> on Fri, 11 Aug 2017 17:11:06 +0000 writes: > See

I am trying once again. By just changing f <- match(xlevs[f], nlevs) to f <- match(xlevs, nlevs)[f] , function 'factor' in R devel could be made more consistent and back-compatible. Why not picking it? -------------------------------------------- On Sat, 25/11/17, Suharto Anggono Suharto Anggono <suharto_anggono at yahoo.com> wrote: Subject: Re: [Rd] Function

While you are fiddling with stopifnot(), please consider changing the form of the error thrown so that it includes the caller's call. The change would be from something like stop( <<the message>> ) to stop(simpleError( <<the message>>, sys.call(-1))) For the following code f <- function(x, y) { stopifnot(x > y) x - y } g <- function(x,

Removal of ans[nas] <- NA from the code of function 'ifelse' in R is not committed (yet). Why? -------------------------------------------- On Mon, 28/11/16, Martin Maechler <maechler at stat.math.ethz.ch> wrote: Subject: Re: [Rd] ifelse() woes ... can we agree on a ifelse2() ? Cc: R-devel at r-project.org, maechler at stat.math.ethz.ch Date: Monday, 28 November, 2016, 10:00

Examples similar to pretty(c(-1,1)*1e300, n = 1e9, min.n = 1) with smaller 'n': pretty(c(-1,1)*1e304, n = 1e5, min.n = 1) pretty(c(-1,1)*1e306, n = 1e3, min.n = 1) A report on 'pretty' when working with integers, similar to what led to change of 'seq' fuzz, is https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15137 -------------------------------------------- On Tue,

While you are editing that, you might change its name from 'stderr' to standardError (or standard_error, etc.) so as not to conflict with base::stderr(). Bill Dunlap TIBCO Software wdunlap tibco.com On Tue, Sep 13, 2016 at 8:55 AM, Martin Maechler <maechler at stat.math.ethz.ch > wrote: > >>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel at