[R-SIG-Finance] Donchian Channel in TTR
Joshua Ulrich
josh.m.ulrich at gmail.com
Sun Apr 15 19:54:10 CEST 2012
On Fri, Apr 13, 2012 at 1:04 PM, BBands <bbands at gmail.com> wrote:
> Donchian channels are a sort of special case in which the channel
> values should not include the current period. if I were to code this,
> today's value would reflect the n-1 prior highs and lows. The reason
So if n=10, you would only use 9 observations to calculate the
high/low channels? That's not what I would expect with n=10. Is that
the behavior Donchain intended?
> is that is that when the current high and low are used there can never
> be a breakout. These channels are used almost exclusively for
> breakouts and traders look to the prior period's values to determine
> whether a breakout has occurred. I fully understand Jeff's concerns
> and would be ok with a note in the docs advising the use of lag(), but
> I would code it with the lag as the default.
>
I'm considering adding an argument "include.lag" (with a default value
of FALSE, so existing functionality will not change) but the result at
time (t) will use observations from t-1 through t-n, not t-1 through
t-n+1.
Thanks,
--
Joshua Ulrich | FOSS Trading: www.fosstrading.com
R/Finance 2012: Applied Finance with R
www.RinFinance.com
> On Thu, Apr 5, 2012 at 7:45 AM, Jeffrey Ryan <jeff.a.ryan at gmail.com> wrote:
>> As I think I am partly responsible for this code in TTR (at least the
>> initial rev), I'll explain my logic.
>>
>> In general, more options/arguments that simply do what single functions
>> can do more explicitly isn't the best design strategy in many cases.
>> Secondly, most (all?) of the other functions in TTR behave by including
>> the 'current' price in the calculation. In the case of DonchianChannel
>> the result of this is simply more obvious.
>>
>> e.g. EMA, SMA, Bbands, runMax, cumsum (base R), cummin (base R), etc also
>> behave this way.
>>
>> The fix, without any code changes in the related TTR functions is to use
>> the facility lag(). This is the canonical way to assure you aren't
>> introducing look-ahead bias in your results.
>>
>> For what it is worth, this had been recently discussed in private. Josh
>> may have a slightly different opinion, and I think the consensus was that
>> the documentation could be more explicit, but the behavior is consistent
>> with R and TTR as is.
>
> _______________________________________________
> 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.
More information about the R-SIG-Finance
mailing list