object aliases are user defined aliases, shorter names for commonly used gt sys-sig-indic descriptions. object aliases can be used in any of the gt sys-sig-indic descriptions, as well as in gt trading system component specifications like CloseStrategy, TradeFilters and OrderFactory. it isn't clear whether an object alias may be used to define multiple components of a trading system (e.g. contain a connecting '|' symbol), but the code commentary, and pod implies that is not their intended purpose. for that it's probably just wiser to use a system alias (e.g. global alias) (refer to -tbd-).
the intention of some of the ras version changes in various object aliases handling methods is to not permit object aliases to define multiple system components (e.g. contain a '|' symbol). however, sufficient code may not be in place to guarantee that attempts to do that will always be detected and flagged with a useful error message.
so don't do it. use a system alias (global alias) for that purpose.
NB: many of the object alias file locations and some object alias file processing attributes described here may only be implemented in specific ras hack versions of the gt toolkit. see the section 'some important notes' for some more details. contact ras directly (or start a devel list message thread) if any of these features are needed in your particular gt use model.
to use an object alias in a gt sys-sig-indic description you prepend to the object aliases name a string that starts with the '@' symbol, then add the type designator ($kind) (e.g. Indicator, Signal, etc) followed by one or two colons ':' and then finally insert the name of the object alias itself. it's recommended that you use the standard gt sys-sig-indic abbreviations in place of the type designators (e.g. $kind) (e.g. Indicators, Signals, Systems, etc) (see GT::Tools pod). for example, if you have an object alias named my_mean and it is an indicator type ($kind is indicator) it would appear in a gt sys-sig-indic description as:
@I:my_mean or possibly @I::my_mean or @Indicators::my_mean (not recommended)
more examples of object aliases definition as well as usage will be presented as the topic is developed.
object alias files are simple text files that specify an object alias and it's value. in a perl language context these files are configuration files in that they have a key-value pair record structure.
there are two different formats that object aliases come in. which form is used to define the object aliases depends on the particular file location (pathname) the object aliases is defined in. regardless of the object alias format type the actual value of the object alias remains the same, but the key string varies depending on the file location.
the files (locations) that can define an object aliases are
$HOME/.gt/options
and
files in the directory $HOME/.gt/aliases named in accordance with the $kind string (see below) and/or the files identified by the value of gt config keys of the form "Path::Aliases::$kind" (case insensitive), defined in the users $HOME/.gt/options file.
in the absence of any explicit directive, additional (global) object alias files will be searched for in the gt install directory -- generally defined as the directory just above the current working directory. because most gt users install gt and then cd to Scripts to use the gt toolkit to perform ta analyses, the typical cwd is the gt Scripts dir (this may not apply when using the cpan branch, or some other installation model). in order to support all (most) other installation models there are a number of explicit ways to specify alternate paths for these global or shared object alias file locations as described in the paragraph 'object alias file locations and file names' below.
the variable $kind assumes each of the following strings during object alias processing and file loading:
signals
indicators
systems
closestrategy
moneymanagement
tradefilters
orderfactory
analyzers
these $kind strings have no uniqueness abbreviations nor any mis-spelling tolerance, thus 'indicator', 'signal' and 'system' will all fail.
the value of $kind, when used as a key (left hand side of the key-value pair), it is not case sensitive but when the $kind string is used in a value context (right hand side of the key-value pair) it is case sensitive and by default will be lower case string as listed above.
there are two different forms of object alias formats depending on the file in which the object alias is defined.
this form of object aliases can only be used in the $HOME/.gt/options file.
"Aliases::$kind::"<object_alias> <whitespace> { <object_alias specification> }
specific format details
the string "Aliases::$kind::" must be prepended (without the quotes) to the object_alias name (<object_alias>).
the object_alias name is any proper perl string but it should
avoid these problematic characters '@#{}[]+-*/'.
the resulting string (e.g. Aliases::$kind::object_alias_name) is used as a gt config hash key: as a consequence the key string will be stored lower case, but is case insensitive. the value of the key will be unaltered and will be case sensitive.
the key string (e.g. Aliases::$kind::object_alias_name) is separated by whitespace from the object alias <object_alias specification>.
the object alias definition <object_alias specification>
is enclosed in curly braces '{...}'.
( statement should be validated and verified )
the object alias definition <object_alias specification> value will consist of the remaining characters on the current logical line (if continuation and comment line support is present in the gt toolkit version for the $HOME/.gt/options file the logical line ends when a line is encountered that doesn't end with a '\' character immediately before the newline character).
here are working examples -- valid only in your $HOME/.gt/options file
Aliases::Indicators::MyMean_opt { I:Generic:Eval ( #1 + #2 ) / 2 }
Aliases::Indicators::PVOL_opt {I:Prices VOLUME}
# example use: display_indicator.pl @I:MyMean_opt GOOG '50 {I:RSI}'
# display_indicator.pl @I:pvol_opt GOOG
the second form of an object alias format can only be used in object alias files where the alias type information (i.e. $kind) is derived from the files pathname. this object alias format omitd the string "Aliases::$kind::" from the object_alias name (<object_alias>). the object alias processing and storage remains the same as previously described so the preceeding formatting details apply with this minor variation:
the object alias definition <object_alias specification> value will consist of the remaining characters on the current logical line (if continuation and comment line support is present in the gt toolkit version for object alias files the logical line ends when a line is encountered that doesn't end with a '\' character immediately before the newline character).
the type b object alias format:
<object_alias> <whitespace> { <object_alias specification> }
format b applies to object aliases files (private files) named based on the $kind strings in the directory $HOME/.gt/aliases or in other, possibly shared, directories as will be described later.
the examples below are of $kind indicator, so they would appear in a file named indicator in an aliases directory at $HOME/.gt/ or at some other directory path in the file system or in an absolute pathname identified via the key "Path::Aliases::Indicator".
MyMean_gbl { I:Generic:Eval ( #1 + #2 ) / 2 }
PHI_gbl {I:Prices VOLUME}
PO {I:Prices OPEN}
PH {I:Prices HIGH}
Pl {I:Prices LOW}
PC {I:Prices CLOSE}
PV {I:Prices VOLUME}
vol {I:Prices VOLUME}
the following examples are of $kind signals, thus they might appear in a file named $HOME/.gt/aliases/signals.
3Xoverlong { S:G:Or { S:G:And {S:G:Above #1 #3} {S:G:CrossOverUp #2 #3} } { S:G:And {S:G:Above #2 #3} {S:G:CrossOverUp #1 #3} } }
3Xovershort { S:G:Or \
{ S:G:And {S:G:Below #1 #3} {S:G:CrossOverDown #2 #3} } \
{ S:G:And {S:G:Below #2 #3} {S:G:CrossOverDown #1 #3} } \
}
3EMAlong { @S:3Xoverlong {I:EMA #1} {I:EMA #2} {I:EMA #3} }
3EMAshort { @S:3Xovershort {I:EMA #1} {I:EMA #2} {I:EMA #3} }
the gt system will look in multiple directories for object alias files. if the paths (directories) do not exist or there are no appropriately named files found in the directories gt will silently ignore the situation. negative conditions will neither cause a warning nor an error, this can be problematic or not depending ...
object alias files are sought in the file system in two places:
$HOME/.gt/aliases. files therein must be named after $kind. this is a fixed pathname and it cannot be altered. however the absense of the directory $HOME/.gt/aliases will inhibit the reading and processing of any user private object alias files.
note: alias files must be name after $kind (e.g. $kind takes on each of these strings 'signals', 'indicators', 'systems', 'closestrategy', 'moneymanagement', 'tradefilters', 'orderfactory', 'analyzers') and must be lower case (if your os/fs is case sensitive).
pathname examples: $HOME/.gt/aliases/signals $HOME/.gt/aliases/indicators $HOME/.gt/aliases/systems $HOME/.gt/aliases/closestrategy
default global (possibly for shared) object aliases files. the location and naming of this collection of object aliases files can be controlled by each GT user via gt configuration key-values and/or an environment variable.
by default the directory for global (shared) object aliases is sought in one of up to five locations, in priority order:
i) the value of multiple gt config keys "Path::Aliases::$kind".
this feature will override the pathname for each $kind global
object alias file, so a user may/must have a gt config key
for each $kind of object alias pathname set in this manner.
ii) the users value in gt config key "Path::Aliases::Shared".
iii) the users value in gt config key "GT::Root".
iv) the users environment variable "${GT_ROOT}".
v) one directory above the current working directory.
item i) overrides items ii) .. v) for $kind object aliases only.
items ii) .. v) are mutually exclusive -- the value assigned by the key sets the directory path where global (shared) object alias files of $kind are sought. if no files are found or the directory does not exist the condition is silently ignored.
items ii) .. v) apply to all shared object alias $kind files not over-ridden by item i).
( the preceeding statement needs to be validated and verified)
each object alias file found via key-value pairs per items ii) .. v) must be named one of the $kind strings (see above).
NB: the default $kind filenames are lower case, but if you elect to change the default name via item i) whatever value is specified will be used as the filename unchanged.
example assuming there is no explicit gt root setting (e.g. item v) above) (pathname shown relative to current working directory)
../aliases/indicators ../aliases/systems ../aliases/signals ../aliases/closestrategy
same example with the gt root directory explicity set using a gt config "GT::Root" key-value pair:
GT::Root /usr/share/geniustrader
files with these pathnames will be sought:
/usr/share/geniustrader/aliases/indicators /usr/share/geniustrader/aliases/systems /usr/share/geniustrader/aliases/signals /usr/share/geniustrader/aliases/closestrategy
similarly you can use gt config key "Path::Aliases::Shared" to set the directory path in the case when "GT::Root" isn't a suitable directory for object alias files. "Path::Aliases::Shared" overrides "GT::Root". gt config key "GT::Root" overrides envar "${GT_ROOT}". default global location '..' relative to cwd.
if the default paths and file names (e.g. $kind) are unacceptable for some reason, do not despair or attempt to change the code. you can easily specify alternate paths and file names for the global object alias files using the existing naming features.
this might be done to facilitate two or more users sharing object aliases files. or it might be needed to support multiple sets of object aliases files or whatever.
alternate paths are under full user control using the gt %conf option keys "Path::Aliases::$kind" to establish new paths as well as the filenames used for object alias files.
Path::Aliases::$kind /this/users/preferred/path/alias_file
will cause gt to search /this/users/preferred/path/ for the file named 'alias_file' hopefully containing type b $kind object aliases. if the file or path does not exist it will be silently ignored. this is both a blessing and a curse, depending ...
it is required that any key specified be in the set of $kind name strings (see above) but the value for the key (e.g. the value of these keys is the absolute pathname of the file containing $kind object aliases) is entirely up to the user. the value will be case sensitive depending on your os/fs. it is expected that the object aliases found at the path associated with the $kind key be of type $kind. in other words, the file named by the value of key Path::Aliases::Indicators should contain indicator aliases, and key Path::Aliases::systems should contain system aliases.
by way of NEGATIVE example, while the following are operationally correct they are NOT recommended practice.
Path::Aliases::signals /home/shared/some_aliases Path::Aliases::indicators /home/shared/objects Path::Aliases::systems /etc/gtsys Path::Aliases::closestrategy /cs
as shown, the user is free to define different directories as well as alternate filenames for the global (shared) object alias files. the effect of putting say signal object aliases in files expected to be indicators hasn't been evaluated, but the expected result is (or should be) that the signal alias would simply not be found.
use suggestion: if you must have different directories object alias files, for the sanity of your maintainers as well as your users, use $kind or filenames that somehow relate to $kind where ever else you set the path.
in other words:
Path::Aliases::signals /home/shared/GT/signals Path::Aliases::indicators /home/shared/devGT/indicators Path::Aliases::systems /etc/systems Path::Aliases::closestrategy /var/shared_GT_oa/closestrategy
the $kind filenames in dir tree $HOME/.gt/aliases will be lower case.
the default global $kind filenames will be lower case.
if you change the default $kind pathname using any of the config options ("Path::Aliases::$kind", "Path::Aliases::Shared", "GT::Root", or envar "${GT_ROOT} whatever pathnames you specify will be used without change.
gt config option keys are always case insensitive and are stored lower case.
completely valid object alias files stored in an appropriate directory but having a case conflict will be silently ignored. suggestion: avoid using upper case pathnames.
object aliases support recursion. this makes the combination of system and object aliases a powerful and useful feature.
if an object alias specification includes arguments encoded with a hash '#' followed by an integer (generally delimited with whitespace) the actual argument value used for that parameter will be the value of the argument that corresponds with the integer.
say what!?
as a fairly useless example say we define an indicator object alias
P {I:Prices #1}
when used in a sys-sig-indic the parameter that is represented by '#1' must be provided as the first argument to the sys-sig-indic. in the following examples argument #1 is either LOW or VOLUME.
display_indicator.pl @I:P GOOG LOW display_indicator.pl @I:P GOOG VOLUME
a more useful example is one defined earlier:
MyMean_gbl { I:Generic:Eval ( #1 + #2 ) / 2 }
which can be used as follows:
display_indicator.pl @I:MyMean_gbl GOOG '{I:Prices HIGH} {I:Prices LOW}'
in this case #1 has the value "{I:Prices HIGH}" and #2 "{I:Prices LOW}"
as an example of recursion (i think), object aliases
PH {I:Prices HIGH}
Pl {I:Prices LOW}
can be used as follows:
display_indicator.pl @I:MyMean_gbl GOOG @I:PH @I:Pl
For example, define these signal object aliases in your $HOME/.gt/aliases/signals file
# 3Xover... is a generic crossover signal involving three lines
3Xoverlong { S:G:Or \
{ S:G:And {S:G:Above #1 #3} {S:G:CrossOverUp #2 #3} } \
{ S:G:And {S:G:Above #2 #3} {S:G:CrossOverUp #1 #3} } }
3Xovershort { S:G:Or \
{ S:G:And {S:G:Below #1 #3} {S:G:CrossOverDown #2 #3} } \
{ S:G:And {S:G:Below #2 #3} {S:G:CrossOverDown #1 #3} } }
# 3EMA... passes its arguments to and invokes 3Xover...
3EMAlong { @S:3Xoverlong {I:EMA #1} {I:EMA #2} {I:EMA #3} }
3EMAshort { @S:3Xovershort {I:EMA #1} {I:EMA #2} {I:EMA #3} }
with a (global) system alias (see -tbd-) named 3EMA defined in your $HOME/.gt/options file:
Aliases::Global::3EMA SY:Generic \
{ @S:3EMAlong 60 90 120 } { @S:3EMAshort 60 90 120 }
you can evaluate initial positions using the aliased signals defined. note however, the arguments are fixed.
with a similar system alias named 3EMA[] in your $HOME/.gt/options file:
Aliases::Global::3EMA[] SY:Generic \
{ @S:3EMAlong #1 #2 #3 } { @S:3EMAshort #1 #2 #3 }
you can pass different arguments to the aliased signals using the numbered parameter substitution feature. use this alias in a sys-sig-indic desc like
SY:3EMA[ 20 50 150 ]
include the square brackets '[' ']' as shown and delimit the parameters with whitespace.
and if you don't want the parameter symmetry (e.g. using same args for the long and short position triggers) you can redefine everything with parameters numbered #1 to #6
Aliases::Global::3EMA[] SY:Generic \
{ @S:3EMAlong #1 #2 #3 } { @S:3EMAshort #4 #5 #6 }
and use a sys-sig-indic desc like SY:3EMA[ 20 50 150 15 40 120 ]
it's critical that the leading '{' is present in each object alias otherwise the arguments don't get fully substituted
continuation and comment lines for object alias files is supported only with the ras versions of methods GT:Tools::resolve_object_alias and GT:Conf::load. the current trunk version of GT::Conf::load performs the initial object alias file reads internally but doesn't handle continuation or comment lines for them. also, the trunk version of method GT:Conf::load is now technically broken (flawed): if called multiple times, say to read an additional gt configuration file, object alias processing will be repeated unnecessarily. finally, the current ras versions of the modules GT:Tools and GT:Conf also diverge from the trunk versions in other ways as well, so it isn't a simple matter of updating just these two modules.
blank lines and lines starting with # are ignored (possibly may apply to ras versions only)
lines may contain a trailing comment provided there is whitespace following the object alias definition and the comment character '#'. (possibly may apply to ras versions only)