This message is about a curious difference in timing between two ways of
computing the
same function. One uses expm, so is expected to be a bit slower, but a bit
turned out to
be a factor of 1000. The code is below. We would be grateful if anyone can
point out any
egregious bad practice in our
Hi,
in R 2.12.1, R CMD check hangs when building a vignette that uses a
foreach loop with the doMC parallel backend.
This does not happen in R 2.13.1, nor if I use doSEQ instead of doMC.
All versions of multicore, doMC and foreach are the same on both my R
installations.
Has anybody
I think one difference is that negll() is fully vectorized - no loops, whereas
nlogL calls the function sol() inside sapply, i.e. a loop.
Michael
On 17 Aug 2011, at 10:27AM, John C Nash wrote:
This message is about a curious difference in timing between two ways of
computing the
same
Hi,
My R package has files in the 'inst' directory that it needs to reference. How
can the R scripts in my package find out the full path to the 'inst' directory
after the package is installed, given that different users may have installed
the package to different libraries?
Thanks,
Jon
I did notice some strange behaviour once, but things were working
without a problem for a while now.
foreach loops and concepts are nice concepts, which I'd like to carry on
using.
Maybe somebody from the foreach-dopar packages could explain why they
have such issues?
Tim do you have concrete
hopefully you'll be able to create a reproducible example, as my hanging
issues seem to come and go without any obvious reason.
On 17/08/2011 13:50, Tim Triche, Jr. wrote:
I'll see if I can put together a self-contained example. Primarily,
the times that I use multicore (and attempted to
I'll see if I can put together a self-contained example. Primarily, the
times that I use multicore (and attempted to use doSMP, mostly because one
of my users refuses to ditch Windows) are when I am reading a ton of binary
files, none of which depend on the others. This is a blindingly obvious
On Tue, Aug 16, 2011 at 11:17 PM, Jonathan Malmaud malm...@gmail.com wrote:
Hi,
My R package has files in the 'inst' directory that it needs to reference.
How can the R scripts in my package find out the full path to the 'inst'
directory after the package is installed, given that different
On Aug 16, 2011, at 10:17 PM, Jonathan Malmaud wrote:
Hi,
My R package has files in the 'inst' directory that it needs to reference.
How can the R scripts in my package find out the full path to the 'inst'
directory after the package is installed, given that different users may have
On 16 August 2011 at 23:17, Jonathan Malmaud wrote:
| Hi,
| My R package has files in the 'inst' directory that it needs to reference.
How can the R scripts in my package find out the full path to the 'inst'
directory after the package is installed, given that different users may have
On Wed, 2011-08-17 at 04:50 -0700, Tim Triche, Jr. wrote:
I'll see if I can put together a self-contained example. Primarily,
the times that I use multicore (and attempted to use doSMP, mostly
because one of my users refuses to ditch Windows) are when I am
reading a ton of binary files, none
Uhm... maybe this is the issue.
The issue seems to specially occur when I am building the vignette,
which performs some parallel computations on a reduced example,
therefore faster than in a normal usage of the package.
The two processes (on my dual core) output some logging information
using
You can use
system.file(package=your_package_name)
which will return you library directory.
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Jonathan Malmaud
Sent: 17 August 2011 04:18
To: r-devel@r-project.org
Subject: [Rd]
Hi,
When loading a package that provides the user-supplied RNG hook
user_unif_rand, calling getNativeSymbolInfo(user_unif_rand) returns
informations about the loaded symbol.
I am using this to identify which package currently provides the RNG hook.
The results are the same on windows and
John C Nash nas...@uottawa.ca writes:
This message is about a curious difference in timing between two ways of
computing the
same function. One uses expm, so is expected to be a bit slower, but a bit
turned out to
be a factor of 1000. The code is below. We would be grateful if anyone can
Yes, the culprit is the evaluation of expm(A*t). This is a lazy way of solving
the system of ODEs, where you save analytic effort, but you pay for it dearly
in terms of computational effort!
Even in this lazy approach, I am sure there ought to be faster ways to
evaluating exponent of a matrix
Hi Renaud
I cannot presently step through the code on Windows to verify the cause of
the problem,
but looking at the code, I would _presume_ the reason is that symbol lookup is
cached on
Windows but not on Linux or OS X (at least by default).
Thus when we perform the second search for
A principled way to solve this system of ODEs is to use the idea of
fundamental matrix, which is the same idea as that of diagonalization of a
matrix (see Boyce and DiPrima or any ODE text).
Here is the code for that:
nlogL2 - function(theta){
k - exp(theta[1:3])
sigma - exp(theta[4])
A
On 17 Aug 2011, at 7:08PM, cbe...@tajo.ucsd.edu cbe...@tajo.ucsd.edu wrote:
John C Nash nas...@uottawa.ca writes:
This message is about a curious difference in timing between two ways of
computing the
same function. One uses expm, so is expected to be a bit slower, but a bit
turned out
Just a small addition:
If you replace below
sol-function(t)100-sum(expm(A*t)%*%x0)
by
sol-function(t){A@x=A@x*t;100-sum(expm(A)@x * x0)}
(ugly! But avoiding the conversions and generics)
The time on my machine drop further down to 0.3 seconds. (from the original 13
seconds, and then from the
20 matches
Mail list logo
