How to close order in the same bar?

Questions about MultiCharts and user contributed studies.
tradinghumble
Posts: 38
Joined: 11 Jun 2006

How to close order in the same bar?

Postby tradinghumble » 21 Apr 2010

Hi, I have a strategy that I'm using to backtest gaps on the ES using Daily Bars and I look at tomorrow's open for entry...

it's running fine on TS but I get the following error in Multicharts:

"Cannot use next bar's price (date or time) and close order in the same signal"

I'm running MC 5.5. Can anyone give me a pointer on what I may be doing wrong?

Thanks in advance.

sharp2be
Posts: 5
Joined: 21 Apr 2010

Postby sharp2be » 21 Apr 2010

Tradinghumble, do you mean close the "position" no the order right? Just want to make it clear for other members here.

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 22 Apr 2010

If you use EasyLanguage like "buy next bar at open" and "sell this bar at close" in the same EasyLanguage strategy, MultiCharts cannot do that, while TS can. That's a known situation - I'm not sure it's exactly a bug, although it's a bug from the perspective of the desire for 100% TS compatibility. It's generally a problem to trade strategies that do things like "sell this bar at close" in real-time, because how can you really do that? The closing price of the bar isn't known until it's closed, and then, of course, it's too late to guarantee a sell at that price and on that bar. So, it's possible to make some strategies that look quite attractive in back-testing in this way, but they tend not to perform as well in real-time because the "reality" of it is that the trades go into the market later in time than they do in back-testing, because the platform has to wait until the bar's actually closed to do it.

MultiCharts seems to have taken the stance that you can't really be "at the close" of one bar and "at the open" of the next bar at the same time, and that's understandable (even if TS didn't restrict in this way). It's probably the "right thing" to do, except that of course it would be great if EasyLanguage that ran on TS all ran on MultiCharts also.

Although there are some who would definitely disagree with me about this (especially who have existing code already this way that they like), I would generally recommend not to code things like "sell this bar at close" in new work at all, because it's a bit of a trap insofar as it distracts you during the system development process in that it looks good, but it's going to be an issue later when you want to go live, and will either not work, or can introduce substantial differences for some bar types compared to historical performance because of the way the fill simulations work, unless you use all market orders and figure in generous slippage - in which case, you're really not better off to use "at close" anyway.

One area where this comes up somewhat frequently though is system testing on daily bars, where the designer wants to get in/out "at the close" or thereabouts, and doesn't want to use intraday data to do the testing (often because it isn't available). Thus, this is a shortcut to get an approximate answer, with the understanding that the reality is undoubtedly a little different. In these cases, it's almost always going to be better to do the simulation using intraday data (for instance as an example, placing an order on 1 minute bars to sell next bar a open at the 3:55pm bar for RTH US equities instead of sell this bar at close on a daily bar), but it's going to take longer to run, and it's going to be limited by the availability of intraday data.

Perhaps in an ideal world, MultiCharts would let you do this just as TS does, so that the language is more compatible, but give you a warning that live performance won't be as reliable in this configuration, rather than simply stopping it altogether, although, it's understandable if they didn't think it was worth spending a lot of time on this given that it may not be an area where there's substantial future focus in development and the "at close" keywords are largely a result of legacy.

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 22 Apr 2010

Let's look at the specific example you gave - it "backtests gaps". The developer probably did something like both a "buy next bar at close + x stop" for a breakout or "sellshort next bar at close + x limit" for mean reversion for the entry so they would only get in when there's a gap, then they also put in "sell this bar at close" and "buytocover this bar at close" so they could close that position, if it got opened, at the close of the same ("next" relative to the word close being used to determine the entry offset price) bar as the entry fill. Their goal was likely to measure the range of those bars where the condition of an x point gap was true, assuming the trader were in effect able to ride this movement for the entire day. This type of thing is often a research question, rather than necessarily a literal trading strategy to deploy alone.

In TS, this more or less works. In MultiCharts, the platform sees the orders involving "at close" and doesn't distinguish them as specifically exits, so it essentially sees that you're trying to simultaneously put in an order at the open and close of the same bar, and says to you, no, you cannot do that because it can't be known to be this bar's open and close at the same moment (in general - other than 1 tick bars and some other special cases).

Hopefully that helps explain - that is essentially what is happening in this case I believe, and why it's happening.

tradinghumble
Posts: 38
Joined: 11 Jun 2006

Postby tradinghumble » 22 Apr 2010

Bruce, thank you so much for taking the time to write such a detailed explanation. You are absolutely right regarding your comment that this procedure will work on TS but not on Multicharts.

Regarding the gap fading backtest I belive the only time we 'break' the rule is when we look at the next day's OPEN, which does not necessarily mean we are relying on it for the trade... the Open will be a decision making point.

The logic for the gap fade is quite simple and in my little experience developing trading systems it does not look into the future, here's what I had in mind:

Using Daily Bars:

tomorrowOpen = Open next bar;
if tomorrowOpen < Close then
Buy 1 contract next bar at the Open

if MarketPosition = 1 then begin
Sell 1 contract at myStop stop;
Sell 1 contract at myTarget limit;
end;

Note that the code above is not necessarily valid, just the idea...

User avatar
TJ
Posts: 7740
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 1033 times
Been thanked: 2221 times

Postby TJ » 22 Apr 2010

for TS:

"buy/sell this bar at close" is for backtest only.
It is stated in the manual.
This order will not execute in live mode.

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 22 Apr 2010

What you should do to re-architect this in a way that's not in question is instead:

buy 1 contract next bar at close - (minmove/pricescale) limit;
sell 1 contract at myStop stop;
sell 1 contract at myTarget limit;

and run this on daily bars. Let me explain why this would work and what you posted would not in MC. First, the "buy at ... limit" is in effect similar to what you're saying when you say tomorrowopen < close - you're specifying you're only willing to pay a price that's a tick below today's closing price. The sell statements are explicitly exits, so they will only execute if you're in a long position. In this way, you're still accomplishing essentially the same thing, yet, you're never attempting to execute on this bar's close.

For the reasons I described above, I would recommend to avoid using "this bar at close" terminology - what I outlined above here will accomplish the same thing you want to accomplish, but without the dangers or issues introduced by using "this bar", and without having to worry that something completely different is needed for forward testing.

Note also that you don't need the "if marketposition = 1 then..." because the sell statements will only execute if you are in a long position. By eliminating this clause from your code, you can place the exits for the next bar before you get a fill (protected by the fact that they're exit only), and thus, it will still work identically without a bar delay.

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 22 Apr 2010

Regarding TS, I don't think the "this bar at close" terminology is particularly encouraged - in fact I would say it's fairly actively discouraged for the reasons described above, and it's still in there only because they didn't want to orphan legacy code that uses it. I think it's fair to say they would not encourage new code to be written that uses it.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 104 times

Postby janus » 22 Apr 2010

Regarding TS, I don't think the "this bar at close" terminology is particularly encouraged - in fact I would say it's fairly actively discouraged for the reasons described above, and it's still in there only because they didn't want to orphan legacy code that uses it. I think it's fair to say they would not encourage new code to be written that uses it.
A straight buy or sell "this bar at close" on a study that updates on every tick in real-time could be interpreted as an "at market" order on the current bar. At the moment the only way to create an "at market" order is to place it at the next update tick, which might be minutes away in a very quiet market. It would be much better if the could make "this bar at close" work this way to get as close as one can get to a true "at market" order.

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 22 Apr 2010

I think that may be a bit of a different issue, in that there are quite special problems introduced in attempting to simulate fills in low liquidity conditions - not just for market orders but for limits as well. There are some models that allow fills to be made with a simulated latency delay e.g. X seconds later, a fill occurs at the best inside bid/ask at that time (where X is something you would base on a test run of entries of that size during similar market conditions on a live account - during this same run, you would likely also be measuring slippage in dollars in addition to the timing), but these are very specialized cases in comparison with this general question about "this bar at close" vs. "next bar at open" which is more of an architectural issue for platforms like TS/MC where the fills are all predicated on bar data rather than the underlying tick data, and where the design generally isn't geared for 1 tick bars or IOG but rather they're treated as just an instance of the more general case.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 104 times

Postby janus » 22 Apr 2010

That's all understandable but it doesn't prevent MC implementing a true "at market" order for those if us who are prepared to use it despite some of the issues. After all, someone trading manually would be disgusted with a platform that prevented them from submitting an "at market" order no matter how quiet the market is. For example, they would be prepared to take the larger than usual spread simply because they want to close a position at a profit, provided they know there are sufficient contracts on the queue to absorb the traders quantity at a reasonable average price.

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 22 Apr 2010

I understand what you're going for, and it sounds like you're saying you're willing to be responsible for your own assessment of (possibly significant) slippage and take your own responsibility for the fact that sometimes depending on conditions it could be a good while before you get an execution in reality, even if the back-test fill done in this way is instantaneous. I'm not opposed to MC implementing this (especially to try to match more closely TS's behavior, since they pretty much define how EL "should work"), simply reflecting on some of the considerations and why the more general case for programming "this bar at close" usually isn't the way to go if it can be avoided.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 104 times

Postby janus » 22 Apr 2010

Provided one has all the necessary information, which is possible with MC, there is no reason why we can't have a true "at market" order type. If the information is not available then it should be anyway since the whole point of any ATS is to take over manual trading.

sharp2be
Posts: 5
Joined: 21 Apr 2010

Postby sharp2be » 22 Apr 2010

What you should do to re-architect this in a way that's not in question is instead:

buy 1 contract next bar at close - (minmove/pricescale) limit;
sell 1 contract at myStop stop;
sell 1 contract at myTarget limit;

and run this on daily bars. Let me explain why this would work and what you posted would not in MC. First, the "buy at ... limit" is in effect similar to what you're saying when you say tomorrowopen < close - you're specifying you're only willing to pay a price that's a tick below today's closing price. The sell statements are explicitly exits, so they will only execute if you're in a long position. In this way, you're still accomplishing essentially the same thing, yet, you're never attempting to execute on this bar's close.

For the reasons I described above, I would recommend to avoid using "this bar at close" terminology - what I outlined above here will accomplish the same thing you want to accomplish, but without the dangers or issues introduced by using "this bar", and without having to worry that something completely different is needed for forward testing.

Note also that you don't need the "if marketposition = 1 then..." because the sell statements will only execute if you are in a long position. By eliminating this clause from your code, you can place the exits for the next bar before you get a fill (protected by the fact that they're exit only), and thus, it will still work identically without a bar delay.
Bruce / TJ - I should add here that I'm only interested in Backtesting the gap fades, not trading it live for now.

I think I understood your idea around using "buy 1 contract next bar at X limit;" and also understood the fact that I won't need to check for marketposition, make sense.

The part I'm struggling with is that I need to know tomorrow's Open in order to make a decision of taking the trade (in real life, I will check the market 20 mins before the open before placing a trade)...

The open is important to me as it will tell me things like:

1. Where is the market opening relative to yesterday's OHLC
2. Gap size
and other information...

again, purpose is only backtesting but MC is not letting me run such a code. By entering next bar using a limit I'm not given the opportunity to really make a decision on the variables/factors I outlined above.

Your thoughts / ideas are appreciated.

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 22 Apr 2010

There's more than one way to handle what you're wanting to do, but personally, I would probably just write it to operate on intraday data such as 1 minute bars. When date <> date[1] you're at the new day's open, and you can get the gap simply by looking at open and close[1] with no difficulties like we're talking about above. In this way, you can also do a good backtest of your decision making process X minutes before the close as well.

sharp2be
Posts: 5
Joined: 21 Apr 2010

Postby sharp2be » 22 Apr 2010

There's more than one way to handle what you're wanting to do, but personally, I would probably just write it to operate on intraday data such as 1 minute bars. When date <> date[1] you're at the new day's open, and you can get the gap simply by looking at open and close[1] with no difficulties like we're talking about above. In this way, you can also do a good backtest of your decision making process X minutes before the close as well.
Bruce, I've tried that it worked initially but I ran into another problem with Multicharts (no on TS) ... for my tests I needed 5-day ATR and 50d MA and I added Data2 as Daily Bars in order to make it easier to calculate. Problem is that MC would then complain about the fact that the study was referencing more bars than I had specified in the Signal properties (even though I specified more bars than I was really referencing in my code)... apparently is a bug.

User avatar
TJ
Posts: 7740
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 1033 times
Been thanked: 2221 times

Postby TJ » 22 Apr 2010

first thing first...

to calculate a logic, you need data.

eg.
the last trading price (also called current price),
previous close,
20 period moving average, etc.,

MultiCharts has no way of accessing future data.
eg. tomorrow's opening.


to incorporate the opening price into your calculation,
you must do the calculation AFTER the opening price has been posted.

if you shift the timing in your mind... you can make the logic work.

calculations can only be done NOW... ie the current bar.

when you are looking at the current bar,
the calculation is done on THIS bar's opening, not next bar's opening.

the gap is the difference between
this bar's opening and LAST bar's close.


hope this will get you started.

sharp2be
Posts: 5
Joined: 21 Apr 2010

Postby sharp2be » 22 Apr 2010

first thing first...

to calculate a logic, you need data.

eg.
the last trading price (also called current price),
previous close,
20 period moving average, etc.,

MultiCharts has no way of accessing future data.
eg. tomorrow's opening.


to incorporate the opening price into your calculation,
you must do the calculation AFTER the opening price has been posted.

if you shift the timing in your mind... you can make the logic work.

calculations can only be done NOW... ie the current bar.

when you are looking at the current bar,
the calculation is done on THIS bar's opening, not next bar's opening.

the gap is the difference between
this bar's opening and LAST bar's close.


hope this will get you started.
TJ - I understand your explanation about doing calculations on the current bar, however, in order to have accurate backtest results I would need to buy at the Open and MC won't let me have an order such as "Buy 1 contract at the Open" because is inside the same Daily bar...

If you have any ideas on how to work around this issue using Daily bars I would appreciate it ... if not, I'm left with no choice but use Intraday data and it seems there's a bug with the MaxBarsBack indicators will reference, as per my previous post.

User avatar
TJ
Posts: 7740
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 1033 times
Been thanked: 2221 times

Postby TJ » 22 Apr 2010

there is no such a thing as "accurate backtest results".

backtest is NEVER real.

there are 2 things you can achieve with backtest:
1. verify a concept,
2. test a segment of code

separating the two will save you some time and headache.

User avatar
TJ
Posts: 7740
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 1033 times
Been thanked: 2221 times

Postby TJ » 22 Apr 2010

...
If you have any ideas on how to work around this issue using Daily bars I would appreciate it ...
don't bang your head against the wall...

User avatar
TJ
Posts: 7740
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 1033 times
Been thanked: 2221 times

Postby TJ » 22 Apr 2010

...and it seems there's a bug with the MaxBarsBack indicators will reference, as per my previous post.
can you give me a link to this thread?

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 22 Apr 2010

I think you should do this via intraday bars such as 1 minute bars if possible. It's possible the maxbarsback bug you are referencing is a misunderstanding - let's see the code you're using to try to do this and perhaps we can help.

tradinghumble
Posts: 38
Joined: 11 Jun 2006

Postby tradinghumble » 22 Apr 2010

...and it seems there's a bug with the MaxBarsBack indicators will reference, as per my previous post.
can you give me a link to this thread?
TJ - sorry, don't have a thread, the information is based on a chat with support. I will post some code I'm using to reproduce the problem... basically using 5-Min for Data1 and Daily for Data2. Will gather the code and post it later.

Thanks for your help so far.

Spaceant
Posts: 254
Joined: 30 May 2009
Has thanked: 1 time
Been thanked: 3 times

Postby Spaceant » 25 Apr 2010

............... why the more general case for programming "this bar at close" usually isn't the way to go if it can be avoided.

Bruce,

Are you saying that we should use Limit Order instead? e.g. Buy next bar at Close Limit

If so, please take a look at the Scenario 3 my previous post: http://forum.tssupport.com/viewtopic.php?t=6803

Well, you will surely miss some trades which are often profitable ones (I beg you these would be big profits!!) based on my actual experience!! As you can imagine that if it is a fast market and there is a gap up above the previous bar close (no matter whether it is just a 1 point gap up or bigger), MC will never execute the buy order even you check the boxes to convert to market orders after X seconds if the market is one-sided up, and often in high speed, and price never touches back the previous close.

Frankly, I now use market orders instead knowing that the executed prices would be less favorable, but I don't want to miss these type of trades.

I have made a formal request to TSSupport to provide an optional feature to really convert the limit order to a market order after X seconds even the price will never touches the previous price close (in addtion I request the Stop Limit Order). But the answer is:
We discussed this feature request with engineers and we are not sure we will implement it in the nearest future.

For sure, this is not the matter of next 3-4 months.

I'm sorry about that, really.

In case later this year we will decided to imrove this - I'll let you know.
Perhaps, they consider that not so many people want this feature. Well, if you like this feature, send a message to them to request it to expedite the development!!

BTY, I have developed a set of codes that do the job using GV DLL. Apparently, they can do the job as I want, but I still feel that this is not perfect yet and needs testing before I publish them. I probably will send one or two folks, who have discussed these and expressed interest in one of the previous posts, to test.

Anyone interested, pls PM me and I will send you the code.

Sa

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 25 Apr 2010

Bruce,

Are you saying that we should use Limit Order instead? e.g. Buy next bar at Close Limit
The discussion above was mostly regarding back-testing and whether a fill would occur at the current bar's closing price when the order was placed (e.g. a fill that takes zero time, unlike the real world) or at the open of the next bar (e.g. the next tick's price for intraday bars - slightly more realistic for intraday bars but still an issue, and an issue for daily bars if you're planning to place an order BEFORE the day's close unlike the back-test which in the case of "this bar at close" is able to magically get an order in exactly at the daily closing price yet have a 100% chance of fill on daily bars unlike real life) - in real-time "buy next bar at market" will get whatever fill the market provides - it doesn't wait for the next bar to end or even begin - it simply sends the order when the current bar closes. If the platform supported "buy this bar at close" it would do the exact same thing - both would send the order to market right away in real-time trading, and there would be no difference in fill. The difference has to do with how in back-testing a fill would be simulated.

Regarding converting limit orders to market if it starts to run away from you, you can do this using IOG by simply tracking the elapsed time, provided it's a liquid market.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 104 times

Postby janus » 25 Apr 2010

- in real-time "buy next bar at market" will get whatever fill the market provides - it doesn't wait for the next bar to end or even begin - it simply sends the order when the current bar closes. If the platform supported "buy this bar at close" it would do the exact same thing - both would send the order to market right away in real-time trading, and there would be no difference in fill. The difference has to do with how in back-testing a fill would be simulated.
I wasn't sure if this is true but now that you stated it and I thought about it some more, I think you are right. Still, I prefer a real "at market" order especially in cases where the market is really slow. I shudder to think what a traditional manual trader would think if they found out that his or her "at market" orders had to be delayed until someone else made a trade first. I'm sure most would be furious even if most of the time it would make no difference. It's the principle of the matter. If a trader wants to submit an "at market" order right now before the next tick update, it's well in their rights to expect any trading platform, manual or automatic, to provide the trader that functionality, no matter how little difference it makes; simply because sometimes it may make a significant difference.

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 25 Apr 2010

To be clear, all orders go into the market immediately in real trading when the order is given to place them, as well as during back-testing. The only question is how back-testing fills are simulated (how it determines when those orders that have been placed are filled) in low liquidity conditions, when there may not be another trade for some time. It sounds like you are saying for back-testing you want it to fill immediately even though no other traders' trades took place in the historical data until later, and to be clear, that's all we're talking about here. There's no live trading issue or question that I know of in this regard - the orders are sent immediately and the question is only about how long the back-testing fill simulation should wait before assuming you got a fill.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 104 times

Postby janus » 25 Apr 2010

I've confused you. I'm referring to real-time trading only, you are discussing back testing, which as we all know will never produce the same results, and as far as I'm concerned is near enough for all but the very active scalp traders.

Spaceant
Posts: 254
Joined: 30 May 2009
Has thanked: 1 time
Been thanked: 3 times

Postby Spaceant » 25 Apr 2010

........ If the platform supported "buy this bar at close" it would do the exact same thing - both would send the order to market right away in real-time trading, and there would be no difference in fill. The difference has to do with how in back-testing a fill would be simulated.
This is definitely true.
Regarding converting limit orders to market if it starts to run away from you, you can do this using IOG by simply tracking the elapsed time, provided it's a liquid market.
This is what I coded. Well, the question is how to implement this IOG counting inside a non-IOG strategy. I just tried to separate them into two using GV DLL. Don't know if there is a way to combine them into one as the original non-IOG strategy would be affected when IOG is enabled, at least the signals are given in different ways which woud complicate the executions, or wouldn't do the same as they are supposed to be.

Bruce, do you know any way without using GV DLL or related tools?

Sa

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 26 Apr 2010

I've confused you. I'm referring to real-time trading only, you are discussing back testing, which as we all know will never produce the same results, and as far as I'm concerned is near enough for all but the very active scalp traders.
As far as I am aware there is no delay issue at all with real-time trading. All orders are sent immediately at the close of the bar, whether they're "buy this bar at close" (when platform has support) or "buy next bar at open". The difference between "buy this bar at close" and "buy next bar at open" is only for back-testing in determining whether there's a delay on the simulated fill. (Separate from the issue of whether MC supports "buy this bar at close" in real-time.)

Since you say you're only concerned with real-time trading, it's unclear to me why you think there is an issue at all, since there is no delay.
Last edited by Bruce DeVault on 26 Apr 2010, edited 2 times in total.

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 26 Apr 2010

Regarding converting limit orders to market if it starts to run away from you, you can do this using IOG by simply tracking the elapsed time, provided it's a liquid market.
This is what I coded. Well, the question is how to implement this IOG counting inside a non-IOG strategy. I just tried to separate them into two using GV DLL. Don't know if there is a way to combine them into one as the original non-IOG strategy would be affected when IOG is enabled, at least the signals are given in different ways which woud complicate the executions, or wouldn't do the same as they are supposed to be.

Bruce, do you know any way without using GV DLL or related tools?

Sa
Have you considered making your strategy IOG, but putting the bulk of your logic inside of an "if barstatus(1) = 2 then begin... end;" block? The barstatus(1) = 2 will only be true at the close of each bar, and thus, the strategy will essentially only be evaluated for this section on bar completion.

Spaceant
Posts: 254
Joined: 30 May 2009
Has thanked: 1 time
Been thanked: 3 times

Postby Spaceant » 30 Apr 2010

Hi Bruce,
Regarding converting limit orders to market if it starts to run away from you, you can do this using IOG by simply tracking the elapsed time, provided it's a liquid market.
Do you have any code that can track the elapsed time?

I have done some tesing on my code which sometimes works, but sometimes it doesn't. I just don't know why.... hope you can give me some inputs so I can resolve it more easily.

Sa

cyberdad
Posts: 36
Joined: 10 Aug 2009

Postby cyberdad » 30 Apr 2010

Interesting thread. I only use "sell/buy this bar at Close" in the routines that determine if UPS Batteries are low.
It seemed logical at the time to exit all positions the soonest possible.

I even remember testing it (just with demo account though) and MC did exit all positions prior to exiting. I suppose I missed something.

Anyway, thanks for the info, I guess its back to "next bar at Market" for UPS battery low...

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 30 Apr 2010

Hi Bruce,
Regarding converting limit orders to market if it starts to run away from you, you can do this using IOG by simply tracking the elapsed time, provided it's a liquid market.
Do you have any code that can track the elapsed time?

I have done some tesing on my code which sometimes works, but sometimes it doesn't. I just don't know why.... hope you can give me some inputs so I can resolve it more easily.

Sa
Check the keywords ComputerDateTime, CurrentTime and CurrentTime_s. What I would suggest is save a copy of ComputerDateTime when you want to start timing in an intrabarpersist variable, and then later when you want to measure elapsed time, you can simply subtract that saved value from the current value of ComputerDateTime which gives you a difference in fractional elapsed days, which you can then multiply by 24 * 60 * 60 to get a difference in seconds.

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 30 Apr 2010

Interesting thread. I only use "sell/buy this bar at Close" in the routines that determine if UPS Batteries are low.
It seemed logical at the time to exit all positions the soonest possible.
Right, I know it probably seems like that would be faster, but really, it isn't... because in real-time, "next bar at open" doesn't wait until the next open to send the order. The "at open" is just how it simulates fills in back-testing, which isn't what you're concerned with in your UPS battery low situation.

Spaceant
Posts: 254
Joined: 30 May 2009
Has thanked: 1 time
Been thanked: 3 times

Postby Spaceant » 04 May 2010

When tracking the elapsed time, I tried to identify the "Signal Start" (in a 5-min chart before counting the time), LEStart and SEStart in my code. But I don't know why the code doesn't work!!

The following Strategy is applied to a chart with USD.JPY, in a 5min chart.
[IntrabarOrderGeneration = True];

Vars:MM(0),TT(0),SetRtn(0),
LE(0),SE(0),LEStart(0),SEStart(0);

If barstatus(1)=2 then begin
MM=FracPortion(Time/100)*100;

LE=Iff(MM=5 or MM=15 or MM=25 or MM=35 or MM=45 or MM=55,1,0);
SE=Iff(MM=0 or MM=10 or MM=20 or MM=30 or MM=40 or MM=50,1,0);
End;

LEStart=Iff(LE=1 and LE[1]=0,1,0);
SEStart=Iff(SE=1 and SE[1]=0,1,0);

SetRtn=GVSetNamedInt("LEStart",LEStart);
SetRtn=GVSetNamedInt("SEStart",SEStart);
SetRtn=GVSetNamedInt("LE",LE);
SetRtn=GVSetNamedInt("SE",SE);
I want to locate the Signal Starts, LEStart and SEStart. BUT, it doesn't seem working as I use GV to feed LEStart and SEStart out to 1 second chart. As shown in the top indicator of left chart, it doesn't show any signal.
[IntrabarOrderGeneration = True];
Vars:LEStart(0),SEStart(0),ErrorCode(0);

ErrorCode=-999;
LEStart=GVGetNamedInt("LEStart",ErrorCode);
SEStart=GVGetNamedInt("SEStart",ErrorCode);

Plot1(LEStart);
Plot2(-SEStart);
What makes me pluzzling is that, when I feed the raw signals, LE and SE, out to a 1 second chart and do the same procedure to idenfy the Signal Starts, it works... see the lower indicator of the left chart.
[IntrabarOrderGeneration = True];
Vars:LE(0),SE(0),LEStart(0),SEStart(0),ErrorCode(0);
ErrorCode=-999;

LE=GVGetNamedInt("LE",ErrorCode);
SE=GVGetNamedInt("SE",ErrorCode);

LEStart=Iff(LE=1 and LE[1]=0,1,0);
SeStart=Iff(SE=1 and SE[1]=0,1,0);

Plot1(LEStart);
Plot2(-SEStart);
Can anyone kind enough to point out what mistake I have made!!
Attachments
SignalTest.JPG
(223.93 KiB) Downloaded 3091 times

User avatar
TJ
Posts: 7740
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 1033 times
Been thanked: 2221 times

Postby TJ » 04 May 2010

the keyword "TIME" refers to the bar ending time of that particular chart.


at MC, press the [F1] key,

look under
PowerLanguage> Keyword Reference> Date and Time Routines

you will see a list of real time keywords.

Spaceant
Posts: 254
Joined: 30 May 2009
Has thanked: 1 time
Been thanked: 3 times

Postby Spaceant » 04 May 2010

Have you considered making your strategy IOG, but putting the bulk of your logic inside of an "if barstatus(1) = 2 then begin... end;" block? The barstatus(1) = 2 will only be true at the close of each bar, and thus, the strategy will essentially only be evaluated for this section on bar completion.
TJ,

I know that the TIME is referred to the bar ending time, that was intened to create the LE and SE signals.

This is same as:
If Condition1 then buy next bar at market (or a Close Limit);

If Condition1 is true at this bar ending, then the strategy will conduct the buy / sell statements. What my code is doing is to create a LE satisfied (same as condition1) condition at br ending at time = 5, 15, 25, 35, 45, and 55 mins; while SE satisfied condition at time = 0, 10, 20, 30, 40 mins. This part creates the signals to be tested.

Suggested by Bruce, I added the "if barstatus(1) = 2 then begin... end;" .....

Spaceant
Posts: 254
Joined: 30 May 2009
Has thanked: 1 time
Been thanked: 3 times

Postby Spaceant » 05 May 2010

To illustrate more, with the Strategy code is unchanged as shown in the earlier post on top, also I have amended the other two indicators as follows:

Top Indicator:

Code: Select all

[IntrabarOrderGeneration = True];

Vars:LE(0),SE(0),LEStart(0),SEStart(0),ErrorCode(0);

ErrorCode=-999;

LE=GVGetNamedInt("LE",ErrorCode);
SE=GVGetNamedInt("SE",ErrorCode);
LEStart=GVGetNamedInt("LEStart",ErrorCode);
SEStart=GVGetNamedInt("SEStart",ErrorCode);

Plot1(LEStart*2,"LEStart",Red);
Plot2(-SEStart*2,"SEStart",magenta);
Plot3(LE,"LE",Yellow);
Plot4(-SE,"SE",Green);

Bottom indicator:

Code: Select all

[IntrabarOrderGeneration = True];
Vars:LE(0),SE(0),LEStart(0),SEStart(0),ErrorCode(0);
ErrorCode=-999;

LE=GVGetNamedInt("LE",ErrorCode);
SE=GVGetNamedInt("SE",ErrorCode);

LEStart=Iff(LE=1 and LE[1]=0,1,0);
SeStart=Iff(SE=1 and SE[1]=0,1,0);

Plot1(LEStart*2,"LEStart",Red);
Plot2(-SEStart*2,"SEStart",magenta);
Plot3(LE,"LE",Yellow);
Plot4(-SE,"SE",Green);
As you can see, only the bottom indicator can identify / spot the Signal Starts (the spikes), while the top indicator is not able to show them.

Also, both show the "raw signals", i.e. the end-of-bar signals which should last for 5-min. For example, when Time=5, the LE = 1, which should last for the next bar (or 5 to 10 min). The LE (and SE) signals are correctly shown.

PROBLEM THAT I AM FACING: The code inside the IOG Strategy is not working on idenfiying the Signal Starts.

Can anyone help me on that?
Attachments
SignalTest1.JPG
(229.22 KiB) Downloaded 3089 times

User avatar
TJ
Posts: 7740
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 1033 times
Been thanked: 2221 times

Postby TJ » 05 May 2010

When tracking the elapsed time, I tried to identify the "Signal Start" (in a 5-min chart before counting the time), LEStart and SEStart in my code. But I don't know why the code doesn't work!!...
Can anyone kind enough to point out what mistake I have made!!
I ran the code this morning,
I saw signals on both subcharts. (HSI)

Being an exceptionally busy day today, I did not have time to investigate the detail, and I closed the charts at lunch time without making a screen save.

I can test it again tomorrow.

User avatar
TJ
Posts: 7740
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 1033 times
Been thanked: 2221 times

Postby TJ » 05 May 2010

When tracking the elapsed time, I tried to identify the "Signal Start" (in a 5-min chart before counting the time), LEStart and SEStart in my code. But I don't know why the code doesn't work!!
...
Can anyone kind enough to point out what mistake I have made!!
I tested them on ES today...
the indicator #1 made one and only one signal all day.
Attachments
spaceant-es-test1.png
(172.99 KiB) Downloaded 3101 times

Spaceant
Posts: 254
Joined: 30 May 2009
Has thanked: 1 time
Been thanked: 3 times

Postby Spaceant » 05 May 2010

TJ,

Well, glad to know that indicator #1 is working, though it only worked once all day, as the logic is there.

I am not sure what has been wrong as indicator #1 and #2 are the same in terms of the logic, the only difference is where the code is compiled - one in the IOG enabled strategy while another one is compiled outside. That makes me pluzzling.

There should be something missing or .......

Sa

User avatar
TJ
Posts: 7740
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 1033 times
Been thanked: 2221 times

Postby TJ » 05 May 2010

I have them running on HSI right now,
so far nothing on indicator #1 has fired.

Spaceant
Posts: 254
Joined: 30 May 2009
Has thanked: 1 time
Been thanked: 3 times

Postby Spaceant » 06 May 2010

I have them running on HSI right now,
so far nothing on indicator #1 has fired.
Me too, either something wrong / missing or the indicator is not reliable!!??

User avatar
TJ
Posts: 7740
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 1033 times
Been thanked: 2221 times

Postby TJ » 06 May 2010

again, my absent minded head shut down MC before looking at your chart...
will try ES again this morning.

:-(


Return to “MultiCharts”