[Rd] Poor family objects error messages

Hello, The following code: > binomial(identity) Generates an error message: Error in binomial(identity) : link "identity" not available for binomial family; available links are �logit�, �probit�, �cloglog�, �cauchit�, �log� While : > binomial("identity") Yields an identity-binomial object

Re: [Rd] Is it a good choice to increase the NCONNECTION value?

RConnection is a pointer to a Rconn structure. The Rconn structure must be allocated independently (e.g. by malloc() in R_new_custom_connection). Therefore, increasing NCONNECTION to 1024 should only use 8 kilobytes on 64-bits platforms and 4 kilobytes on 32 bits platforms. Ideally, it should

[Rd] R_CheckUserInterrupt

Dear R developers, R makes some functions interruptible, thanks to a call to R_CheckUserInterrupt. Simple arithmetic operations can be interrupted avoiding freezes when using huge arrays (e.g. length > 1 billion). But many operations, such as matrix multiplication, are not interruptible. I

Re: [Rd] order of operations

Due to lazy evaluation, the order of operations can be pretty random in R. Actually, some operations may not be performed at all, sometimes. The following program illustrates the issue: test1=function(x,y) {} test2=function(x,y) {x;y} test3=function(x,y) {y;x} alpha="hello" test1(alpha <- 1,

Re: [Rd] Is it a good choice to increase the NCONNECTION value?

_ De : qwey...@mail.ustc.edu.cn Envoyé : mercredi 25 août 2021 06:15:59 À : Simon Urbanek Cc : Martin Maechler; GILLIBERT, Andre; R-devel Objet : 回复: [SPAM] Re: [Rd] Is it a good choice to increase the NCONNECTION value? ATTENTION: Cet e-mail provient d’une adresse mail extérieure

Re: [Rd] sum() and mean() for (ALTREP) integer sequences

Hello, Please, find a long response below. == difference between mean(x) and sum(x)/length(x) == At the core, mean(x) and sum(x)/length(x) works very differently for real numbers. Mean is more accurate when applied to a vector with a small variance but a very high mean, especially on

Re: [Rd] Spurious warnings in coercion from double/complex/character to raw

Hello, Integer overflow is undefined behavior by the C standard. For instance, on my computer, with GCC 5.4.0, with the optimization level 2, the following program never stops: include int main(void) { for(int i=1; i != 0; i++) { if ((i & 0xFFF) == 0) {

Re: [Rd] Question about quantile fuzz and GPL license

Martin Maechler wrote: > OTOH, type=7 is the default, and I guess used in 99.9% of > all uses of quantile, *and* does never use any fuzz Indeed. This also implies that this default should be well-thought when creating a new implementation of the quantile() procedure for a new programming

Re: [Rd] Question about quantile fuzz and GPL license

On 9/14/21 9:22 AM, Abel AOUN wrote: > However I don't get why epsilon is multiplied by 4 instead of simply using > epsilon. > Is there someone who can explain this 4 ? .Machine$double.eps is the "precision" of floating point values for values close to 1.0 (between 0.5 and 2.0). Using fuzz =

Re: [Rd] WISH: set.seed(seed) to produce error if length(seed) != 1 (now silent)

Hello, A vector with a length >= 2 to set.seed would probably be a bug. An error message will help the user to fix his R code. The bug may be accidental or due to bad understanding of the set.seed function. For instance, a user may think that the whole state of the PRNG can be passed to

[Rd] Redundant source code for random number generation

Dear R developers, When trying to fix poor performances of the runif() function (I can easily make it three times faster if you are interested in performance patches, maybe six times faster with a bit of refactoring of R source code), I noticed some redundant code in R source code (R-devel of

[Rd] Problem in random number generation for Marsaglia-Multicarry + Ahrens-Dieter

Dear R developers, At the same time I discovered a flaw in Marsaglia-Multicarry + Kinderman-Ramage, I found another in Marsaglia-Multicarry + Ahrens-Dieter. It is less obvious than for Kinderman-Ramage; so I created a new thread for this bug. The following code shows the problem (tested on R

[Rd] Problem in random number generation for Marsaglia-Multicarry + Kinderman-Ramage

Dear R developers, In my opinion, I discovered a severe flaw that occur with the combination of the Marsaglia-Multicarry pseudo-random number generator associated to the Kinderman-Ramage algorithm to generate normally distributed numbers. The sample program is very simple (tested on R-4.1.1

Re: [Rd] stats::fft produces inconsistent results

l make it easier to understand the extensive documentation. -- Sinc�rement Andr� GILLIBERT De : Dipterix Wang Envoy� : mercredi 20 octobre 2021 22:01 � : Martin Maechler ; GILLIBERT, Andre ; bbol...@gmail.com Cc : r-devel@r-project.org Objet : Re: [Rd] stats::fft produces inconsistent resul

Re: [Rd] stats::fft produces inconsistent results

Hello, That sounds like a good diagnosis! Indeed, R vectors are passed "by reference" to C code, but the semantic must be "by value", i.e. the C function must NOT change the contents of the vector, except in very specific cases. A good program that has to work on a vector, must first duplicate

[Rd] Workaround very slow NAN/Infinities arithmetic?

Dear R developers, By default, R uses the "long double" data type to get extra precision for intermediate computations, with a small performance tradeoff. Unfortunately, on all Intel x86 computers I have ever seen, long doubles (implemented in the x87 FPU) are extremely slow whenever a special

Re: [Rd] Workaround very slow NAN/Infinities arithmetic?

Brodie Gaslam wrote: > André, > I'm not an R core member, but happen to have looked a little bit at this > issue myself. I've seen similar things on Skylake and Coffee Lake 2 > (9700, one generation past your latest) too. I think it would make sense > to have some handling of this, although I

Re: [Rd] [External] Re: Workaround very slow NAN/Infinities arithmetic?

> Mildly related (?) to this discussion, if you happen to be in a situation > where you know something is a C NAN, but need to check if its a proper R > NA, the R_IsNA function is surprisingly (to me, at least) expensive to do > in a tight loop because it calls the (again, surprisingly expensive

Re: [Rd] Segfault in setMask in R 4.1

Hello, Which graphic device (backend) do you use? The setMask() function calls the internal setMask function associated to the graphic device. If the Web application uses one of the standard graphic backend, the bug may come from the R core. If it uses a custom graphic backend, the bug may be

Re: [Rd] Is it a good choice to increase the NCONNECTION value?

_ De : Simon Urbanek Envoyé : jeudi 26 août 2021 01:27:51 À : GILLIBERT, Andre Cc : qwey...@mail.ustc.edu.cn; R-devel; Martin Maechler Objet : Re: [Rd] Is it a good choice to increase the NCONNECTION value? ATTENTION: Cet e-mail provient d’une adresse mail extérieure au CHU de Rouen.

Re: [Rd] order of operations

For the discussion: > Yes, and were it not for 0 * NA == NA, you might skip evaluation of y if x > evaluates to zero. With the same idea, NA * (alpha <- 6) could skip the assignment. I do not think that, on the short term, R would do that thing, but who knows in the future! As of R 4.1,

Re: [Rd] Documentation of addmargins

Thomas SOEIRO wrote: > Dear list, > There is a minor typo in addmargins (section Details): > - If the functions used to form margins are not commutative the result > depends on the order in which margins are computed. Annotation of margins is > done via naming the FUN list. > + If the

Re: [Rd] string concatenation operator (revisited)

Ivan Krylov wrote: > FWIW, Perl5 has a separate string concatenation operator (".") in order > to avoid potential confusion with addition. So do Lua (".."), SQL > ("||", only some of the dialects) and Raku ("~", former Perl6). Indeed, using the same operator '+' for addition and string

Re: [Rd] Better 'undefined columns' error for data.frame

Duncan Murdoch wrote: > On 24/09/2022 9:56 a.m., GILLIBERT, Andre wrote: > > Dear R developers, > > > > > > One of the error messages that make me loose the most time is the > > "undefined columns selected" of `[.data.frame`. > > >

Re: [Rd] Better 'undefined columns' error for data.frame

Duncan Murdoch wrote: > > > On 25/09/2022 2:48 p.m., Dirk Eddelbuettel wrote: > > > > Andre, > > > > On 25 September 2022 at 18:09, GILLIBERT, Andre wrote: > > | Please, find the patch attached, based on the latest R SVN trunk code. > > >

[Rd] Better 'undefined columns' error for data.frame

Dear R developers, One of the error messages that make me loose the most time is the "undefined columns selected" of `[.data.frame`. It ought to specify the list of bad column names, but currently does not. Fortunately, this can easily be fixed by a small patch I can write. Are you

Re: [Rd] Bug in optim for specific orders of magnitude

J C Nash wrote: > Extreme scaling quite often ruins optimization calculations. If you think > available methods are capable of doing this, there's a bridge I can sell you > in NYC. Given that optim()seems to have problem with denormals but work correctly with values greater than 1e-308, I

Re: [Rd] Recycling in arithmetic operations involving zero-length vectors

Duncan Murdoch wrote: > To even do that, we would have to first decide which "cases" should produce a > warning. > Let's say `1 + x` should give a warning when x = numeric(0). Then should > `x^2` also produce a warning? Should `x^0.5`? Should `sqrt(x)`? > Should `log(x)`? The most probable

[Rd] Bug or feature?

Dear developers, I found an inconsistency in the predict.lm() function between offset and non-offset terms of the formula, but I am not sure whether that is intentional or a bug. The problem can be shown in a simple example: mod <- local({ y <- rep(0,10) x <- rep(c(0,1), each=5)

[Rd] Documentation bug?

Dead R developers, In R-devel 2023-02-11 and older R versions, there is a note in the "lm {stats}" help page specifying that: > Offsets specified by offset will not be included in predictions by > predict.lm, whereas > those specified by

Re: [Rd] Inquiry about the behaviour of subsetting and names in matrices

Envoyé : mercredi 3 mai 2023 11:08:28 À : GILLIBERT, Andre Cc : r-devel@r-project.org Objet : Re: [Rd] Inquiry about the behaviour of subsetting and names in matrices ATTENTION: Cet e-mail provient d’une adresse mail extérieure au CHU de Rouen. Ne cliquez pas sur les liens ou n'ouvrez pas

Re: [Rd] Inquiry about the behaviour of subsetting and names in matrices

Karolis wrote: > Hello, > I have stumbled upon a few cases where the behaviour of naming and subsetting > in matrices seems unintuitive. > All those look related so wanted to put everything in one message. > 1. Why row/col selection by names with NAs is not allowed? > x <- setNames(1:10,