Bars.MarketInfo: estimate bars for a day
Author: thodder
Creation Date: 10/3/2009 8:04 PM
profile picture

thodder

#1
I started to use this in some of my intraday strategies. For example, the following bit of code was useful to estimate bars for a day:
CODE:
Please log in to see this code.

(This code doesn't account for shortened trading days so it is only an estimate.)

On Saturday, Bars.MarketInfo is null, but I thought this was working fine during the week. I didn't see this in help, so I was wondering if it was safe to use.
profile picture

Cone

#2
QUOTE:
to estimate bars for a day:
How about not estimating, and get the exact number of bars for the current day?...

CODE:
Please log in to see this code.
profile picture

thodder

#3
I think Bars.MarketInfo was null due to the security I was using not the day of week, or time, I was doing the test. I got a null reference when I backtested symbol 'QQQQ' whereas symbol 'ADM' worked fine.

Initially I was using this calculation as the following:

CODE:
Please log in to see this code.


Mainly I was looking for a starting point for my loop when I had a combination of intraday bars and daily bars.

Cone, Bars.IntradayBarNumber will only give me the current bar number. I want to know how many bars for the current day. I'd like to have a test to get me the current bar number and then test how close that bar is to closing.

I've been trying to figure out what a good technique is to test for the last hour of the day. I may want to do special trading at the end of the day (but not SellAtClose). For example, SellAtLimit until the last hour of closing, and then switch to SellAtStop in case the last hour is going up, but then SellAtMarket in the last couple of bars.

If I know the closing time, I could use Date[bar].TimeOfDay to test against Bars.MarketInfo.CloseTimeNative.TimeOfDay. For example, action in the last 15 minutes of trading:

CODE:
Please log in to see this code.


These were just some ideas; however, Bars.MarketInfo doesn't appear to be the right variable to accomplish special trading at end of day at the moment.
profile picture

Eugene

#4
QUOTE:
I'd like to have a test to get me the current bar number and then test how close that bar is to closing.

Note that you can not know how many bars are there left to closing (no trade = missing bars, curbs in), so you can only estimate this number.
QUOTE:
I've been trying to figure out what a good technique is to test for the last hour of the day.

Maybe this could help?

Intraday / Multi-Time Frame | Keep from holding positions overnight
profile picture

thodder

#5
I hadn't considered the fact that there may be missing bars. I guess a time test is better than bars test when I do special processing for the end of day.

Eugene,

I don't think that example helps but I appreciate you pointing it out to me.

With the "Intraday / Multi-Time Frame | Keep from holding positions overnight", closing time is set by a variable. For backtesting, that will using the same closing time for all days and it doesn't really solve my problem (even Bars.MarketInfo would not handle the early closing days for backtesting). I would also have trouble running this through the Optimizer as it would try to change my closing time. I think I'm better keeping this as a hard-coded value than a variable at the moment.

Just a minor critique of "Intraday / Multi-Time Frame | Keep from holding positions overnight":
* Date[bar].TimeOfDay should work as good as function GetTime();
* Using [DateTime variable].AddMinutes(-15).TimeOfDay should do the same as AddIntegerTime() (what I did in my example code).

The main difference between "Intraday / Multi-Time Frame | Keep from holding positions overnight" and my approach is that my version was trying to use Bars.MarketInfo for the closing time whereas your example uses a parameter.

For backtesting purposes, I'm better off leaving a closing time as hard-coded than a parameter. When I go live, then I might have to add a parameter to handle those days where the market closes early -- what I was hoping to handle automatically with Bars.MarketInfo.
profile picture

Eugene

#6
Thanks for your suggestions.

QUOTE:
even Bars.MarketInfo would not handle the early closing days for backtesting

Why? It should. Here's an attempt to use that information in Community.Components:

Shortened Sessions
profile picture

thodder

#7
Bars.MarketInfo.CloseTimeNative and Bars.MarketInfo.OpenTimeNative do not use an index for the bar; therefore it can only provide one open and one close time. I do see Bars.MarketInfo.SpecialHours and Bars.MarketInfo.Holidays. Perhaps one of these could help me with the special closing times. I'll take a look at the Shortened.Sessions to see if that helps.

Still my main concern with Bars.MarketInfo is that it is undocumented and sometimes returns me a null reference. Is this something I can rely on in the future?
profile picture

Eugene

#8
QUOTE:
Bars.MarketInfo.CloseTimeNative and Bars.MarketInfo.OpenTimeNative do not use an index for the bar; therefore it can only provide one open and one close time.

Among the rest, MarketInfo provides regular open/close times and a list of session with special hours (i.e. short sessions). Take a look at Markets.xml in the root of Wealth-Lab's data folder: that's the source of Bars.MarketInfo.
QUOTE:
Still my main concern with Bars.MarketInfo is that it is undocumented and sometimes returns me a null reference.

As trading doesn't typically happen on Saturdays, this must be the reason for returning a null.
QUOTE:
Is this something I can rely on in the future?

Definitely, MarketInfo is important and is here to stay.
profile picture

Eugene

#9
QUOTE:
Why? It should. Here's an attempt to use that information in Community.Components:

Shortened Sessions

Will be depreciated in the next release of Community Components.
This website uses cookies to improve your experience. We'll assume you're ok with that, but you can opt-out if you wish (Read more).