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()