similar to: NA in doc for options(matprod="default")

Le 17/02/2020 ? 17:50, Tomas Kalibera a ?crit?: > On 2/17/20 5:36 PM, Serguei Sokol wrote: >> Hi, >> >> A colleague of mine has spotted me a passage of the doc ?option >> talking about Inf and NaN check in 'matprod=default' section: >> https://stat.ethz.ch/R-manual/R-devel/library/base/html/options.html >> >> I am wondering if NA should be

Hi, I was wondering if I could use the matprod function from array.c in my own C routine. I tried the following as a test /* my_matprod.c */ # include <Rinternals.h> /* for REAL, SEXP etc */ # include <R_ext/Applic.h> /* array.c says need for dgemm */ /* following copied from array.c */ static void matprod(double *x, int nrx, int ncx, double *y, int nry, int ncy, double *z)

I am using R to multiply some large (30k x 30k double) matrices on a 64 core machine (xeon phi). I added some timers to src/main/array.c to see where the time is going. All of the time is being spent in the matprod function, most of that time is spent in dgemm. 15 seconds is in matprod in some code that is checking if there are NaNs. > system.time (C <- B %*% A) nancheck: wall time

> Do you have R code (including set.seed(.) if relevant) to show on how to generate > the large square matrices you've mentioned in the beginning? So we get to some > reproducible benchmarks? Hi Martin, Here is the program I used. I only generate 2 random numbers and reuse them to make the benchmark run faster. Let me know if there is something I can do to help--alternate

Hi Tomas, Can you share the full code for your benchmark, compiler options, and performance results so that I can try to reproduce them? There are a lot of variables that can affect the results. Private email is fine if it is too much for the mailing list. I am measuring on Knight's Landing (KNL) that was released in November. KNL is not a co-processor so no offload is necessary. R executes

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

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

Le 07/07/2017 ? 01:09, Duncan Murdoch a ?crit : > On 06/07/2017 6:44 PM, Sokol Serguei wrote: >> Duncan Murdoch has written at Thu, 6 Jul 2017 13:58:10 -0400 >>> On 06/07/2017 5:21 AM, Serguei Sokol wrote: >>>> I propose the following patch against the current >>>> R-devel/src/main/connection.c (cf. attached file). >>>> It gives (on my linux

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

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

Le 07/07/2017 ? 16:52, Duncan Murdoch a ?crit : > On 07/07/2017 9:54 AM, Serguei Sokol wrote: >> Le 07/07/2017 ? 01:09, Duncan Murdoch a ?crit : >>> On 06/07/2017 6:44 PM, Sokol Serguei wrote: >>>> Duncan Murdoch has written at Thu, 6 Jul 2017 13:58:10 -0400 >>>>> On 06/07/2017 5:21 AM, Serguei Sokol wrote: >>>>>> I propose the

Simon, Thanks for replying. In what follows I won't try to argue (I understood that you find this a bad idea) but I would like to make clearer some of your point for me (and may be for others). Le 16/04/2020 ? 16:48, Simon Urbanek a ?crit?: > Serguei, >> On 17/04/2020, at 2:24 AM, Sokol Serguei <sokol at insa-toulouse.fr> >> wrote: Hi, I would like to make a

I'm sure this exists elsewhere, but, as a trade-off, could you achieve what you want with a separate helper function F(expr) that constructs the function you want to pass to [lsv]apply()? Something that would allow you to write: sapply(split(mtcars, mtcars$cyl), F(summary(lm(mpg ~ wt,.))$r.squared)) Such an F() function would apply elsewhere too. /Henrik On Thu, Apr 16, 2020 at 9:30 AM

Duncan Murdoch has written at Thu, 6 Jul 2017 13:58:10 -0400 > On 06/07/2017 5:21 AM, Serguei Sokol wrote: >> I propose the following patch against the current >> R-devel/src/main/connection.c (cf. attached file). >> It gives (on my linux box): >> > fc=file("/dev/full", "w") >> > write.csv("a", file=fc) >> Error in

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

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 ?

Le 15/05/2017 ? 15:37, Martin Maechler a ?crit : >>>>>> Serguei Sokol <sokol at insa-toulouse.fr> >>>>>> on Mon, 15 May 2017 13:14:34 +0200 writes: > > I see in the archives that the attachment cannot pass. > > So, here is the code: > > [....... MM: I needed to reformat etc to match closely to > the current

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

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

I propose the following patch against the current R-devel/src/main/connection.c (cf. attached file). It gives (on my linux box): > fc=file("/dev/full", "w") > write.csv("a", file=fc) Error in writeLines(paste(col.names, collapse = sep), file, sep = eol) : system call failure on writing > close(fc) Serguei. Le 05/07/2017 ? 15:33, Serguei Sokol a ?crit