NeoTicker Blog

We have received many questions related to using NeoBreadth. Questions usually involve techniques in writing the real-time formulas and historical data formulas. I will write a few articles on some of techniques we discovered so that all users can utilize these tricks and concepts.

Advance Issues Real-Time Formula

The default formula for the Advance Issues NeoBreadth definition is as follows,

Last >= prevDClose (M15)

This formula works fine in real-time. More importantly, it works with all kinds of time frame settings. Thus if you want to track the advance issues for a basket of stocks traded in London, all you need is to change the time frame setting in the NeoBreadth definition. The formula can take care of the rest.

There is a weakness with this formula that power users do not like – it takes up more memory than it should. Within the formula the indicator prevDClose is a series based on the 15-minute data series. Thus you are using 2 series with properly 100 bars each (can be much more then that if your RAM Cache setting allows for more).

That does not sound like much, isn’t it?

Now think about the number of symbols you are going to throw behind this formula. At 500 symbols, you are tracking 500 data series and 500 indicator series, or, 100,000 bars of information.

If you are tracking many NeoBreadth definitions, you cannot afford to waste your computer memory like that.

First Alternative

So, is there any alternative?

Yes, if your data vendor provides very accurate previous day close data as a quote field, then your formula can be written like this,

Last > Prev

This formula uses absolutely no series at all. Just the comparison of 2 quote fields. Unluckily, most data vendors do not provide accurate previous day close data. Thus, most users will not be able to utilize this formula.

Many users asked why data vendors do not have accurate previous day close data.

The issue is actually two-folds.

First, stocks no longer trade in a single exchange center in a fixed time range. We have pre-market trading, after hours trading, and also the special settlement period right after the regular trading hours. It gets very complicated what we consider as the close of the previous trading day.

Second, official closing price for stocks that traded at, say, New York Stock Exchange, may not be the actual last traded price during the regular trading hours. If a new settlement price is set after the market close, that number becomes the official closing price.

Data vendors cannot accommodate all these variations and still generate the exact previous closing price that you are looking for. That is especially true if you are working with customized time frame. e.g. shortened trading time range

Second Alternative

Is there any other way? Yes.

Consider the following formula,

c (M390:2) >= c (1, M390:2)

This formula can generate the correct advance issues for stocks traded in North America only. Thats because the use of 390-minute bar is tailored towards the 390 minutes of trading from 9:30 to 4:00 Eastern Time.

The advantage of this formula,

1. No indicator is involved, saving the real-time cost of updating an indicator
2. It loaded only 2 days of data, thus, there are 2 bars only for the data series.

Comparing this formula against the standard one, we are talking about significant saving in both CPU time and memory usage (by at least 50,000 times!).

If you are not tracking advance issues in North America, don’t worry. You can change the 390-minute bar to the one that match the trading time for the exchange you are tracking. It is not something that is hard to do, all it takes is the courage to experiment with the various settings to get what you are looking for.

2-Day Advance Issues

Some users already notice that we provide the backfill data for 2-Day Advance Issues on various indices.

What is 2-Day Advance Issues?

As oppose to comparing against the close of previous trading day, the comparison is done against the close of 2 trading days ago.

The exact formula we use is as follows,

c (M390:6) >= c (2, M390:6)

The reason why the formula is using 390-minute bar that loads 6 days is that we are also tracking 3-day, 4-day, and 5-day advance issues. Using the same custom days to load setting can help all these NeoBreadth definitions to share the same data series for their calculations.

Discuss this article