similar to: R history: Why 'L; in suffix character ‘L’ for integer constants?

Yeah, that was what I heard from our instructor when I was a graduate student: L stands for Long (integer). Regards, Yihui -- https://yihui.name On Fri, Jun 16, 2017 at 11:00 AM, Serguei Sokol <sokol at insa-toulouse.fr> wrote: > Le 16/06/2017 ? 17:54, Henrik Bengtsson a ?crit : >> >> I'm just curious (no complaints), what was the reason for choosing the >> letter

Wikipedia claims that C ints are still only guaranteed to be at least 16 bits, and longs are at least 32 bits. So no, R's integers are long. -pd > On 16 Jun 2017, at 20:20 , William Dunlap via R-devel <r-devel at r-project.org> wrote: > > But R "integers" are C "ints", as opposed to S "integers", which are C > "long ints". (I

The relevant sections of the C standard are http://c0x.coding-guidelines.com/5.2.4.2.1.html, which specifies that C ints are only guaranteed to be 16 bits, C long ints at least 32 bits in size, as Peter mentioned. Also http://c0x.coding-guidelines.com/6.4.4.1.html specifies l or L as the suffix for a long int constants. However R does define integers as `int` in it's source code, so use of L

But R "integers" are C "ints", as opposed to S "integers", which are C "long ints". (I suppose R never had to run on ancient hardware with 16 bit ints.) Bill Dunlap TIBCO Software wdunlap tibco.com On Fri, Jun 16, 2017 at 10:47 AM, Yihui Xie <xie at yihui.name> wrote: > Yeah, that was what I heard from our instructor when I was a graduate >

"Writing R Extensions" says "int": R storage mode C type FORTRAN type logical int* INTEGER integer int* INTEGER double double* DOUBLE PRECISION complex Rcomplex* DOUBLE COMPLEX character char** CHARACTER*255 raw unsigned char* none Bill Dunlap TIBCO Software wdunlap tibco.com On Fri, Jun 16, 2017 at 11:53 AM, peter dalgaard <pdalgd at gmail.com> wrote:

On 16/06/2017 20:37, Jim Hester wrote: > The relevant sections of the C standard are > http://c0x.coding-guidelines.com/5.2.4.2.1.html, which specifies that C There is more than one C standard, but that is none of them. > ints are only guaranteed to be 16 bits, C long ints at least 32 bits in > size, as Peter mentioned. Also http://c0x.coding-guidelines.com/6.4.4.1.html >

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

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

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

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 ?

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

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

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

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

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

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

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 >