This TSAdvSigEval analysis technique is used to evaluate real world advanced sentiment-filtered trading signals against the EM-based sentimentscape. This is an advanced procedure designed to test two-component real-world signaling systems where one component is the actual entry and exit signal based on either the traded entity or a surrogate, and the other component is a sentiment signal that allows only long or short trades to take place.
For this procedure, two real-world signals are generated, merged, and tested: a wide-sense signal that partitions overall market sentiment into positive and negative states, and a finer time horizon signal that generates the actual entries and exits.
If you are not using a two-component sentiment-augmented signaling system, you should use the TSSigEval or TSRefSigEval analysis techniques. They are simpler to use and understand, and they also support asymmetric signaling. In TSAdvSigEval, both the primary and sentiment components of the signals used to create the sentimentscape are symmetric with respect to the information content used to generate the upside and downside transitions.
Note that you can still use this procedure to test two-component sentiment-augmented signaling systems even if the both the sentiment and primary signaling are asymmetric. They will simply be tested against the less finely tuned symmetric sentimentscape in the signal analysis.
The real-world trading signals will be plotted atop the sentimentscape or referential sentimentscape at their respective time horizon and lag fractions. A brief summary of the signal analysis for a trading system is shown when moving the mouse over the special point representing that particular trading signal. The full signal analysis, including the equity curve, is shown when clicking on the point representing that particular trading signal.
This analysis technique requires one to add his or her trading signals to the TSAdvSigEval code. You must have some experience coding EasyLanguage analysis techniques and functions.
Unfortunately, TradeStation function architecture computes all series functions contained anywhere within a function regardless of whether the program logic actually calls those functions. That makes it impractical and computationally very expensive to store all signal functions in a single generic user-defined signal function. As such, it is necessary to have separate TSAdvSigEval variants for each signal set.
For each signal specific version of TSAdvSigEval, you must assign the signal count to Signal, and put the various signals in Signal, Signal, up to a maximum of Signal. The original TSAdvSigEval contains sample signals. It is recommended that this original TSAdvSigEval be kept unchanged, and that you use the Save As option to create additional analysis techniques, each containing the set of signals you would typically test together. For example, you could create MyAdvSigEval1 for evaluating signal set 1, MyAdvSigEval2 for evaluating signal set 2, and so on.
Sample functions are included for MA crossover and breakout signals. You may wish to use these functions
as templates. Basically, the signal for a bar must be set as follows:
+1 for in market long
-1 for in market short
0 for out-of-market
Since a tradescape and signal analysis is either long or short, but not both, only one side of the signal is used:
For a long tradescape, the +1 signal is in a position (long), otherwise out of market
For a short tradescape, the -1 signal is in a position (short), otherwise out of market
Since the signals are encoded and stored with the data on each bar, only the current bar's signal is computed on each call.
String SignalTitle ("TSAdvSigEval")
This is the signal title to be added to the Sentimentscape plot that describes the signal setup being evaluated.
int TradedEntity (1)
This input specifies the specific data stream to be traded and analyzed. The value 1 uses data1, 2 uses data 2, and so on. TradedEntity cannot be zero.
int SignalEntity (0)
This input specifies the specific data stream to be used for generating the signals. The value 1 uses data1, 2 uses data 2, and so on. If SignalEntity is 0, or set to the same data stream as TradedEntity, no referential or surrogate signaling occurs and the traded entity is directly signaled. If SignalEntity is set to a separate data stream, those data are used for the surrogate that generates the primary trading signals.
int SentimentEntity (2)
The SentimentEntity is the data stream that is processed to create the positive sentiment windows where only long positions are permitted, and the negative sentiment windows where only short positions are allowed. A specific sentiment entity must be specified; the value cannot be 0. The SentimentEntity can be any entity that reflects the sentiment associated with the traded entity. In sentiment-augmented signaling, the entity to be traded is usually different from the entity used for the sentiment signaling. In general, a sentiment entity will be an overall market index or a surrogate for such, or a sector index or ETF. It can, however, be the same as the TradedEntity, and if a SignalEntity is specified, it can be the same as the surrogate used for the primary signaling. In such an instance, the sentiment signal draws its sentiment states from the wide-sense behavior of the entity used for the primary signaling.
int SentimentLen (80)
This is the EM Length of sentiment signal. Typical values range from 20-80. The higher the value, the longer in time the long-only and short-only windows will be. This value cannot be set to less than 5.
The SentimentLen sets the time horizon for the wide-sense sentiment signal. Note that no sentiment filtration occurs if the EM length in the sentimentscape is equal to or greater than the SentimentLen. If the sentiment filtration is particularly effective, there can be an abrupt or sharp transition in the surface near the SentimentLen.
The lag added to the sentiment signal for each point in the surface will be identical in lag fraction to the lag for that point in the tradescape surface. For example, if the point in the surface has an EM length of 20 and a lag fraction of 1, and the EM length for the sentiment filter, as specified in SentimentLen, is 80, the idealized primary signal is offset by a lag of 20 and the idealized sentiment signal is offset by a lag of 80.
double Asymmetry (1.0)
The asymmetry is the ratio of the information content used for the upside transitions (turns to the upside) relative to the downside transitions (turns to the downside). A quick to enter but slow to exit long signaling system has an asymmetry less than 1. A slow to enter but fast to exit signaling system has an asymmetry greater than 1. Typical signal asymmetries are between 0.25 and 4. The turtle HH=55 LL=20 breakout system is an example of an asymmetric signaler, one that for long trades is slow to enter and fast to exit, a signal asymmetry of 55/20=2.75.
Asymmetry must be between 0.1 and 10.
In the tradescape plot, only a single EM length is shown for the X axis. The interpretation of an EM length of 20 would be as follows for an asymmetry of 0.5. The EM signal used to generate the upside transitions (the entries for a long system) will be 20 * sqrt(0.5) = 14.142. The EM signal used for the downside transitions (the exits for a long system) will be 20 / sqrt(0.5) = 28.284. The asymmetry is thus 14.142/28.284 = 0.5. While the tradescape result is shown at an EM length of 20, the actual lengths used to generate the turns for the composite EM signal are 14.142 and 28.284. Note that the EM length assigned is not the average of the two lengths.
Note also that an asymmetry of 1.0 generates the standard (symmetric) sentimentscape or referential sentimentscape.
String FileName ("")
The data within the TradeStation chart is written to a disk file that is used in a separate procedure to generate the plots and analyses. If FileName is empty, , a temporary binary data file is used to store the data and this file is automatically deleted when the window is closed. If a full path filename is specified, a persistent ASCII CSV file is written. A full valid Windows path and filename must be specified. The directory path will be created if it does not currently exist. Since a comma separated value (CSV) file is written, a CSV file extension is recommended. For example, a FileName such as "c:\data\a1.csv" is valid, even if the folder c:\data doesn't yet exist.
int WalkFwd (2520)
This is the count of bars, from last non-reserved bar backward in time, to use for the analysis. In order to accommodate all of the time horizons in a tradescape, do not set this value below 250. For an overlapped progressive tradescape, this value needs to be at least 125. If a value is specified that is greater than the amount of data available in the chart, all of the data that is present is used.
int Reserved (0)
This is the count of most recent bars to reserve for any walk-forward you may wish to independently carry out. These data are disregarded in the analysis. A value of 0 processes all data through the most recent bar.
int DoShort (0)
A tradescape is normally a long-side only analysis. This value can be set to 1 to perform short side tradescapes and signal analysis.
int Degap (0)
This option removes all overnight/weekend gaps in data for instances where positions are always closed prior to a trading session's closing bar.
If Degap is 1, a check is made to see if the same day fraction of data is greater than 80%. If this criterion is met, as with hourly or finer bar densities, the gap across days is mathematically removed. The price activity from the prior day's closing bar through the end of the first bar of the next day will be zeroed. This means the two bars will share the same closing values. The adjustment is based on the differential in closing prices and is applied to the open, high, and low values as well.
The adjustment is made backward in time so that the most recent bar's close will be the current price. The removal of gaps moving backward in time can result in negative prices. In such an instance, the lowest low in the de-gapped data will be set to 0.01 and all prices will be shifted accordingly.
int InactiveAtLastBar (1)
When this variable is non-zero, the last bar in the chart will automatically trigger the computation and deactivate the analysis. A progress bar is normally drawn, but if this proves a distraction, it will be omitted if this value is set to 2. If set to 0, the analysis will not take place until the Status is toggled Off in the Format Analysis Techniques option. If this variable is set to 0, the binary signals are also plotted in the TradeStation chart.