similar to: small bug in plot code

On Sun, 2023-04-16 at 13:52 +0200, I?aki Ucar wrote: > I agree that something like this would be a nice addition. With the > current condition system, it would be certainly easy (but quite a lot > of work) to define a hierarchy of built-in conditions, and then use > them consistently throughout base R. Yes, a typed condition system would be great. I have two other ideas: By

A colleague sent me the following: If you specify probabilities in the 'sample' function and forget to type 'prob=...', then you get nonsense. E.g. sample(1:10,1,c(0,0,0,0,1,0,0,0,0,0)) does not filter '5', while sample(1:10,1,prob=c(0,0,0,0,1,0,0,0,0,0)) does it correctly. I wish this would return an error because the

With this patch, > A <- matrix(1, 2, 2) > B <- matrix(2, 3, 2) > A %*% B Error in A %*% B : non-conformable arguments of dimension (2, 2) and (3, 2) >From 205b591d4d14b5ff667325fb233a6deb08314726 Mon Sep 17 00:00:00 2001 From: Joshua Nathaniel Pritikin <jpritikin at pobox.com> Date: Fri, 5 Apr 2019 12:03:58 -0400 Subject: [PATCH] Improve non-conformable arguments error

Full_Name: Prokaj Vilmos Version: R 2-4-0 OS: Windows Submission from: (NULL) (193.224.79.8) PackBits(rbinom(32,1,0.5)==1,"integer") does not work. z<-packBits(rbinom(32,1,.5)==1,"integer") Error in packBits(x, type) : argument 'x' must be raw, integer or logical Taking a closer look at the C code main/character.c do_packBits rutin one can find the following

Hi, I have a problem with R-devel and Stataread 2.5. Stataread installs (compiles, at gives no error messages). But typing > library(stataread) Error in dyn.load(x, as.logical(local), as.logical(now)) : unable to load shared library "/usr/local/lib/R/library/stataread/libs/stataread.so": /usr/local/lib/R/library/stataread/libs/stataread.so: undefined symbol: errorcall Error in

Here is a nasty one: (0.65.1 on linux) > plot(c(1,2,3,4),c(2,4,6,8),log="Y") Segmentation fault (core dumped) [ml at athome ml]$ Seems the bug is in errorcall(). yes, I know the syntax is wrong, but it is an easy mistake to make and it is inconvenient to lose the work space at times. Michael ---------------------------------- E-Mail: Michael Lapsley <mlapsley at

The following statements yield a seg.fault: R --vanilla --nsize 500K x <- rep(letters,10000) f <- function(x) {z<-paste("\"",x,"\"",sep=""); z} y <- f(x) Segmentation fault If a turn gcinfo on, I get Garbage collection [nr. 1]... 387529 cons cells free (75%) 3807 Kbytes of heap free (62%) Garbage collection [nr. 2]... 273868 cons cells free

I've been inspired to look at the R source code by some strange timing results that I wrote about on my blog at radfordneal.wordpress.com (see the posts on "Speeding up parentheses..." and "Two surprising things...". I discovered that the strange speed advantage of curly brackets over parentheses is partially explained by an inefficiency in the evalList and

Duncan Murdoch wrote: > Huntsinger, Reid wrote: > >>Sorry, I was looking at 2.0.1 when I meant to be looking at 2.1.0. The line >>numbers for the latter are 161-179 and line 164 is the one with what I think >>is a typo. >> >>Reid Huntsinger >> >>-----Original Message----- >>From: r-devel-bounces@stat.math.ethz.ch

I'd like to propose that the whenever the length of condition passed to an if or a while statement differs from one, an error is produced rather than just a warning as today: > x <- 1:2 > if (x == 1) message("x == 1") x == 1 Warning message: In if (x == 1) message("x == 1") : the condition has length > 1 and only the first element will be used There are

Full_Name: Partho Bhowmick Version: 2.8.1 OS: Windows XP Submission from: (NULL) (199.43.48.131) While trying to install package sn (I have tried multiple mirrors), I get the following message trying URL 'http://www.revolution-computing.com/cran/bin/windows/contrib/2.8/sn_0.4-10.zip' Content type 'application/zip' length 320643 bytes (313 Kb) opened URL downloaded 313 Kb

In versions of R prior to 3.0, by default .C and .Call would find the requested C function regardless of which shared library it was located in. You could use the PACKAGE argument to restrict the search to a specific library, but doing so was not necessary for it to work. R 3.0 introduced a significant change to that behavior; from the NEWS file: CHANGES IN R 3.0.0: PERFORMANCE

I found a bug in one of the fourteen speed patches I posted, namely in patch-vec-subset. I've fixed this (I now see one does need to duplicate index vectors sometimes, though one can avoid it most of the time). I also split this patch in two, since it really has two different and independent parts. The patch-vec-subset patch now has only some straightforward (locally-checkable) speedups for

Hi Peter Yes, that looks roughly right to me. I would be in favour of your option (b), partly because it is probably easiest and partly because that retains the basic graphics device startup logic pattern that is replicated across all(?) graphics devices. Paul On 28/04/19 11:39 AM, peter dalgaard wrote: > I had a look at the current code, and AFAICT it has essentially the same structure

On Sun, 16 Apr 2023 at 12:58, nospam at altfeld-im.de <nospam at altfeld-im.de> wrote: > > I am the author of the *tryCatchLog* package and want to > > - suppress selected conditions (warnings and messages) > - rethrow selected conditions (e.g a specific warning as a message or to "rename" the condition text). > > I could not find any reliable unique

I tested it. It fixes the bug and didn't seem to produce any errors. Thank you Professor Dalgaard! I'm so glad this has finally been addressed. I will update the bug report. (https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702) On Thu, May 02, 2019 at 04:48:51PM +0200, peter dalgaard wrote: >OK, this is now in R-devel, but only superficially tested (b/c this is a Mac). Please

Dear all, I'm trying to fix a subtle bug in the hdf5 package. This package provides an interfaces to the HDF5 library and hence allows one to load data into R from files in the HDF5 format. The bug appeared during a period in which R changed but the package did not. I include below both the R and C code, stripped of everything except what is needed to show the bug. What is supposed to

Thanks Professor Dalgard. If you have a different way to fix the bug then I'd be happy to test it. Or whatever. I understand that maybe some data was being referenced before it had been initialized. I could also support moving the R_ProcessEvents call in another place, but it seems one would also like to generate some kind of warning message, at the location of the bad reference, rather than

I have to write extensions to R regularly. One of them was an interface to a mysql database on a different computer. The best way to do that is to have something like mysql<-function (dbname, host = "zap", user = "nobody", password = "ok") { handle <<- .RC("mysqlconnect", c(host, user, password, dbname)) } and query<-function (cmd) {

Looking at the source code of sort() -- for some speedup considerations -- I found that we currently use isVector() for testing the validity of x in sort(x) whereas I think we should use isVectorAtomic(), actually for S-plus compatibility additionally allowing NULL. Hence I'd propose to replace the test if (!isVector(CAR(args))) errorcall(call, "only vectors can be sorted");