I have a WL indicator (RSDif) which takes a symbol name as an "internal" Bars parameter. Since the symbol name is an internal Bars parameter, it's included in the more verbose version of the hashKey, which is the description field. See code below.

CODE:
Please log in to see this code.

But there's a weird problem. When optimizing a strategy, WL caches a "pseudo copy" of this indicator by default for every symbol in the dataset--not desirable.


My question is, since the indicator cache is associated with a Bars object, which uniquely identifies and separates each symbol independently anyway, should the symbol name be left off the hashKey--and the description key--in this very special case by default?

If so, would there be a special case--ever--where you would want to include the symbol-name parameter in the hashKey--or description--at some point? I'm asking because sometimes I'm comparing both a sector index and industry index against the S&P500 for a given stock on the Chart (although that's done with a separate member function call). So DataSeries for these two comparison cases are created on the stock Chart.

I've been using this indicator a couple years okay, but I'm wondering if these pseudo copies of this indicator would load memory resources during optimization if I don't clear the cache, which I don't like. Even if these pseudo copies are never cached, they must be taking up some kind of resource, right?

A simple fix to your code:

CODE:
Please log in to see this code.

Thanks a bunch. I agree with your changes. Yes, since there's a DataSeries constructor that takes Bars input, it makes more sense to pass Bars in there (instead of a DataSeries) unless there's a good reason not to. But all these changes didn't change the behavior of the execution at all. The "By Symbol" tabulation still listed pseudo copies of the RSDif indicator (by column) for each symbol in the dataset.

Then it occurred to me this may be an artifact of how the "By Symbol" tabulation picks its columns for its listing. So I totally removed the bars.Symbol component from the description string; see the fixed code below.

CODE:
Please log in to see this code.

Not only did this change eliminate the pseudo indicator copies from being repeated for each symbol (by column), but it removed the RSDif indicator from the tabulation altogether. So my tentative conclusion is that this behavior is more about how By Symbol tabulates columns in its output--it uses the uniqueness of the description field, which might be the best design.

The bottom line is that one doesn't want to include bars.Symbol in the description string because this confuses the By Symbol implementation. You might try inserting bars.Symbol in the description of one of your own indicators to see if you get the same duplicate column behavior for By Symbol.

QUOTE:
The bottom line is that one doesn't want to include bars.Symbol in the description string because this confuses the By Symbol implementation.

You're right. There is no need to include it unless your indicator operates on external Bars object's data such as an index. In this case you will want to keep the external symbol's Bars object in the Description string to ensure it's unique. I noticed the use of index in your static Series code (but wasn't sure if we should remove it b/c your implementation is omitted):

public static RSDif Series(Bars bars, string indexSymbol = ".SPX")

QUOTE:
So my tentative conclusion is that this behavior is more about how By Symbol tabulates columns in its output--it uses the uniqueness of the description field, which might be the best design.

Just in case, this is a documented feature. It appears in the User Guide > Preferences > Performance Visualizers > By Symbol > Other Data Series:

The final value of each DataSeries created by the strategy is automatically displayed in the rightmost columns with the following exceptions:
...

QUOTE:
There is no need to include it unless your indicator operates with external Bars object's data such as an index. In this case you will want to keep it.

Yes, this indicator is computing the Relative Strength Difference, RSDif, between the current stock (bars.Symbol) and an external index (where the name is passed as a parameter). There's not a problem including the index name in the description and hashKey, but one needs to leave the name of the stock itself out; otherwise, the By Symbol tabulation gets confused. It's just a matter of learning the particulars of this implementation and API.

And yes, this is the indicator that calls ExternalSymbol.Series (encapsulating reflection) to grab that external index. I trade against the decorrelated line, and this indicator is responsible for doing that decorrelation against the S&P500 (or whatever index gets passed). That process removes the market noise from a stock before its time series is fed into other indicators. In signal processing, this decorrelation step is common practice.