I thought the way this done in WL6 was excellent, which involved what would now be Transaction properties:
double AutoProfitLevel
double RiskStopLevel
If either of these are non-zero for a Signal, the Order Manager would place closing Limit and/or Stop orders when the Signal was filled on the entry bar. Elegant!
double AutoProfitLevel
double RiskStopLevel
If either of these are non-zero for a Signal, the Order Manager would place closing Limit and/or Stop orders when the Signal was filled on the entry bar. Elegant!
Rename
Looks like this one will be slated for Build 10.
Will these 2 properties automatically flow through to the position thus created?
If not, please consider creating them for the Position object as well (as in WL6), would be very helpful, thanks.
If not, please consider creating them for the Position object as well (as in WL6), would be very helpful, thanks.
If I'm right, Cone said this one is for live trading. How can I close position at same candle Close price in backtesting?
Yes, you're right. Here's a design pattern for backtesting:
https://www.wealth-lab.com/Discussion/Buy-Sell-at-close-and-Entry-Bar-6081
And since this is a feature request thread, it would be optimal to continue the conversation in another topic.
https://www.wealth-lab.com/Discussion/Buy-Sell-at-close-and-Entry-Bar-6081
And since this is a feature request thread, it would be optimal to continue the conversation in another topic.
I guess I was premature earlier when I said build 10, but it's now floated to the top so it will be slated for build 16.
I've been waiting 300 years for this !!!!!!!!!!!!!
Hope this will make available LastOpenPosition (or LastPosition) object on 'bar' itself to use as needed.
The WL7 backtester won't have access to a Position object on the same bar as a signal (Transaction) is issued. This is because the Position object is not instantiated until the following bar.
Will we be able to assign a Profit Target and Stop on signal bar (subject to trade execution on next bar)?
Working through this, I think the old way of assigning values to a Transaction property does get us partly there. We can establish stop/profit levels based on the basis price. But we do not know the execution price at that point.
I'm thinking of providing a new Strategy overload method that will let you set a same bar stop and/or limit level based on either the basis or the execution price.
This would let us make this work in backtesting as well as live trading.
I'm thinking of providing a new Strategy overload method that will let you set a same bar stop and/or limit level based on either the basis or the execution price.
This would let us make this work in backtesting as well as live trading.
Wouldn't granular processing be sufficient to make it work for backtesting without the overload?
Good point, Robert!
In this vein may I request that granular processing be extended to use Daily bars if one is trading on Weekly bars; should be easy as Daily bars are always available.
In this vein may I request that granular processing be extended to use Daily bars if one is trading on Weekly bars; should be easy as Daily bars are always available.
I think we are mixing things up. Granular Processing is an optional feature, so it isn't connected to same bar orders. The new method that I'm introducing allows one to place limit and stop orders with the knowledge of the triggering order's execution price.
QUOTE:
...knowledge of the triggering order's execution price
Sounds good as Profit Target & Stops, if based on % move, are always off of the execution price (incl slippage, if any).
And Position size is always based on basis price as that's known beforehand and how one submits trade orders to broker.
Sounds like things are falling in place and backtesting will finally start mimicking real-life trading!
Your Response
Post
Edit Post
Login is required