Quantcast

Donchian Channel in TTR

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Donchian Channel in TTR

Andreas Voellenklee
Hi,

The DonchianChannel function in the package TTR calculates the highest
high and lowest low of the *current price* and the last (n-1) prices.
According to my sources, only the previous n prices should be
regarded, not the current price.

The following example shows that the current price is taken in the fifth line

getSymbols("YHOO", adjust=TRUE)
head(cbind((YHOO), DonchianChannel(cbind(Hi(YHOO),Lo(YHOO)),n=5)),n=10)

Possibly both methods are valid, but there should be a (optional)
parameter to the function so that users can choose whether they want
to include the current price or not. As in here:
http://www.linnsoft.com/tour/techind/donch.htm

Regards,
Andreas

_______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Donchian Channel in TTR

Jeffrey Ryan
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.

HTH
Jeff

On 4/5/12 8:11 AM, "Andreas Voellenklee" <[hidden email]> wrote:

>Hi,
>
>The DonchianChannel function in the package TTR calculates the highest
>high and lowest low of the *current price* and the last (n-1) prices.
>According to my sources, only the previous n prices should be
>regarded, not the current price.
>
>The following example shows that the current price is taken in the fifth
>line
>
>getSymbols("YHOO", adjust=TRUE)
>head(cbind((YHOO), DonchianChannel(cbind(Hi(YHOO),Lo(YHOO)),n=5)),n=10)
>
>Possibly both methods are valid, but there should be a (optional)
>parameter to the function so that users can choose whether they want
>to include the current price or not. As in here:
>http://www.linnsoft.com/tour/techind/donch.htm
>
>Regards,
>Andreas
>
>_______________________________________________
>[hidden email] 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.

_______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Donchian Channel in TTR

Andreas Voellenklee
Ok, so the other implementation of Donchian Channel, where the current
price is not included in calculation would be:

> getSymbols("YHOO", adjust=TRUE)
> head(cbind((YHOO), lag(DonchianChannel(cbind(Hi(YHOO),Lo(YHOO)),n=5)),k=1),n=10)

Andreas

_______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Donchian Channel in TTR

BBands
In reply to this post by Jeffrey Ryan
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
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.

Best,

John Bollinger

On Thu, Apr 5, 2012 at 7:45 AM, Jeffrey Ryan <[hidden email]> 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.

_______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Donchian Channel in TTR

Joshua Ulrich
On Fri, Apr 13, 2012 at 1:04 PM, BBands <[hidden email]> 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 <[hidden email]> 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.
>
> _______________________________________________
> [hidden email] 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.

_______________________________________________
[hidden email] 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.
Loading...