Re: [Rd] serialize/unserialize vector improvement

t; Best, > > luke > > > On Mon, 3 Oct 2011, Michael Spiegel wrote: > >> Any thoughts? I haven't heard any feedback on this patch. >> >> Thanks! >> --Michael >> >> On Wed, Sep 28, 2011 at 3:10 PM, Michael Spiegel >> wrote: >>> >&g

[Rd] exporting isChild in package parallel

I was wondering if there is any interest in making the function isChild() exported from the package parallel? This would be of great help to anyone writing R packages that use thread-level parallelism, and would like to throttle the spawning of threads whenever the R process is detected to be a chi

Re: [Rd] [R-sig-hpc] R CMD INSTALL configure.args and CC customization

nd welcome others to comment if there are potential downsides to this solution. George > Michael Spiegel michael.m.spiegel at gmail.com > <mailto:r-devel%40r-project.org?Subject=Re%3A%20%5BRd%5D%20R%20CMD%20I > NSTALL%20configure.args%20and%20CC%20customization&am

Re: [Rd] serialize/unserialize vector improvement

Any thoughts? I haven't heard any feedback on this patch. Thanks! --Michael On Wed, Sep 28, 2011 at 3:10 PM, Michael Spiegel wrote: > Hi folks, > > I've attached a patch to the svn trunk that improves the performance > of the serialize/unserialize interface for vec

[Rd] serialize/unserialize vector improvement

Hi folks, I've attached a patch to the svn trunk that improves the performance of the serialize/unserialize interface for vector types. The current implementation: a) invokes the R_XDREncode operation for each element of the vector type, and b) uses a switch statement to determine the stream type

Re: [Rd] R CMD INSTALL configure.args and CC customization

I am running into the following issue that has been previously reported on the R-devel mailing list. The short version is that I'm writing a package for MPI, and I'd like to change CC and SHLIB_LD to "mpicc". Trying to change them in Makevars.in has no effect, because the values are clobbered by /e

Re: [Rd] [R-SIG-Mac] BLAS benchmarks on R 2.12.0

My apologies. I finally noticed that the source files in src/extra/blas had changed. I had been looking at the diff file for a few days, until I remembered that the "c" at the beginning of a line signifies the line as a comment. OK, so the game plan for our specific R package will be to take the

Re: [Rd] BLAS benchmarks on R 2.12.0

either veclib, Atlas, or the Goto BLAS implementations, I've tested all of them on our performance test suite. --Michael On Mon, Nov 1, 2010 at 6:07 PM, Andrew Piskorski wrote: > On Sun, Oct 31, 2010 at 12:41:24PM -0400, Michael Spiegel wrote: > >> 1) Compile the reference BLAS im

[Rd] BLAS benchmarks on R 2.12.0

Hi, I saw on the mailing list and in the NEWS file that some unsafe math transformations were disabled for the reference BLAS implementation that is used in R. We have a set of performance tests for the OpenMx library, and some of the tests have a x3-10 slowdown in R 2.12.0 versus 2.11.1. When I

Re: [Rd] windows 64-bit package build on 32-bit machine

on Urbanek wrote: > > On Oct 26, 2010, at 9:04 PM, Michael Spiegel wrote: > >> Hello, >> >> Is it possible to build a 64-bit package on a 32-bit machine on >> windows? I can cross-compile for x86, x86_64, and ppc on a 32-bit OS X >> machine.  And it look

[Rd] windows 64-bit package build on 32-bit machine

Hello, Is it possible to build a 64-bit package on a 32-bit machine on windows? I can cross-compile for x86, x86_64, and ppc on a 32-bit OS X machine. And it looks like I could build a 32-bit library on a 64-bit windows machine. But it doesn't look possible to build a 64-bit library on a 32-bit

Re: [Rd] (PR#14226) -- Re: libgfortran misplaced in Mac OS X R install

be found). > > On Thu, 4 Mar 2010, Simon Urbanek wrote: > >> Hi Michael, >> >> On Mar 3, 2010, at 12:01 , Michael Spiegel wrote: >> >>> I am the guy who compiles the OpenMx binaries.  We would be delighted to >>> place our package on CRAN, once the proje

[Rd] (PR#14226) -- Re: libgfortran misplaced in Mac OS X R install (PR#14226)

I am the guy who compiles the OpenMx binaries. We would be delighted to place our package on CRAN, once the project is stable enough so that we are comfortable releasing it to the larger public. Let's try to track down where I made a mistake. Our Makevars.in file contains the line: PKG_LIBS=$(F

Re: [Rd] c() poor error reporting (PR#13917)

Aug 29, 2009 at 5:53 PM, Duncan Murdoch wrote: > On 28/08/2009 5:00 PM, michael.m.spie...@gmail.com wrote: >> >> Full_Name: Michael Spiegel >> Version: 2.9.1 >> OS: linux >> Submission from: (NULL) (137.54.6.192) >> >> >> The function c() gives a

Re: [Rd] diag() has a bug (PR#13702)

Aha. Yes, it would. Thank you. However the error message is still incorrect. On Thu, May 14, 2009 at 3:35 PM, Benilton Carvalho wrote: > in that case, wouldn't > > diag(diag(foo)) > > suffice? > > b > > > On May 14, 2009, at 4:30 PM, Michael Spiegel wrote

Re: [Rd] diag() has a bug (PR#13702)

with those dimensions. > > diag(pi, 6, 6) > > and that by > > diag(foo, 2, 2) > > you really meant > > diag(foo)[2] > > Apologies if I misunderstood. > > b > > On May 14, 2009, at 10:45 AM, michael.m.spie...@gmail.com wrote: > > Full_Name: