similar to: RFC: tapply(*, ..., init.value = NA)

Displaying 20 results from an estimated 10000 matches similar to: "RFC: tapply(*, ..., init.value = NA)"

2017 Jan 31
1
RFC: tapply(*, ..., init.value = NA)
Function 'aggregate.data.frame' in R has taken a different route. With drop=FALSE, the function is also applied to subset corresponding to combination of grouping variables that doesn't appear in the data (example 2 in https://stat.ethz.ch/pipermail/r-devel/2017-January/073678.html). Because 'default' is used only when simplification happens, putting 'default' after
2017 Jan 27
1
RFC: tapply(*, ..., init.value = NA)
The "no factor combination" case is distinguishable by 'tapply' with simplify=FALSE. > D2 <- data.frame(n = gl(3,4), L = gl(6,2, labels=LETTERS[1:6]), N=3) > D2 <- D2[-c(1,5), ] > DN <- D2; DN[1,"N"] <- NA > with(DN, tapply(N, list(n,L), FUN=sum, simplify=FALSE)) A B C D E F 1 NA 6 NULL NULL NULL NULL 2 NULL NULL 3 6
2017 Feb 07
0
RFC: tapply(*, ..., init.value = NA)
Function 'tapply' in R devel r72137 uses if(!is.null(ans) && is.na(default) && is.atomic(ans)) . Problems: - It is possible that user-specified 'default' is not of length 1. If the length is zero, the 'if' gives an error. - It is possible that is.na(default) is TRUE and user-specified 'default' is NaN. --------------------------------------------
2017 Nov 04
1
ans[nas] <- NA in 'ifelse' (was: ifelse() woes ... can we agree on a ifelse2() ?)
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
2017 Jan 27
1
RFC: tapply(*, ..., init.value = NA)
On Fri, Jan 27, 2017 at 12:34 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote: > > > On Jan 26, 2017 07:50, "William Dunlap via R-devel" <r-devel at r-project.org> > > wrote: > > > It would be cool if the default for tapply's init.value could be > > FUN(X[0]), so it would be 0 for FUN=sum or FUN=length, TRUE for >
2017 Jan 26
3
RFC: tapply(*, ..., init.value = NA)
Last week, we've talked here about "xtabs(), factors and NAs", -> https://stat.ethz.ch/pipermail/r-devel/2017-January/073621.html In the mean time, I've spent several hours on the issue and also committed changes to R-devel "in two iterations". In the case there is a *Left* hand side part to xtabs() formula, see the help page example using 'esoph', it
2017 Jan 26
2
RFC: tapply(*, ..., init.value = NA)
On a related note, the storage mode should try to match ans[[1]] (or unlist:ed and) when allocating 'ansmat' to avoid coercion and hence a full copy. Henrik On Jan 26, 2017 07:50, "William Dunlap via R-devel" <r-devel at r-project.org> wrote: It would be cool if the default for tapply's init.value could be FUN(X[0]), so it would be 0 for FUN=sum or FUN=length, TRUE
2016 Sep 13
1
R-intro: function 'stderr' and 'sd'
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
2016 Jan 03
1
Wrong bug ID & URL in Daily News about R-devel/NEWS
I was browsing some recent R news at http://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2016/01/03#n2016-01-03 And reading this item: "tapply() has been made considerably more efficient without changing functionality, thanks to proposals from Peter Haverty and Suharto Anggono. (PR#16488)" But I found that the link in the item goes to a page about the GUI, not tapply:
2016 Sep 09
2
R-intro: function 'stderr' and 'sd'
In "An Introduction to R" Version 3.3.1, in "4.2 The function tapply() and ragged arrays", after stderr <- function(x) sqrt(var(x)/length(x)) , there is a note in brackets: Writing functions will be considered later in [Writing your own functions], and in this case was unnecessary as R also has a builtin function sd(). The part "in this case was unnecessary as R also
2017 Jan 26
0
RFC: tapply(*, ..., init.value = NA)
It would be cool if the default for tapply's init.value could be FUN(X[0]), so it would be 0 for FUN=sum or FUN=length, TRUE for FUN=all, -Inf for FUN=max, etc. But that would take time and would break code for which FUN did not work on length-0 objects. Bill Dunlap TIBCO Software wdunlap tibco.com On Thu, Jan 26, 2017 at 2:42 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote:
2017 Jan 27
0
RFC: tapply(*, ..., init.value = NA)
> On Jan 26, 2017 07:50, "William Dunlap via R-devel" <r-devel at r-project.org> > wrote: > It would be cool if the default for tapply's init.value could be > FUN(X[0]), so it would be 0 for FUN=sum or FUN=length, TRUE for > FUN=all, -Inf for FUN=max, etc. But that would take time and would > break code for which FUN did not work on
2017 Jun 11
1
translateChar in NewName in bind.c
I see another thing in function 'NewName' in bind.c. In else if (*CHAR(tag)) , 'ans' is basically copied from 'tag'. Could the whole thing there be just the following? ans = tag; It seems to me that it can also replace ans = R_BlankString; in 'else'; so, else if (*CHAR(tag)) and else can be merged to be just else . --------------------------------------------
1997 Dec 08
3
R-alpha: Bug in tapply in the Windows version of September
The function tapply is not working in the Windows version of R=20 (Version 0.50 Beta (Sept 29, 1997)) In tapply <- function (x, INDEX, FUN=3DNULL, simplify=3DTRUE, ...)=20 ... The part: if (simplify && all(unlist(lapply(ans, length)) =3D=3D 1)) { ans <- unlist(ans, recursive =3D FALSE) names(ans)<-namelist[[1]] return(ans) } should be replaced by if (simplify
2016 Aug 14
2
table(exclude = NULL) always includes NA
useNA <- if (missing(useNA) && !missing(exclude) && !(NA %in% exclude)) "ifany" An example where it change 'table' result for non-factor input, from https://stat.ethz.ch/pipermail/r-help/2005-April/069053.html : x <- c(1,2,3,3,NA) table(as.integer(x), exclude=NaN) I bring the example up, in case that the change in result is not intended.
2016 Aug 15
1
table(exclude = NULL) always includes NA
>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>> on Mon, 15 Aug 2016 11:07:43 +0200 writes: >>>>> Suharto Anggono Suharto Anggono <suharto_anggono at yahoo.com> >>>>> on Sun, 14 Aug 2016 03:42:08 +0000 writes: >> useNA <- if (missing(useNA) && !missing(exclude) && !(NA %in%
2017 May 18
2
stopifnot() does not stop at first non-TRUE argument
>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())(...) . I now realize that sys.call() doesn't expand '...' when the function is called with '...'. It just returns the call as is. If 'stopifnot' uses sys.call() instead of match.call() , the
2017 May 19
1
stopifnot() does not stop at first non-TRUE argument
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,
2017 Aug 18
1
Issues of R_pretty in src/appl/pretty.c
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,
2017 Aug 19
1
Issues of R_pretty in src/appl/pretty.c
Yes, they work now. I mentioned them partly because the commit description said overflow for large n and partly to be considered for regression tests. -------------------------------------------- On Sat, 19/8/17, Martin Maechler <maechler at stat.math.ethz.ch> wrote: Subject: Re: [Rd] Issues of R_pretty in src/appl/pretty.c Cc: r-devel at r-project.org Date: Saturday, 19 August, 2017,