similar to: Announcing pqR - a faster version of R

In testing pqR on Solaris SPARC systems, I have found two bugs that are also present in recent R Core versions. You can see the bugs and fixes at the following URLs: https://github.com/radfordneal/pqR/commit/739a4960a4d8f3a3b20cfc311518369576689f37 https://github.com/radfordneal/pqR/commit/339b7286c7b43dcc6b00e51515772f1d7dce7858 The first bug, in nls, is most likely to occur on a 64-bit

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

> From: Philippe GROSJEAN <Philippe.GROSJEAN at umons.ac.be> > > ... for latest CRAN version, we have successfully installed 4999 > packages among the 5321 CRAN package on our platform. ... It is > strange that a large portion of R CMD check errors on CRAN occur and > disappear *without any version update* of a package or any of its > direct or indirect dependencies!

On Tue, Jul 14, 2015 at 07:52:56PM -0400, Duncan Murdoch wrote: > On 14/07/2015 6:08 PM, Radford Neal wrote: > > In testing pqR on Solaris SPARC systems, I have found two bugs that > > are also present in recent R Core versions. You can see the bugs and > > fixes at the following URLs: > > > >

I think the discussion of this issue has gotten more complicated than necessary. First, there really is a bug. You can see this also by the fact that delayed warning messages are wrong. For instance, in R-3.1.2: > lapply(c(-1,2,-1),sqrt) [[1]] [1] NaN [[2]] [1] 1.414214 [[3]] [1] NaN Warning messages: 1: In FUN(c(-1, 2, -1)[[3L]], ...) : NaNs produced 2: In

A new version of pqR is now available at pqR-project.org, which fixes several bugs that are also present in the latest R Core patch release (r66002). A number of bugs found previously during pqR development are also unfixed in the latest R Core release. Here is the list of these bugs that are unfixed in r66002 (including documentation deficiencies), taken from the pqR bug fix and documentation

Fellipe, CXXR development has moved to github, and we haven't fixed up the build for using git yet. Could you send a pull request with your change to the repo at https://github.com/cxxr-devel/cxxr/? Also, this patch may be useful for pqR too. https://github.com/radfordneal/pqR Thanks On Mon, Jan 19, 2015 at 2:35 PM, Dirk Eddelbuettel <edd at debian.org> wrote: > > On 19

On 14/07/2015 6:08 PM, Radford Neal wrote: > In testing pqR on Solaris SPARC systems, I have found two bugs that > are also present in recent R Core versions. You can see the bugs and > fixes at the following URLs: > > https://github.com/radfordneal/pqR/commit/739a4960a4d8f3a3b20cfc311518369576689f37 Thanks for the report. Just one followup on this one: There are two sections

> From: "Cohn, Robert S" <robert.s.cohn at intel.com> > > 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

> On Fri, 2017-10-20 at 14:01 +0000, brodie gaslam via R-devel wrote: > > I'm thinking of this passage: > > > > > Logical values are sent as 0 (FALSE), 1 (TRUE) or INT_MIN = > > > -2147483648 (NA, but only if NAOK is true), and the compiled code > > > should return one of these three values. (Non-zero values other > > > than INT_MIN are

I am trying to write a program that uses R and takes a pdb file, and converts it to a pqr file. This task is simple generally, using the website, http://pdb2pqr-1.wustl.edu/pdb2pqr/. How do you use R to input a pdb file (that is on hand) into the upload pdb file input, and run the website and give the return file to be a pqr file. Thanks for your help. -- View this message in context:

There are websites using python to convert a pdb to a pqr. I was wondering if there is a simpler way to do it. We have a protein in pdb format, and want to convert that to a pqr file so that the program apbs can open it. We want to accomplish this conversion in R. Thank you for your help. -- View this message in context: http://n4.nabble.com/Converting-pdb-to-pqr-tp1475426p1475426.html Sent

Suharto, If you're interested in performance with subscripting, you might want to look at pqR (pqR-project.org). It has some substantial performance improvements for subscripting over R Core versions. This is especially true for the current development version of pqR (probably leading to a new release in about a month). You can look at a somewhat-stable snapshot of recent pqR development

> ... with assignments inside of loops like this: > > reweight = function(iter, w, Q) { > for (i in 1:iter) { > wT = w * Q > } > } > ... before the RHS is executed, the LHS allocation would be added > to a small fixed length list of available space which is checked > before future allocations. If the same size is requested before the > next garbage

> Henrik Bengtsson: > > I'm looking for a way to get the length of an object 'x' as given by > base data type without dispatching on class. The performance improvement you're looking for is implemented in the latest version of pqR (pqR-2016-10-24, see pqR-project.org), along with corresponding improvements in several other circumstances where unclass(x) does not

> From: Tomas Kalibera <tomas.kalibera at gmail.com> > > Thanks for the report, I am working on a patch that will address this. > > I confirm there is a lot of potential for speedup. On my system, > > 'N=200000; x <- substring(paste(rep("A", N), collapse=""), 1:N, 1:N)' > > spends 96% time in checking if the string is ascii and 3%

While doing some performance testing with the new version of pqR (see pqR-project.org), I've encountered an extreme, and quite unnecessary, inefficiency in the current R Core implementation of R, which I think you might want to correct. The inefficiency is in access to columns of a data frame, as in expressions such as df$col[i], which I think are very common (the alternatives of

I've been getting pqR to work on windows systems, and in the process have discovered various problems with R core versions of R and with Rtools. One is with the implementation of OpenMP in 64-bit Rtools. This problem is in Rtools215 and Rtools33, and presumably all the ones in between. You can see the problem with the following test program: #include <stdio.h> #include <omp.h>

On Sun, 1 Mar 2015, Radford Neal wrote: > I think the discussion of this issue has gotten more complicated than > necessary. The discussion has gotten no more complicated than it needs to be. There are other instances, such as Reduce where there is a bug report pending that amounts to the same issue. Performing surgery on expressions and calling eval is not good practice at the R level

I have rewritten the R parser in the new version of pqR that I recently released (pqR-2015-09-14, at pqR-project.org). The new version of the parser is much cleaner, is faster (sometimes quite substantially faster), has a better interface to the read-eval-print loop, and provides a better basis for future extensions. The deparser has also been substantially revised in pqR, and is better