similar to: 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

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

>>>>> 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 computed by the decomposition(*): always full rank in the LAPACK case. > For a

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

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. > On Jan 22, 2018, at 11:21 AM, Serguei Sokol <sokol at insa-toulouse.fr> wrote: > > Hi, > > I have noticed different rank values calculated by qr() depending on > LAPACK parameter. When it is FALSE (default) a true rank is

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

Hi, I came across a case when the dimensions of matrices returned by qr() operated on a sparse matrix does not coincide with the initial matrix. Here is a spinet code that should produce an example (one of many that I could provide): ?m=205 ?n=199 ?set.seed(7); ?a=matrix(rnorm(m*n), m, n) ?a[sample(seq(m*n), m*(n-4))]=0 ?a=as(a, "Matrix") ?qa=qr(a); ?stopifnot(nrow(qa at R) ==

A usually trustworthy R correspondent posted a pure R implementation on SO at some point in his lost youth: https://stackoverflow.com/questions/3224731/john-tukey-median-median-or-resistant-line-statistical-test-for-r-and-line This one does indeed generate the line of identity for the (1:9, 1:9) case, so I do suspect that we have a genuine scr*wup in line(). Notice, incidentally, that >

Le 04/12/2018 ? 11:27, I?aki Ucar a ?crit?: > On Tue, 4 Dec 2018 at 11:12, <qweytr1 at mail.ustc.edu.cn> wrote: >> function ppois is a function calculate the CDF of Poisson distribution, it should generate a non-decreasing result, but what I got is: >> >>> any(diff(ppois(0:19,lambda=0.9))<0) >> [1] TRUE >> >> Actually, >> >>>

Seriously, if a method gives a wrong result, it's wrong. line() does NOT implement the algorithm of Tukey, even not after the patch. We're not discussing Excel here, are we? The method of Tukey is rather clear, and it is NOT using the default quantile definition from the quantile function. Actually, it doesn't even use quantiles to define the groups. It just says that the groups

function ppois is a function calculate the CDF of Poisson distribution, it should generate a non-decreasing result, but what I got is: > any(diff(ppois(0:19,lambda=0.9))<0) [1] TRUE Actually, > ppois(19,lambda=0.9)<ppois(18,lambda=0.9) [1] TRUE Which could not be TRUE. Code is tested in both R 3.5.1 and Microsoft R Open 3.5.1. _

> > The behaviour of a[1,] is unchanged, for backwards compatibility > > reasons. But in pqR one can explicitly mark an argument as > > missing using "_". When an array subscript is missing in this way, > > the names will not be dropped in this context even if there is > > only one of them. So a[1,_] will do what you want: > > > > > a =

Dmitriy Selivanov (selivanov.dmitriy at gmail.com) wrote: > Consider following example: > > a = matrix(1:2, nrow = 2, dimnames = list(c("row1", "row2"), c("col1"))) > a[1, ] > # 1 > > It returns *unnamed* vector `1` where I would expect named vector. In fact > it returns named vector when number of columns is > 1. > Same issue applicable

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 only positive values returned by the vfprintf call. Cheers, j. On 4 July 2017 at 21:37, Duncan Murdoch <murdoch.duncan at

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

Hi Rui. Thanks for answer, I'm aware of drop = FALSE option. Unfortunately it doesn't resolve the issue - I'm expecting to get a vector, not a matrix . ??, 21 ????. 2018 ?. ? 20:54, Rui Barradas <ruipbarradas at sapo.pt>: > Hello, > > Use drop = FALSE. > > a[1, , drop = FALSE] > # col1 > #row1 1 > > > Hope this helps, > > Rui Barradas

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

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

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

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