similar to: Augment base::replace(x, list, value) to allow list= to be a predicate?

Displaying 20 results from an estimated 6000 matches similar to: "Augment base::replace(x, list, value) to allow list= to be a predicate?"

2023 Mar 06
1
Augment base::replace(x, list, value) to allow list= to be a predicate?
Le 04/03/2023 ? 01:21, Pavel Krivitsky a ?crit?: > Dear All, > > Currently, list= in base::replace(x, list, value) has to be an index > vector. For me, at least, the most common use case is for list= to be > some simple property of elements of x, e.g., > > x <- c(1,2,NA,3) > replace(x, is.na(x), 0) > > Particularly when using R pipes, which don't allow multiple
2023 Mar 07
1
Augment base::replace(x, list, value) to allow list= to be a predicate?
This could be extended to sub and gsub as well which gsubfn in the gusbfn package already does: library(gsubfn) gsubfn("^..", toupper, c("abc", "xyz")) ## [1] "ABc" "XYz" On Fri, Mar 3, 2023 at 7:22?PM Pavel Krivitsky <p.krivitsky at unsw.edu.au> wrote: > > Dear All, > > Currently, list= in base::replace(x, list, value)
2023 Mar 08
1
Augment base::replace(x, list, value) to allow list= to be a predicate?
That's an interesting example, as it's conceptually similar to what Pavel is proposing, but structurally different. gsubfn() is more complicated than a simple switch in the body of the function, and wouldn't work well as an anonymous function. Multiple dispatch can nicely encompass both of these cases. For replace(), library(S7) replace <- new_generic("replace",
2023 Jan 10
1
rhub vs. CRAN fedora-*-devel, using armadillo & slapack
Le 10/01/2023 ? 11:37, Serguei Sokol a ?crit?: > Le 10/01/2023 ? 10:44, RICHET Yann a ?crit?: >> Dear R-devel people, >> >> We are working to submit a package which is mainly a binding over a >> C++ lib (https://github.com/libKriging) using armadillo. >> It is _not_ a standard RcppArmadillo package, because we also had to >> provide a python binding... so
2023 Jan 10
1
rhub vs. CRAN fedora-*-devel, using armadillo & slapack
Le 10/01/2023 ? 10:44, RICHET Yann a ?crit?: > Dear R-devel people, > > We are working to submit a package which is mainly a binding over a C++ lib (https://github.com/libKriging) using armadillo. > It is _not_ a standard RcppArmadillo package, because we also had to provide a python binding... so there is a huge layer of cmake & scripting to make it work with a standard armadillo
2023 Jan 10
1
rhub vs. CRAN fedora-*-devel, using armadillo & slapack
Dear R-devel people, We are working to submit a package which is mainly a binding over a C++ lib (https://github.com/libKriging) using armadillo. It is _not_ a standard RcppArmadillo package, because we also had to provide a python binding... so there is a huge layer of cmake & scripting to make it work with a standard armadillo (but using same version that RcppArmadillo). It seems now
2023 Apr 25
1
xyTable(x,y) versus table(x,y) with NAs
Le 25/04/2023 ? 10:24, Viechtbauer, Wolfgang (NP) a ?crit?: > Hi all, > > Posted this many years ago (https://stat.ethz.ch/pipermail/r-devel/2017-December/075224.html), but either this slipped under the radar or my feeble mind is unable to understand what xyTable() is doing here and nobody bothered to correct me. I now stumbled again across this issue. > > x <- c(1, 1, 2, 2, 2,
2020 Apr 17
2
suggestion: "." in [lsv]apply()
Thanks Simon, Now, I see better your argument. Le 16/04/2020 ? 22:48, Simon Urbanek a ?crit?: > ... I'm not arguing against the principle, I'm arguing about your > particular proposal as it is inconsistent and not general. This sounds promising for me. May be in a (new?) future, R core will come with a correct proposal for this principle? Meanwhile, to avoid substitute(),
2023 Dec 18
1
[External] Re: zapsmall(x) for scalar x
Le 17/12/2023 ? 18:26, Barry Rowlingson a ?crit?: > I think what's been missed is that zapsmall works relative to the absolute > largest value in the vector. Hence if there's only one > item in the vector, it is the largest, so its not zapped. The function's > raison d'etre isn't to replace absolutely small values, > but small values relative to the largest.
2018 Jan 22
3
Inconsistent rank in qr()
Le 22/01/2018 ? 17:40, Keith O'Hara a ?crit?: > This behavior is noted in the qr documentation, no? > > rank - the rank of x as computed by the decomposition(*): always full rank in the LAPACK case. For a me a "full rank matrix" is a matrix the rank of which is indeed min(nrow(A), ncol(A)) but here the meaning of "always is full rank" is somewhat confusing. Does it
2020 Apr 20
1
suggestion: "." in [lsv]apply()
Le 19/04/2020 ? 20:46, Gabor Grothendieck a ?crit?: > You can get pretty close to that already using fn$ in the gsubfn package: >> library(gsubfn) fn$sapply(split(mtcars, mtcars$cyl), x ~ >> summary(lm(mpg ~ wt, x))$r.squared) > 4 6 8 0.5086326 0.4645102 0.4229655 Right, I thought about similar syntax but this implementation has similar flaws pointed by Simon, i.e. it reduces
2023 Dec 18
1
[External] Re: zapsmall(x) for scalar x
>>>>> Serguei Sokol via R-devel >>>>> on Mon, 18 Dec 2023 10:29:02 +0100 writes: > Le 17/12/2023 ? 18:26, Barry Rowlingson a ?crit?: >> I think what's been missed is that zapsmall works relative to the absolute >> largest value in the vector. Hence if there's only one >> item in the vector, it is the largest, so its
2023 Dec 18
1
[External] Re: zapsmall(x) for scalar x
Le 18/12/2023 ? 11:24, Martin Maechler a ?crit?: >>>>>> Serguei Sokol via R-devel >>>>>> on Mon, 18 Dec 2023 10:29:02 +0100 writes: > > Le 17/12/2023 ? 18:26, Barry Rowlingson a ?crit?: > >> I think what's been missed is that zapsmall works relative to the absolute > >> largest value in the vector. Hence if
2020 Jul 19
6
Speed-up/Cache loadNamespace()
Dear all, in our current setting we have our packages stored on a (rather slow) network drive and need to invoke short R scripts (using RScript) in a timely manner. Most of the script's runtime is spent with package loading using library() (or loadNamespace to be precise). Is there a way to cache the package namespaces as listed in loadedNamespaces() and load them into memory before the
2017 Jul 05
2
[New Patch] Fix disk corruption when writing
Le 05/07/2017 ? 13:09, Duncan Murdoch a ?crit : > On 05/07/2017 5:26 AM, January W. wrote: >> I tried the newest patch, but it does not seem to work for me (on >> Linux). Despite the check in Rconn_printf, the write.csv happily writes >> to /dev/full and does not report an error. When I added a printf("%d\n", >> res); to the Rconn_printf() definition, I see
2018 Jan 23
1
Inconsistent rank in qr()
Le 23/01/2018 ? 08:47, Martin Maechler a ?crit?: >>>>>> Serguei Sokol <sokol at insa-toulouse.fr> >>>>>> on Mon, 22 Jan 2018 17:57:47 +0100 writes: > > Le 22/01/2018 ? 17:40, Keith O'Hara a ?crit?: > >> This behavior is noted in the qr documentation, no? > >> > >> rank - the rank of x as
2013 Mar 09
2
Submitting packages with weak circular dependencies to CRAN.
Hello, R-devel, I am planning to submit two packages, A and B, to CRAN. Package B uses an API exported by package A, while package A uses package B to test the API in question. Thus, package B Depends on, and Enhances, A, and A Suggests B. Could I get some guidance on submitting them to CRAN? A cannot be checked without B, but B cannot be installed without A. Thanks in
2020 Apr 16
6
suggestion: "." in [lsv]apply()
Hi, I would like to make a suggestion for a small syntactic modification of FUN argument in the family of functions [lsv]apply(). The idea is to allow one-liner expressions without typing "function(item) {...}" to surround them. The argument to the anonymous function is simply referred as ".". Let take an example. With this new feature, the following call
2018 Jan 22
2
Inconsistent rank in qr()
Hi, I have noticed different rank values calculated by qr() depending on LAPACK parameter. When it is FALSE (default) a true rank is estimated and returned. Unfortunately, when LAPACK is set to TRUE, the min(nrow(A), ncol(A)) is returned which is only occasionally a true rank. Would not it be more consistent to replace the rank in the latter case by something based on the following pseudo code ?
2017 May 29
3
stats::line() does not produce correct Tukey line when n mod 6 is 2 or 3
Here is an attached patch. Best, Serguei. Le 29/05/2017 ? 12:21, Serguei Sokol a ?crit : > The problem or actual R implementation relies on an assumption > that median(x[i] | x[i] <= quantile(x, 1/3)) == quantile(x, 1/6) > which reveals not to be true despite very trustful appearance. > > If we continue with the example of x=y=1:9 > then quantile(x, 1/6)=2.5 (here quantile()