[R-SIG-Finance] need apply.paramset logging

Joshua Ulrich josh.m.ulrich at gmail.com
Tue Mar 22 18:22:37 CET 2016


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
>>>>
>>> _______________________________________________
>>> R-SIG-Finance at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-finance
>>> -- Subscriber-posting only. If you want to post, subscribe first.
>>> -- Also note that this is not the r-help list where general R questions
>>> should go.
>
>
> _______________________________________________
> R-SIG-Finance at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-sig-finance
> -- Subscriber-posting only. If you want to post, subscribe first.
> -- Also note that this is not the r-help list where general R questions
> should go.



-- 
Joshua Ulrich  |  about.me/joshuaulrich
FOSS Trading  |  www.fosstrading.com
R/Finance 2016 | www.rinfinance.com



More information about the R-SIG-Finance mailing list