Bimi, read all the posts. You'll then see my code, at least enough of it to see my logic.
1) Because of you, I do have a Flow Chart.
2) About the order sent 1 hour late: I SAW IT HAPPEN. There was no trade in the Data2 series for over 1 hour. When it finally traded, MC inserted that trade back in time over 1 hour. And then it proceeded to give a Signal there, which proved to be very profitable. (This was not during actual, real-money trading.) I have no record of it for I didn't know it was going to happen. I would have to take screen shots constantly, or record all day long as Big Mike suggested, to prove it to you. But I don't need to prove it to anyone. I saw it happen. And I see it happen on much smaller time periods all the time. I don't lie.
3) I don't even know what 'pseudo code' is.
4) Yes, for a 'variable map' I have a blank face.
5) For the response to this, read #2 again.
And you're right about all the debugging, etc., I must do. I'm trying to do that. But I was a grading and paving contractor during my working days. I was not a professional programmer. I've taught myself what little I know. I'm just a hard worker who often times looks for too many shortcuts.
I'm 66 years old and I still have not learned patience. So when I see things go constantly 'wrong', I really get angry. You look at what I programmed. It's on P.4, Post #79. (Since then I have changed it to try to work around the problems that have come up. I'm trying to use InsideBid and InsideAsk now. But I've run into problems there also.) If you can spot the problems that cause the time lag, then please let me know. I see nothing wrong myself. But then I'm old, worn-out, and have no patience. You're young, bright, and quick. I envy you.
In programming, nobody is a lier, the only lier is the fleeting intrabar variable.
There is no need to get hang up on the delayed order. It happened, we have to find out why.
There is no need worry about someone not believing you.
That's not the point of the exercise; we are here to code, not assign blame.
There are ways to insert audit trails in the code to track your variables, orders, conditions, etc.,
Once I have shown you how, you can do that to all the coding projects.
No need to pull the passive-aggressive routine...
We all have our challenges, I will leave my sob story for another day, another place.
Thank you very much for your post - it is very pertinent for me at my stage of the journey.
To date I have primarily been developing strategies with a fixed profit target and stop loss. I have introduced variable stop loss management which respond to changes in conditions (by moving the stop in the direction of the trade or exiting). This is all good.
I was thinking about either reducing the fixed target amounts to increase the % winning, maybe introducing multiple targets or somehow staying with winning trades for longer through trailing stops.
You seem to be recommending the trailing stop option?
Lots is written in futures.io (formerly BMT) about entries, but not much is written about trailing stops. Do you have any good suggestions for information sources. Perhaps you could explain about how tiered stops work? Any help or assistance you could provide would be very much appreciated.
I'll respond, but we shouldn't hijack this guy's thread. Maybe you can start a new thread on the topic.
Obviously you have a basic/simple trailing stop which has a fixed trail. Fixed trails offer a little more flexibility than simple fixed stops. However, the fixed trail itself presents some challenges and limitations. The larger the trail amount, the more forgiving it is to retracements (not exiting you earlier than you would have liked). However, a larger trail also means you give up more profit when the market finally moves against you for good (after the trend has ended). Pulling your stops in tight has the opposite tradeoff, you cling to more profit, but you might get stopped early out of trades that wanted to continue after a pullback, but you couldn't survive the retracement because your trail was too tight.
Tiered stops (fixed or trailing) simply involve placing a second stop once a threshold is reached. I highly recommend that you research "maximum favorable excursion" (MFE) as a percentage and how to do the analysis as to what the average MFE is for your trading results. This will allow you to set things like a second stoploss amount that overrides the first (locking in and ensuring at that point that you breakeven, take a small amount of profit, a medium amount of profit...etc...whatever you want).
You can also place a "floor" on your trails which essentially waits for a trade to reach a certain profit amount before activating the trailing stop. (essentially a tier for the trailing stop).
I've also developed my own parabolic and hyperbolic stops...which are essentially trailing stops that shrink following a parabolic or hyperbolic pattern. Basically, in order to overcome the issue in the first paragraph, you can have a trail start out wide and forgiving, but as the trade progresses, the size of the trail shrinks, locking in a certain amount of profit. If you shrink slowly at first, but then race to lock in profits after a few ticks...this will have favorable results in certain market conditions. If you have a wide trail at first that quickly shrinks at first, but then slows to a more reasonable pace later....that also has it's advantages, but only in certain markets.
The essence here is that you can familiarize yourself with any number of combinations of stops, trails, etc. Automation allows you to craft/code your stops to behave however you want. Only iniate upon certain conditions, etc.
I like to incorporate both a price action exit (based upon some action by the market, retracement, pullback, end of trend, etc) and then also protect it with a trailing stop that initiates on some floor amount. I also like to lock in a break even at some point. So at some points in a trade, I may have 3 different exits working.....one at the break even, one that's trailing and one that's waiting if the price action criteria are met. This allow the flexibility to let the trade continue, but if my price action criteria happen to slip and not catch it....or for whatever reason, my trail hasn't shrunk above break even yet.....etc, etc.
This is where trial and error comes in. You craft a strategy with an entry edge. You start to optimize the profit/loss amounts and you start "trying" different exit strategies to wring out more profit.
Don't fixate yourself on win%. You should concern yourself more with overall profit, net profit/trade, and profit/loss ratio.
I really don't care if the win% is 5%, as long as the strategy is profitable (to my liking), has acceptible drawdown, has a large profit/loss ratio and doesn't take 100 trades to make a dollar (high net profit/trade average).
"A dumb man never learns. A smart man learns from his own failure and success. But a wise man learns from the failure and success of others."
The following 4 users say Thank You to RM99 for this post:
I am very disappointed with MC 7. I was hoping it would have eliminated my backtesting (and FORWARD TESTING) bugs. But things are just the same.
Yes, MC 7 has some nice additions. But as far as acting on data tick by tick and posting Buy / SS signals timely and posting them at the correct price, forget it. At least for 2-point Range Bars, even on such a slow instrument as ES.
I wrote a work-around program to try to help MC eliminate the bugs that I was encountering. (I'll list the code below.) It uses InsideBid and InsideAsk, so that everything should be current. But just watching it run today, I took notes on what happened from 2:18 PM to 3:20 PM Central time.
Before I list what happened, for the day (since midnight), MC says the strategy made +2801 Net for 1 Contract of ES on 26 R.T.'s, with 100% Success Ratio.
Now the results from watching it run 'Live' for the time period shown above:
2:18 -- Should have gotten SS signal at 1323.00. MC finally gives the signal some minutes later, but inserts it 3 minutes Before my signal, at 1323.75.
2:32 -- Should have gotten Buy signal at 1322.75. MC finally gives the signal some minutes later, but inserts it 2 minutes Before my signal, at 1321.75.
2:36 -- Should have gotten SS signal at 1321.75. MC finally gives the signal 2 minutes later, but inserts it 3 minutes Before my signal, at 1322.75.
2:38 -- Should have gotten Buy signal at 1322.25. MC finally gives the signal 2 minutes later, but inserts it 1 minute Before my signal, at 1321.50.
2:44 -- Should have gotten SS signal at 1322.00. MC finally gives the signal 6 minutes later, but inserts it 1 minute Before my signal, at 1322.75.
3:00 -- Should have gotten Buy signal at 1323.25. MC finally gives the signal 3 1/2 minutes later, but inserts it 8 minutes Before my signal, at 1322.00.
3:06 -- Should have gotten SS signal at 1322.50. MC finally gives the signal 18 minutes later (After the market Closes!), but inserts it 2 1/2 minutes Before my signal, at 1323.75. This is totally unbelievable!
***** MultiCharts needs to address these problems. And they are huge problems. Now that MC 7 is out, their programmers have time to see why this happens. It is so wrong it is sinful. I will post my ACTUAL code below. I hope there are major flaws in it so that MultiCharts is NOT wrong.