Eugene,

I am attempting to understand some items that I am sure are relatively elementary to most people, but I seem to be quite ignorant.

I was looking over the source code for the TASC indicators and noticed that on occasion your code does not include the "ds.Description" term in Series portion of an Indicator Description, for example in TruncatedBandPass you have:

CODE:
Please log in to see this code.

and I would have expected that needed to be done, but obviously it doesn't.

Question: Does WL6 have another way to correctly identify this Series? Thanks!

Vince

Hi Vince,

Please find answers in the API documentation:

Creating an Indicator Library in Wealth-Lab

Thanks.

Eugene,

I was using the document that you referenced, which is the basis of my question. In that document it has

CODE:
Please log in to see this code.

for the example.

Obviously that is the preferred method, BUT in your coding you have occasionally not used that approach, and not included an explicit "ds.Description" identifier. I understand that there can be MANY ways to code something, so I am attempting to understand how WL6 picks up the Series description in the absence of an explicit declaration. Thanks!

Vince

If you leave the ds.Description term out in the "hash" description below ...

CODE:
Please log in to see this code.

then you run the risk of creating two cache entries for SMA(...) which are derived from different base indicators. For example, SMA(Median(...)...) would look like SMA(DX(...)...) so one cached entry would clobber the other and get confused. I have ran into this problem on a couple TASC indicators, but this issue wasn't serious enough to return wrong answers.

I think it's okay to mess with the "hash" (description) line provided you can guarantee uniqueness in all cache lookups. Also, for some of my indicators, I create a more "descriptive" description line, but follow strict guidelines when creating the hash description for cache lookups.

CODE:
Please log in to see this code.

The concern here is that the hashKey description needs to be as terse as possible to speed cache lookups and conform to indicator standards so everything is compatible with other indicator calls, but the description itself can be anything. Note that it's unnecessary to include the bars.Symbol in the hashKey because you're caching into a Bars object which already uniquely identifies the bars.Symbol attribute.

In contrast, if your indicator is caching into a DataSeries object, which doesn't have a bars.Symbol attribute, then you should probably include the bars.Symbol in the hashKey for uniqueness. And yes, the Object Browser on Visual Studio does show a Dictionary datatype with a Cache property on the DataSeries definition. Check it out.

superticker,

Thanks for some light on the subject. What you are describing is part of what has driven my initial ignorant question to Eugene. I had a "feeling" that not including "ds.Description" explicitly MIGHT have some unintended consequence, but I was asking IF there was some internal mechanism that WL6 used to prevent it, hence my question about an "implicit" process to provide a differentiation.

Vince

Superticker,

You are 100% correct! I just opened a Chart window and placed a 200 bar SMA on it. I then used the TruncatedBandPass indicator on the Price Series and the SMA. The indicator for both was identical, which obviously means that the second time it was retrieving the cached (incorrect) copy (see attached).

Vince

QUOTE:
The indicator for both was identical, which obviously means that the second time it was retrieving the cached (incorrect) copy (see attached).

A more interesting question is "If two different strategies call the same indicator and Bars object (ticker symbol), would the cache copies get confused between these two strategies?"

In other words, are the Bars objects for one strategy kept separate from the Bars object for the other? ... Or are all Bars objects for all strategies stored in the same global cache? I don't know. But you might be able to use the Object Browser on Visual Studio to see of Bars objects are separated by strategy. My "guess" is they have to be; otherwise, the Performance Visualizers would get confused and display results for all strategies on a single visualizer.

QUOTE:
But you might be able to use the Object Explorer on Visual Studio to see of Bars objects are separated by strategy.

You are now getting WAY beyond my capability! ;)

But based on what you are saying, I would not necessarily make that assumption. That is really a question for Glitch. The more interesting question would be "What if both strategies have exactly the same name?" Would there be potential confusion then??

Vince

QUOTE:
The more interesting question would be "What if both strategies have exactly the same name [would cache entries get confused]?"

Well, in this case you would want the cached entries to be "identical" so you're not creating the same cached indicator twice.

Perhaps you're worried about the case where two entirely different strategies have the same name. But WL won't let you create two strategies with the same name (at least not in the same folder). There's an XML tag inside the strategy source file with the name of the strategy, and that name needs to be unique.

QUOTE:
Perhaps you're worried about the case where two entirely different strategies have the same name. But WL won't let you create two strategies with the same name (at least not in the same folder).

I was specifically thinking about the latter case that you raised... Same name, different folder, different strategy.

QUOTE:
There's an XML tag inside the strategy source file with the name of the strategy, and that name needs to be unique.

I wonder if it might be a hash based on the name.

Vince

QUOTE:
The more interesting question would be "What if both strategies have exactly the same name?" Would there be potential confusion then??

Their Guids should be unique for WL to distinguish them, I believe.

QUOTE:

QUOTE:
The more interesting question would be "What if both strategies have exactly the same name?" Would there be potential confusion then??

Their Guids should be unique for WL to distinguish them, I believe.

Eugene, does that mean that every calculated indicator has the associated GUID from its parent strategy that generated it?

Vince

The way the Bars.Cache works is documented in the API manual which doesn't mention Guid as part of the process.

QUOTE:
The way the Bars.Cache works is documented in the API manual which doesn't mention Guid as part of the process.

So it might be an issue, but probably somewhat obscure.

However the issue that superticker pointed out is probably much more critical and potentially of wider impact, especially if an indicator is being used in something like a Rotation strategy. In that situation it appears that the cache could be providing incorrect data.

Vince

QUOTE:
In other words, are the Bars objects for one strategy kept separate from the Bars object for the other?

Probably.