TradingView
bennef
15 Th05 2019 12:53

CCI PWR 

Bitcoin / US Dollar Perpetual Inverse Swap ContractBitMEX

Mô tả

This is a backtest for my CCI PWR indicator here. It works very well on a daily chart but may be useful for lower timeframes.

You can change the backtest settings to test different periods of time.

I have included a stop-loss function that will exit a trade if the price goes against the signals. The parameter is an integer that represents a %age of the current price, so for example, a value of 2 would mean a stoploss is set 2% below a long entry or 2% above a short entry.

is an image of ETH/BTC with the same settings.

Let me know if you find it useful!
Bình luận
BeAst767
Can you send me the backtest (just the time functions/declarations) portion of the script? I am trying to determine if the script here uses the correct backtest methodology: tradingview.com/script/SMQcpefL-How-to-automate-this-strategy-for-free-Version-2/
bennef
@BeAst767, the link you posted shows the same code I used for the period selection component. Code below:

testStartYear = input(2017, "Backtest Start Year")
testStartMonth = input(1, "Backtest Start Month")
testStartDay = input(1, "Backtest Start Day")
testPeriodStart = timestamp(testStartYear,testStartMonth,testStartDay, 0, 0)

testStopYear = input(2019, "Backtest Stop Year")
testStopMonth = input(12, "Backtest Stop Month")
testStopDay = input(31, "Backtest Stop Day")
testPeriodStop = timestamp(testStopYear,testStopMonth,testStopDay, 0, 0)

// A switch to control background coloring of the test period
testPeriodBackground = input(title="Color Background?", type=bool, defval=true)
testPeriodBackgroundColor = testPeriodBackground and (time >= testPeriodStart) and (time <= testPeriodStop) ? #0000FF : na
bgcolor(testPeriodBackgroundColor, transp=97)

testPeriod() =>
time >= testPeriodStart and time <= testPeriodStop ? true : false

The strategy component of my code simply says to enter a long if we get a long signal AND either (we are already short) OR (we are not in a trade because we have been stopped out)
BeAst767
@bennef, Awesome. How about barstate.isconfirmed when entering strategy.entry (or within study too) so you know the code has executed for the entire bar vs. asserted (went true) half way thru the bar, but goes false. Would you ever want to 'latch' your positionEntry logic halfway through the bar? I messaged TV Tech Support for this answer and can share that if you like.
bennef
@BeAst767, I have not investigated barstate.isconfirmed to be honest. The thinking behind my strategy is to react to the close of a bar, not to create a signal halfway through. Am I right in thinking I need barstate.isconfirmed in order to ensure my entries are the result of a closed bar and not because the entry criteria is met part-way through a bar?
BeAst767
@bennef, in version 3 since the declarations are all recursive, all your variables are constantly getting set to 0 and na and all the initial defaults each clock cycle. So barstate.isconfirmed and barstate.isnew is a way to evaluate if something happened that bar or not. Your thinking is correct, but the trouble is when it comes time to evaluate a quick exit like on a high wick , that long take profit cannot be captured or latched in the middle of the bar. There is literally like no code possible to latch or remember the event. TV Tech support suggested to me to use version 4 and thr declarations var for upcoming better compliance to mid bar events.
bennef
@BeAst767, Interseting. I do not utilise any take-profit in this script, the exit conditions are simply 1) when we get an opposing signal or 2) when we get stopped out.
Thêm nữa