For the differences between Global Variables, ELCollections (ELC), and ADE, let’s start with a definition to make the discussion easier: I will call any study or strategy applied to a chart or RadarScreen an “analysis object”. Two indicators applied to the same chart are different analysis objects, and the same indicator applied to two charts is also two analysis objects. In fact, the same indicator applied twice to the same chart is two analysis objects as well. Each analysis object has its own context and its own data, which is stored in its variables and in the variables of the functions it calls.
In standard EasyLanguage, there is no way for two analysis objects to communicate with each other. Each analysis object sees only its own context and data. Thus, you can’t use standard EL to pass data between charts, between different indicators and strategies, or between symbols in RadarScreen. GVs, ELC, and ADE offer different solutions to this problem.
GVs provide a simple mechanism for storing data within one analysis object and then retrieving that data within a different analysis object. There are two kinds of global variables: named and numbered. Thus, you can store a particular value by name within one analysis object, and you can retrieve that value using the same name within another analysis object. Alternatively, you can store the value by a numeric ID within one object and retrieve the value using that ID within another object. That’s really about all there is to it.
One advantage of GVs is that they allow you to pass data not only between analysis objects, but also between applications. Charting, RadarScreen, and OptionStation are different applications, but you can use GVs to pass data between analysis objects in these applications. GV is the only utility I’m aware of that provides this particular capability.
ELCollections is not just a global variables utility, but it does allow for communication between analysis objects by providing shared collections. In fact, a single shared “map” provides the same capability as named global variables (except for the ability to pass data between applications), and a single shared “list” provides the same capability as numbered global variables. But beyond that, ELC allows you to create multiple shared maps and lists, and these data structures are arbitrarily expandable, unlike GVs where there is a fixed maximum number of variables. Furthermore, you can create collections of collections (e.g. a map of lists), which allows you to create data structures of arbitrary complexity. Finally, ELC provides a much richer set of capabilities such as inserting, deleting, sorting, statistics, and file access. All of these capabilities are available for shared collections as well as for local collections.
ADE is a global variables utility for time-series data. In other words, it is specifically designed to allow you to store data series for any symbol/interval within one analysis object, and then to access those data series within another analysis object. Notice that this is quite a bit different from GVs, where you can only store single values by name or numeric ID.
ADE is actually written almost completely in EasyLanguage using ELC, so it could be considered an ELC application. It is possible to use ELC directly to do anything that you can do with ADE, but ADE does a lot of the hard work for you. It allows you to store global time series data and access it from other analysis objects with a minimum of fuss.
One of the primary advantages of ADE over GVs is that you can backtest the process of passing data between analysis objects. This is very difficult to do with GVs for non-trivial cases. Since ADE provides automatic bar to bar mapping, even across different intervals, you can easily backtest applications that rely on passing data between different symbols or timeframes. It’s not really feasible to develop a backtestable portfolio application with GVs, but you could do it with ADE.
Note that ADE is not really a direct analog of GVs, since the former is for time-series data and the latter is for “single-point” data. However, if you have ADE, you also have ELC, which does provide a direct analog of GVs — and much more. The only thing GVs can do that ELC and ADE can’t do is pass data between applications. On the other hand, there are many, many things you can do with ELC and ADE that you can’t do with GVs. But as always, power has its cost: ELC and ADE are more complex and have a considerably steeper learning curve than GVs.
Here’s my personal summary of the pros and cons of these utilities:
Simple and relatively easy to learn.
Allows you to pass data between applications (Charting, RadarScreen, OptionStation).
Essentially a TS standard.
Not backtestable for non-trivial applications.
Has a fixed limit on the number of variables.
Has a single namespace for named variables, making name collisions more likely.
Has a single ID space for numbered vairables, making ID collisions more likely.
Provides only a “flat” variable space, so it’s not easy to store complex data.
No fixed limit on the amount of data that can be stored.
Provides as many namespaces or ID spaces as you need.
Allows for arbitrarily complex data structures.
Provides both global and local data structures.
Feature-rich: provides inserting, deleting, sorting, file access, and more.
More complex than GVs, so the learning curve is steeper.
Cannot pass data between applications (Charting, RadarScreen, OptionStation).
Not a TS standard.
Allows you to store global time-series data and access it from any analysis object.
Provides automatic bar to bar mapping between the same or different intervals.
Makes it possible to build backtestable inter-chart or inter-symbol systems.
Provides facilities to derive synthetic higher-timeframe bars.
Provides facilities for caching both raw and calculated data series in text files.
Includes support for TypeZero bars (tick and volume bars)
Same as for ELCollections.