need apply.paramset logging

On Tue, Mar 22, 2016 at 10:21 AM, Diego Peroni <diegoperoni at vodafone.it> wrote:

On 22/03/2016 16:03, Brian G. Peterson wrote:

Executing on minute data won't drive the speed of the path-dependent
rules loop, the total number of signals which need to be evaluated will,
or the inclusion of things like trailing stops.

Trailing Stops is my case :-)

You should be able to sort out which parameter combination is failing
from the print statements.  you should also be able to look at the audit
environment to see which portfolio you're expecting is missing.

During multicore execution I'm enable to see print out.
I'm sure there is a way to redirect each thread print out to a file but I
don't know how.

doMC runs in separate processes, not threads.  You could add some code
to print the process ID before each message, or write to a file named
with the process ID.

Sys.getpid()

[1] 29236

registerDoMC(2)
foreach(1:6) %dopar% { Sys.getpid() }

[[1]]
[1] 29345

[[2]]
[1] 29346

[[3]]
[1] 29345

[[4]]
[1] 29346

[[5]]
[1] 29345

[[6]]
[1] 29346

Ultimately, this is a problem in your strategy specification...  You've
created an infeasible parameter combination.  You likely want to debug
what, specifically, is failing, rather than just skipping the failing
parameter set.

If you're determined to work with the combine funtion...

Sure :)

The .combine argument for foreach is described in the documentation for
foreach.  See ?foreach.

The combine function in apply.paramset is inside the apply.paramset
function.  We could probably check for a user-supplied combine, or you
could modify the combine function inside apply.paramset yourself.

Thanks a lot, I take a look


Regards

Diego

On Tue, 2016-03-22 at 15:45 +0100, Diego Peroni wrote:

Brain thanks for your answers!

My strategy take a long time to run because it is "minute" based and
runs over 6 years.

I've just 100 combinations so it is not the best to reduce nsamples to
find errors.

If I reduce time range (2 o 3 years) it doesn't fail.

If I run sequentially it take a very long time.

The best solution remains the last you have indicated: "custom .combine
function that could trap errors".
Does exist some documentation or example to read?

Regards

Diego Peroni




On 22/03/2016 09:46, Brian G. Peterson wrote:

On 03/22/2016 03:37 AM, Diego Peroni wrote:

I'm testing paramset combinations with:

.....
library(doMC)
registerDoMC(cores=detectCores())
paramsetenv = new.env()
results = apply.paramset(qs.strategy, paramset.label = "MACDOPT",
verbose = TRUE,
                             portfolio=qs.strategy, account=qs.strategy,
nsamples=0, audit=paramsetenv)

but the procedure returns NULL object with this message:

error calling combine function:
<simpleError: $ operator is invalid for atomic vectors>

Is there a way to log threads errors?

Or how can I modify "apply.paramset" function to "catch" single
simultation error or void result and discard it?

you're setting

nsamples=0

so you have zero results to combine.

In this case, you told it to run no samples, but I can conceive of a
strategy using some MCMC sampler that could fail spontaneously in some
circumstances.

A point of clarification: nsamples = 0 is the default for
apply.paramset. While confusing, that means that no sampling is done
and all parameter combinations are evaluated.  Sampling is only done
when nsamples > 0.

In a more general sense, you could specify a custom .combine function
that could trap errors if there was some possibility that your
strategy would fail to return a viable result.

A strategy that runs fine in a single core should run fine in
apply.paramset.  A reasonable way to start testing this beyond a
single parameterization would be to set a small number of samples,
like nsamples=50 and run it with registerDoSEQ() to run it sequentially.

Regards,

Brian