Hi All, Apologies in advance for such a naive question but I am wearing body armor so shoot me.

I've researched the forums reading about the detection of gaps from the prior day's close to the opening intraday bar of the current day... presumably a 1 minute bar, but the code is always really, to me, complex. So the question is:

If the system is delivering a dataseries of 1 minute bars which is being updated every minute then isn't the last bar in the series Bar.Count-1 the current bar always? And if this is true and you start the monitor before the market opens and look for the first bar with data (assuming that the system provides blank or zero bars until the real open occurs) isn't this the opening bar of the day for the given symbol? Or if the system is only delivering bars when one is actually created in the market would not the first updated bar similarly be the opening bar.

In any event, to compare the prior day's close to the current 1 minute open would it not just be comparing the first bar you get of the day as in above with the prior bar:

Bars.Count-1 vs Bars.Count-2

?

Again forgive the naivety but the dataseries for intraday data have me confused whereas daily data seems more understandable.

Thanks to all for your patience.

QUOTE:
isn't the last bar in the series Bar.Count-1 the current bar always?

Correct.

QUOTE:
assuming that the system provides blank or zero bars until the real open occurs

Nothing happens in the Strategy Monitor at the open. The S. Monitor schedules to grab the bar that just ended and adds it to the "chart"; that bar's number is Bar.Count - 1. So, for a 5 minute chart, the S. Mon. is just sitting idle from 09:30 to 09:35. At 09:35, the bar is requested, and the opening value of that bar is the opening price of the day.

QUOTE:
Bars.Count-1 vs Bars.Count-2

If you knew your were processing the first bar of the day, that's correct.

Here is a handy statement to get the bar number of the first bar of the day - assumes you're processing in the loop with bar as the index:

CODE:
Please log in to see this code.

Also you know that you're processing the first bar of the day if Bars.IntradayBarNumber(bar) == 0

QUOTE:
the dataseries for intraday data have me confused whereas daily data seems more understandable.

There is a little more work usually to code intraday systems, but the DataSeries concept is exactly the same no matter the scale.

@Cone thank you for your reply and for clarifying.

What I did not understand is that there is, apparently, no 'trigger' by the internals of WLP that 'delivers' a bar automatically whenever one is complete, but rather the routine simply waiting the requisite amount of time and then 'requesting' the bar.

One further question based on your response: What happens at the open if no trades occur until some time after the beginning of the trading session

i.e. no trades until 3 minutes into the session... so effectively there is no opening price until 3 minutes after session begin..... what is reported for the request for the first, second and third bar of the session where there is no trade data?

QUOTE:
no 'trigger' by the internals of WLP that 'delivers' a bar automatically whenever one is complete,

Wealth-Lab is a data consumer, it never deliver data - it only receives.

QUOTE:
'requesting' the bar.

The Strategy Monitor requests complete bars and then runs the Strategy. That's different than a Streaming Chart window that subscribes to streaming data, builds news bars from the ticks, pushes a new bar into the chart and run the strategy. There is less delay executing a strategy after a bar is complete.

QUOTE:
what is reported for the request for the first, second and third bar of the session where there is no trade data?

Assuming you're talking about a 1-Minute chart, nothing happens because there was no trading activity. No bars are formed. "Missing" bars like this can occur throughout the day.

Ok Cone, I 'm getting clearer on this but there is one part (lol.... only one?) where I need more clarity:

Apparently the 'strategy' is run quite differently in the Strategy Monitor, which can run the strategy for All the symbols in a Dataset and the way a single streaming chart works when a strategy is active on the chart.

By a streaming chart 'subscribing' to the data stream I understand you to mean that the background chart code simply sits accumulating a tick stream and then delivers a bar 'whenever' one is complete (based on the frequency) and then runs the strategy upon delivering that bar. Does this mean that, despite that a tick can occur at 'anytime', the delivered bar is automatically synchronized with the 'time of day' corresponding to one of the standard intervals (1, 5, 10, 15 min etc.) and further then, if no bar is delivered, for a 'time cell' in the dataseries, then that bar is what you are calling 'missing'? Referring back, by synchronized I mean that a bar is delivered with 'whatever' ticks have accumulated when a time boundary fires.

The Strategy Monitor HOWEVER from what I glean above:

The Strategy Monitor subscribes to nothing but instead simply asks for a bar from some 'other' internal code whenever the SM's clock fires for the standard period that it is set to? So if the SM requests a bar and the bar is 'missing' does it run the strategy for that time cell anyway?

If I've got this approximately correct, I'm having trouble understanding why there is any difference in execution delay of a strategy if both systems ultimately either 'push' a bar into the chart and run or receive a requested bar and run.... since both are occurring on a 'time boundary'?

QUOTE:
Apparently the 'strategy' is run quite differently in the Strategy Monitor, which can run the strategy for All the symbols in a Dataset and the way a single streaming chart works when a strategy is active on the chart.

There is a difference, but oh gosh, where do we start? The S. Monitor and S. Window execute strategies in precisely the same way. The only difference is the data delivery. But when a new bar is loaded for a symbol, the strategy executes on the data, that's all there is to it in either tool.

There is a difference in the results (and even in the trades) of the S. Monitor and S. Window when executing a Portfolio Simulation (Sizing Control) on a DataSet with more than 1 symbol:

a) When the Strategy Window operates on a DataSet, a Portfolio Simulation is just that - it combines the results of all trades and builds and equity curve as if you were trading it day by day. This almost always results in rejected trades during the simulation at times when you don't have enough free cash for new purchases (or shorts).

b) When the Monitor operates on a DataSet, there really is no "Portfolio Simulation". In other words, the sizing is applied to each symbol in its own separate simulation. The results of all symbols are not combined. This is why the User Guide tells you in more than one place that Raw Profit sizing is recommended in the S. Monitor. With Raw Profit mode, you won't have any skipped trades, so you'll always see the Alerts for every new trade or trade exit.


Re: Streaming. Yes. The way streaming charts operate is pretty much "industry standard". The only difference that you may find is that some providers will fill missing bars with the value of the previous interval, but with zero volume. In our opinion, this will distort indicators by adding measurements for trading activity that never occurred.

QUOTE:
The Strategy Monitor subscribes to nothing but instead simply asks for a bar from some 'other' internal code whenever the SM's clock fires for the standard period that it is set to?

Please see the User Guide. It explains that the 'other' code is based on your system clock, and that you should ensure it's synchronized with "market time".

QUOTE:
So if the SM requests a bar and the bar is 'missing' does it run the strategy for that time cell anyway?

No. No new bar, no need to run the Strategy, which as you can see in the code runs based on bar numbers.

CODE:
Please log in to see this code.

Strategy Monitor: Schedules a run for the end of the next interval and when it arrives (based on your system clock), 1) waits 5 seconds to ensure the historical bar is available on the server, 2) requests an update (delay to server), and 3) receives the update (delay from the server). So that's 5 seconds + Round trip delay. Furthermore, Fidelity updates 10 symbols at a time per Strategy. So, if you have 50 symbols, multiply the round trip delay by 5.

Streaming Window: Immediately knows that an end of interval occurred when either a) a tick in the next interval arrives, or, b) the "heartbeat" declares an end of interval. Here there is practically no delay.

So, if you're running a strategy on fewer than 10 symbols, for sure I'd just put them all in Streaming Windows. However, if you have say 16 charts or more, that's a lot to keep track of, so I'd opt for the Monitor. However, due to the delays, if running intervals at 5 minutes or less with 20 symbols or more in the Monitor, I'd recommended splitting your DataSets in groups of 10 symbols.

@Cone, thanks again for the reply and such a detailed one.

QUOTE:
Please see the User Guide. It explains that the 'other' code is based on your system clock, and that you should ensure it's synchronized with "market time".

I did see this in the User Guide, but did not understand the significance until now since I assumed the internal code would figure things out from time stamps.

QUOTE:
Strategy Monitor: Schedules a run for the end of the next interval and when it arrives (based on your system clock), 1) waits 5 seconds to ensure the historical bar is available on the server, 2) requests an update (delay to server), and 3) receives the update (delay from the server). So that's 5 seconds + Round trip delay. Furthermore, Fidelity updates 10 symbols at a time per Strategy. So, if you have 50 symbols, multiply the round trip delay by 5.

This piece is MOST illuminating and explains directly why I have been having trouble with larger numbers of symbols in the SM (I never even tried running separate Strategy
Windows). I had assumed that iterating over bars was the source of the delay but this is much greater.

Unfortunately, I need (well need becomes relative if it just can't be done) to follow 162 symbols on 1 minute charts, but I only need to look at the current bar and 5 bars back for each run of the strategy. In other words, there is no need to iterate over a large number of bars for each run of the Strategy. Other systems in which I've tried this 'force' your code to iterate over the whole dataset but WLP seems to be the only one that puts the 'iteration loop' in the hands of the user/programmer, so that I can only look at a few bars without incurring the whole overhead of looking at all of them on every run... but apparently, from what you say about the server delays and symbol updating, I'm on a hopeless quest since even ignoring round trip delay 150 symbols incurs a delay of 15X5 or more than the minute bar itself :(

I suppose I'll have to do some stat analysis on the symbol group and try to find a smaller target group that fits my model.

Thanks again, so much, for your help.

QUOTE:
15X5 or more than the minute bar itself

The 5 seconds doesn't apply to the round trip delay, but in practice the delay between a 10-symbol request and the subsequent one turns out to be about 3 seconds.

QUOTE:
I suppose I'll have to do some stat analysis on the symbol group and try to find a smaller target group that fits my model.

Why? I guess the point of the last sentence in my previous post didn't make it across.

For the 162 symbols, create 17 DataSets with 10 symbols each (max). Add a Strategy item using the same script assigned to each of the DataSets. That way, they'll all run simultaneously, each creating one request only. It's currently the only way to go for a 1-minute Strategy.

@Cone

QUOTE:
However, due to the delays, if running intervals at 5 minutes or less with 20 symbols or more in the Monitor, I'd recommended splitting your DataSets in groups of 10 symbols.

I am sorry, but you are right. While I did understand what you were suggesting in your last sentence, I thought that you were also implying that the system could not handle 17 DataSets running simultaneously.

That pretty much wraps it up for me and I thank you again for the clarity of explanation and your patience in providing it.

Cheers,
Namuh

If you can affort an extra 3 seconds, you might consider using 20 symbols per DataSet. It would be easier to manage 8 or 9 DataSets than 17.

Ok the timing works fine and the suggestion for 20/set is even better. However I did run into a problem. I need more information out in real time than a simple Alert. I naively (remember this is the Super Naive Thread) tried PrintDebug to provide the data but it appears that it does not work in SM. I researched what I could find and came up with everything from Aleksy (may have misspelled his/her name and apologize if I did) and opening the Console... to writing to a file which is too slow. These are more complex and internal solutions than I am comfortable with at this time at my level of programming knowledge with .NET. I didn't try Message.Box (it may not work either) because I assume it is not persistent from run to run and I need to read and assess the data as it develops.

Is there any 'simple' way to display textual data in real time as the SM runs on its list?

btw, I encountered a post about the place some of you work.... what is MS123? If you don't mind saying.


lol sorry to keep adding... but now what does "Time's Up" in the ACTION column mean...

QUOTE:
I need more information out in real time than a simple Alert.

What kind of information do you need? Will you be at your computer to see it?

You can display lots of info in the Signal Name string. See the syntax of any trading signal (BuyAtMarket, SellAtLimit, etc.) Just hit F11 for the QuickRef.

MS123 is 3rd-party support for Wealth-Lab. We run wealth-lab.com, the Wealth-Lab wiki, Wealth-Lab support, create Wealth-Lab Extensions (Add-ins, Providers, Visualizers, and Strategies), contribute to magazines, etc., and, we repackage and resell Wealth-Lab Developer to international customers.

Re: DeActivate
Click on the Strategy, then click "De-activate Strategy" in the toolbar.

Re: Times up
It means the S. Monitor gave up looking for data for at least one symbol in the DataSet for a particular bar. In other words, an interval passed without trades for at least one symbol.

I thought I removed the DeActivate question? I found the answer after I initially posted.

I did think of the Signal Name string, but didn't go that way because the Alerts are wiped on the next run and I didn't want to have to be at the computer exactly on schedule. I suppose I could rig something up to take a screen shot, but I'd rather not.... or I may reconsider writing to a file.... I thought further and there may be some use to running stats on the longer term results.

As far as 'Times up' I couldn't tell if that meant that the strategy ran for the symbols that DID finish or if the run aborted when any/at least one symbol failed to complete? In other words, for the runs I have done so far I could not tell if there were simply no triggers or if the remainder of symbols were skipped.

QUOTE:
I could not tell if there were simply no triggers or if the remainder of symbols were skipped.

The Strategies that update are executed. If there are no Alerts, then none will appear. "Time's up" just lets you know there's at least one symbol that hasn't traded, that's all.

QUOTE:
running stats on the longer term results.

Alerts are real time. You can always run the script at any time later to generate the results you would have seen when trading - provided the data do not change. However, the data may change when loading a chart at a later time due to corrections. For sure writing to a file shouldn't be a problem. Just pass true for the append parameter when creating a new StreamWriter().

The use of the Signal Name field works fine... I didn't realize you could pack so much into it :) I have been able to run 9 groups of symbols on 1 minute charts with proper updating and the system keeps up. There are from 15 to 17 symbols in each group (I simply broke them into alpha boundaries for ease of tracking). I do notice that if I add them all at once and activate them at once they never fully initialize as in the last 4 to 5 groups or so sit and never get service, but if I add them one by one and bring each online first before adding the next I can get them all loaded and active with no problems.... odd behavior.... thread priorities getting messed up perhaps?

BTW I'm sure this belongs somewhere else, but there seems to be a bug in the compile, load, display interface in a Strategy Window and the lower left section of the main window where the changeable parameters are displayed. I have noticed that quite often I will change, for example, the default starting value of a parameter in the code and recompile but the display of the parameter slider and value will not update to reflect the new starting value even when I click Run Strategy. The correct value is used on the run and eventually the display updates or you can force it by changing the parameter to another value, but it's disconcerting.

QUOTE:
I do notice that if I add them all at once and activate them at once they never fully

You should perform a Data Manager update before the market open and Activate the Strategies prior to the open. If you Activate in the middle of the day, 3 days of data (minimum) are requested to fill in missing history and apply corrections. If you're doing that with over 100 charts, there's a lot of data to request, and above all save to disk file. (The large data files are not updated after initialization.)

QUOTE:
I have noticed that quite often I will change, for example, the default starting value of a parameter in the code and recompile

That's because the Strategy has already been saved to run with other parameter values.

I think we're past the initial point of the discussion. If you have questions on another subject, please start a new thread.

Ok I understand. Sorry to move out of context

Thanks for all your help.