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 th
On 17 Aug 2011, at 7:08PM, wrote:
> John C Nash 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.
>
> Looks like A
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])
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 user_un
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
John C Nash 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
> point ou
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 lin
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] Refe
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 c
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, no
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
installed
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
> i
On Tue, Aug 16, 2011 at 11: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
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
us
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 u
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 e
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 Malmau
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 fun
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 encounte
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 ou
20 matches
Mail list logo