New documentation
First commit, halfway through a major restructuring of documentation.
This commit is contained in:
Julian Molina committed
1 parent
f2ff0ce58b
commit
c2fb254a04
456 files changed
+44176
-253
No files matched your search
@@ -0,0 +1,190 @@
|
||||
---
|
||||
title: Product Definition
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-product-definition.html
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
Now that we have covered processes definitions, let's go back to the top level structure and do the same with the structure of *products definitions*.
|
||||
|
||||
We will take a look into Paula's Bollinger Standard Channels product and explore the three main definitions required: *records definition*, *dataset definitions*, *calculation procedures* and *data building procedure*.
|
||||
|
||||
| Records Definition | Dataset Definition | Calculations Procedure | Data Building Procedure |
|
||||
| :---: | :---: | :---: | :---: |
|
||||
|  |  |  | 
|
||||
|
||||
But first, let's take a look at the image below, showing a piece of configuration available within the main *product definition* node.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/69140177-4a050e80-0ac2-11ea-8374-114ca00a0d08.gif)
|
||||
|
||||
```js
|
||||
{
|
||||
"codeName": "Bollinger-Standard-Channels",
|
||||
"singularVariableName": "bollingerStandardChannel",
|
||||
"pluralVariableName": "bollingerStandardChannels"
|
||||
}
|
||||
```
|
||||
|
||||
* ```codeName``` is the name of the product as it is used within the bot's code.
|
||||
|
||||
* ```singularVariableName``` is the singular form of the name of the variable representing the product, as it will later be used on strategies (*i.e.:* ```bollingerChannel.direction```, where *bollingerChannel* is the name of the product as defined in its configuration and *direction* is the name of the property, as you will see later on in the Records Definition section).
|
||||
|
||||
* ```pluralVariableName``` is the plural form of the variable.
|
||||
|
||||
> **NOTE:** Remember that names set in configuration files are the ones used in the bot's code, not the label that may be set directly over the node. You may use a descriptive name on the label as a personal reference if you wish, but it will never be used in the code.
|
||||
|
||||
## Records Definition
|
||||
|
||||
This is where indicators define how many fields, what fields and in which order those fields will be stored in each record.
|
||||
|
||||
| Record Property |
|
||||
| :---: |
|
||||
|  |
|
||||
|
||||
Records may have as many properties as required. Remember that the order in which record properties are defined around the parent *record definition* node is the order in which they are stored in the actual record.
|
||||
|
||||
Record properties have an internal configuration:
|
||||
|
||||
```js
|
||||
{
|
||||
"codeName": "begin",
|
||||
"isString": false,
|
||||
"isCalculated": true
|
||||
}
|
||||
```
|
||||
|
||||
* ```codeName``` is the name of the record as it is used in the bot's code. Most record definitions will have a *begin* date and an *end* date.
|
||||
|
||||
* ```isString``` determines if the field is a text string or if, in turn, is a numeric field. Dates are stored in the *epoch* format, which is numeric. The reason why this configuration is important is because fields which are strings need to be stored between "double quotes".
|
||||
|
||||
* ```isCalculated``` determines if the field is stored in the dataset or if, instead, is calculated at a later stage, as explained in the *input to output cycle* earlier. A value *true* means that the record is not stored. In the case ```isCaculated``` is not defined in the configuration, it is assumed to be false.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/69139160-3ce72000-0ac0-11ea-9566-a259c9ea6194.gif)
|
||||
|
||||
The image above shows the four different record properties defined for Paula's Bollinger Standard Channels product.
|
||||
|
||||
You will notice some *record properties* may have a formula attached. **In this context, formulas are used to assign a value to the property.**
|
||||
|
||||
The formula may act in slightly different ways depending on the ```isCaculated``` attribute in the *property definition* configuration:
|
||||
|
||||
* When a property is calculated (```"isCalculated": true```), the formula assigns to the property a value that is calculated in the *calculations procedure* (we will study this procedure further down this explantion). Even if the property is not stored in the dataset, it is made available as a *calculated property* to other bots that may have the dataset as input.
|
||||
|
||||
* When a property is not calculated (```"isCalculated": false``` or the attribute is not defined in the configuration) the formula is applied in the *data building procedure* (we will get to that later on too).
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/69168829-a6365580-0af7-11ea-8583-f39a19a6465b.gif)
|
||||
|
||||
The image above shows Chris' Bollinger Band product *record definitions*. Notice how the first five properties have no formula while the last two remaining properties do have formulas. These last two properties are calculated.
|
||||
|
||||
## Dataset Definition
|
||||
|
||||
Datasets are defined via a configuration script that contains roughly the following information:
|
||||
|
||||
```js
|
||||
{
|
||||
"codeName": "Multi-Period-Market",
|
||||
"type": "Market Files",
|
||||
"validPeriods": [ "24-hs", "12-hs", "08-hs", "06-hs", "04-hs", "03-hs", "02-hs", "01-hs" ],
|
||||
"filePath": "AAMasters/AAPaula.1.0/AACloud.1.1/@Exchange/dataSet.V1/Output/Bollinger-Standard-Channels/Multi-Period-Market/@Period",
|
||||
"fileName": "@AssetA_@AssetB.json"
|
||||
}
|
||||
```
|
||||
|
||||
The code is pretty much self explanatory:
|
||||
|
||||
* ```codeName``` is the name of the dataset as used within the code.
|
||||
|
||||
* ```type``` refers to the type of dataset as described in the [Outputs](outputs#types-of-datasets) section.
|
||||
|
||||
* ```validPeriods``` refers to the timeperiods covered in the dataset.
|
||||
|
||||
* ```filePath``` sets the path on which files will be stored.
|
||||
|
||||
* ```fileName``` sets the name of the files that constitute the dataset.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/69176546-324f7980-0b06-11ea-91cb-1b421f62d466.gif)
|
||||
|
||||
The image above shows the reference that needs to be present between the *dataset definition* and the corresponding *output dataset* defined as the *process output*.
|
||||
|
||||
## Calculations Procedure
|
||||
|
||||
The calculations procedure is where the processing of calculated properties takes place.
|
||||
|
||||
| Procedure Initialization | Procedure Loop |
|
||||
| :---: | :---: |
|
||||
|  |  |
|
||||
|
||||
The procedure has two structure of nodes:
|
||||
|
||||
* **Procedure initialization** allows running a piece of code before the recursive process starts, and it is mostly used to initialize variables.
|
||||
|
||||
* **Procedure loop** holds the code that will be applied to calculate the properties for each record in a recursive manner.
|
||||
|
||||
Let's take Chris' Bollinger Bands *calculation procedure* as an example.
|
||||
|
||||
The code for its *procedure initialization* is:
|
||||
|
||||
```js
|
||||
variable.lastMovingAverage = 0
|
||||
variable.SIDE_TOLERANCE = 0.5 * system.timePeriod / system.ONE_DAY_IN_MILISECONDS
|
||||
variable.SMALL_SLOPE = 1.0 * system.timePeriod / system.ONE_DAY_IN_MILISECONDS
|
||||
variable.MEDIUM_SLOPE = 2.0 * system.timePeriod / system.ONE_DAY_IN_MILISECONDS
|
||||
variable.HIGH_SLOPE = 4.0 * system.timePeriod / system.ONE_DAY_IN_MILISECONDS
|
||||
```
|
||||
|
||||
As you may be able to gather from the code snippet above, five different variables are being initialized with simple calculations.
|
||||
|
||||
The code for the *procedure loop* section is:
|
||||
|
||||
```js
|
||||
if (variable.lastMovingAverage > product.bollingerBand.movingAverage) { variable.direction = "Down" }
|
||||
if (variable.lastMovingAverage < product.bollingerBand.movingAverage) { variable.direction = "Up" }
|
||||
if (variable.lastMovingAverage === product.bollingerBand.movingAverage) { variable.direction = "Side" }
|
||||
|
||||
variable.delta = Math.abs(product.bollingerBand.movingAverage - variable.lastMovingAverage)
|
||||
|
||||
variable.slope = "Extreme"
|
||||
if (variable.delta < product.bollingerBand.movingAverage * variable.HIGH_SLOPE / 100) { variable.slope = "Steep" }
|
||||
if (variable.delta < product.bollingerBand.movingAverage * variable.MEDIUM_SLOPE / 100) { variable.slope = "Medium" }
|
||||
if (variable.delta < product.bollingerBand.movingAverage * variable.SMALL_SLOPE / 100) { variable.slope = "Gentle" }
|
||||
if (variable.delta < product.bollingerBand.movingAverage * variable.SIDE_TOLERANCE / 100) { variable.slope = "Side" }
|
||||
|
||||
variable.lastMovingAverage = product.bollingerBand.movingAverage
|
||||
```
|
||||
|
||||
As you may see, the first block of code determines the direction of the channel (Down, Up or Side), while the second section determines the inclination of the slope of the Moving Average (Extreme, Steep, Medium, Gentle, side).
|
||||
|
||||
## Data Building Procedure
|
||||
|
||||
The *data building procedure* is the section in which the operations the bot will perform on the input dataset are defined. These operations should result in the values of the properties previously defined.
|
||||
|
||||
| Procedure Initialization | Procedure Loop |
|
||||
| :---: | :---: |
|
||||
|  |  |
|
||||
|
||||
As you may figure, the *data building procedure* works pretty much like the *calculations procedure*, with a *procedure initialization* structure of nodes and a *procedure loop* structure of nodes.
|
||||
|
||||
Let's take a peek at the code Paula uses to build the Bollinger Standard Channels out of the Bollinger Bands dataset offered by Chris.
|
||||
|
||||
Procedure initialization:
|
||||
|
||||
```js
|
||||
variable.period = 1
|
||||
```
|
||||
|
||||
Procedure loop:
|
||||
|
||||
```js
|
||||
if (record.previous !== undefined) {
|
||||
if (record.current.direction === record.previous.direction) {
|
||||
variable.period++
|
||||
} else {
|
||||
variable.period = 1
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Simple right?
|
||||
|
||||
Indeed. You may recall that the Bollinger Standard Channel product has four different *record properties* defined: *begin* and *end*, which are dates taken directly from the input data source, *direction*, which is handed by Chris as a calculated property, and *period*, which is all Paula needs to calculate to build this new dataset.
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: "Overview"
|
||||
sidebar: algorithmic_sidebar
|
||||
permalink: algorithmic-trading-system-overview.html
|
||||
|
||||
---
|
||||
|
||||
{{ site.pages | where: "permalink", "systematic-trading-system-overview.html" }}
|
||||
|
||||
@@ -0,0 +1,98 @@
|
||||
---
|
||||
title: Advanced Backtesting
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-advanced-backtesting.html
|
||||
---
|
||||
|
||||
## Adding New Sessions
|
||||
|
||||
The platform allows for having multiple testing sessions. You may add and work with multiple sessions in two different ways:
|
||||
|
||||
**1. Independent Task**
|
||||
|
||||
Each task is an independent process at the *operating system* level, which handles its own memory allotment, and may be controlled and killed independently.
|
||||
|
||||
A process running under its own task may not be affected by errors occurring on other processes.
|
||||
|
||||
For the reasons above, you may choose to run each testing session on separate tasks.
|
||||
|
||||
The easiest way to create sessions under this configuration is by cloning an existing task and dropping the cloned file back on the Designer. Once the new task is on the Designer, you may chain it to your preferred task manager.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/70354911-23d8c000-1871-11ea-8a6c-552ab6e206ce.gif)
|
||||
|
||||
> **NOTE:** You may even choose to set up an independent task manager. Simply go to the *My Computer* network node and click *Add Task Manager*.
|
||||
|
||||
**2. Shared Task**
|
||||
|
||||
You may decide that you don't need independent tasks for each of your backtesting sessions or prefer to handle multiple sessions under one task.
|
||||
|
||||
To create new sessions under such configuration you need to clone the process that runs one of the existing sessions, and drop the clone on to the Designer. Then, structure of nodes the process to the trading bot instance and give the session a new name.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67272829-90644f00-f4bd-11e9-9559-3f01233ecee8.gif)
|
||||
|
||||
The number of backtesting sessions you may run simultaneously is capped by your machine's processing capacity. Current tests indicate that a dual-core processor at 2.4GHz may process up to 5 sessions at the same time without compromising the machine's performance.
|
||||
|
||||
Running more sessions than the optimal number your machine may process efficiently may result in the sessions taking more time to process than if they were run in a sequence.
|
||||
|
||||
## Linking Processes and Sessions
|
||||
|
||||
If you followed the above process, cloning the whole task or process structure of nodes to duplicate a session, you do not need to do anything else... your new session is already up and running.
|
||||
|
||||
However, if you decide to create a new structure of nodes by creating each individual node at the time, you will need to continue with the following steps.
|
||||
|
||||
### Process
|
||||
|
||||
Every time you create a new session you need to establish a reference from the process instance to the *Multi-Period* process of *Jason*, the trading bot. Jason *lives* within the *Masters* team.
|
||||
|
||||
To do this, you first need to locate Jason. Hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>M</kbd> (*M* for *Masters*) and click  on the menu.
|
||||
|
||||
Now hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>J</kbd> (*J* for *Jason*) and click  on the menu. Look around among Jason's offspring nodes and find the *Multi-Period* process definition.
|
||||
|
||||
Now you need to drag your process all the way here and establish teh reference with Jason's *Multi-Period* process definition by pulling it close using the right button of the mouse. Once the reference is established, you may let your process drift back to where it belongs.
|
||||
|
||||
The easy way to drag the process all across the workspace is to right-click it, and use the keyboard <kbd>Ctrl or ⌘</kbd> + <kbd>↑</kbd> and <kbd>←</kbd> to start panning in the direction of Jason. Just follow the rest of the grey lines corresponding to the references of other processes to find your destination.
|
||||
|
||||
Once you are in the vicinity of Jason, stop, take a pause and pin the data process so that it doesn't fly back to its parent node. Now locate the *Multi-Period* process definition, right-click on the process instance you just dragged and establish the reference. Make sure you unpin the process instance so that it flys back home.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/70355145-b2e5d800-1871-11ea-9bb3-49148772307c.gif)
|
||||
|
||||
> **PRO TIP:** if you need to link several processes, you may want to reverse the procedure and drag Jason's *Multi-Period* process definition towards the area where you created the new sessions instead.
|
||||
|
||||
### Session
|
||||
|
||||
You also need to establish a reference between the session and the definition you inted to run the session on. The procedure is similar to the above. Drag the session towards the definition you intend to test on and pull it closer using the right button of the mouse to establish the reference.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/70355703-0e649580-1873-11ea-925e-1f0250148d2c.gif)
|
||||
|
||||
## Sessions Folder Name
|
||||
|
||||
Before you use the new session, you may want to edit the configuration by clicking *Edit Session* on the menu:
|
||||
|
||||
```js
|
||||
{
|
||||
"folderName": "Session-Name"
|
||||
}
|
||||
```
|
||||
|
||||
The session name you use in the configuration will be taken to name the folder in which the trading bot will store the simulations corresponding to this session. This may be useful should you ever need to look directly into the data.
|
||||
|
||||
## Testing Logic Variations
|
||||
|
||||
Being able to run multiple backtesting sessions allows you to speed up the strategy tuning stage.
|
||||
|
||||
For instance, you may want to check how different variations of a condition in the *take position event* affect the results. To tests all variations at the same time, you would:
|
||||
|
||||
**1.** Replicate a backtesting session by cloning the corresponding *process* node (along with its offspring) and dropping the clone back on your workspace, as many times as you require, [attaching it](Designer-Interface#detachment-and-attachment-of-nodes) to an available trading bot.
|
||||
|
||||
**2.** Rename each backtesting session with a significant name that is related to the different variations of the condition you wish to test.
|
||||
|
||||
**3.** Set up the first variation of the condition and run the corresponding backtesting session. Replace the first variation with the second one, and launch the second backtesting session. Repeat as many times as desired.
|
||||
|
||||
## Testing on Non-Linear Date Ranges
|
||||
|
||||
It is a known fact that testing and optimizing a strategy over a complete dataset may lead to [overfitting](https://en.wikipedia.org/wiki/Overfitting).
|
||||
|
||||
Being able to set up multiple backtesting operations allows you to segment your dataset as you may consider appropriate, for instance, creating sessions to test only on odd months, every three or six months, or in a more random-like arrangement.
|
||||
|
||||
The system provides enough flexibility to accommodate different backtesting criteria and styles. It is up to you how to set it up.
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: Anatomy of an indicator
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-anatomy-of-an-indicator.html
|
||||
---
|
||||
|
||||
The tools available for you to turn an existing dataset into a new, value-added product, are scattered througout the definitions of the indicator itself.
|
||||
|
||||
We will dive into Paula and Chris—two of the indicators that ship with the platform—to learn how these bots are structured.
|
||||
|
||||
| Masters Team | Paula | Chris |
|
||||
| :---: | :---: | :---: |
|
||||
|  |  |  |
|
||||
|
||||
It is highly recommended that you follow this exploration directly on the platform, so that you may clearly see the relationship among nodes and play with the hierachy as we advance.
|
||||
|
||||
Paula and Chris are offspring nodes of the Masters Team hierarchy.
|
||||
|
||||
To find the Masters team, hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>M</kbd> (*M* for *Masters*) and click  on the menu.
|
||||
|
||||
To find Paula, hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>P</kbd> (*P* for *Paula*).
|
||||
|
||||
To find Chris, hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>C</kbd> (*C* for *Chris*).
|
||||
|
||||
> **NOTE:** At this moment, only Paula's definitions are complete and fully set up in the Masters Team. You may explore the indicators in the Sparta Team for more examples (hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>S</kbd> (*C* for *Sparta*)).
|
||||
|
||||
## Top Level Structure
|
||||
|
||||
Paula is the indicator building Bollinger Channels and Bollinger SubChannels (along with chanels and subchannel objects, used by plotters), based on the Bollinger Bands created by Chris.
|
||||
|
||||
| Process Definition | Product Definition |
|
||||
| :---: | :---: |
|
||||
|  |  |
|
||||
|
||||
We established earlier that bots run *processes* which create *products*. As such, the first order of business to describe an indicator bot is to define its processes and products.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/68942711-8cb8a500-07a9-11ea-9e87-8fac12e3a143.png)
|
||||
|
||||
> **NOTE:** When we analyze the way in which nodes are represented within a hierarchy, it may be important to note the *order* in which they are displayed around its parent object. In this case, the first child node of Paula is the Multi-Period-Market Process Definition, as it is the first in the clock-wise direction from the line chaining Paula to its parent node, the Masters Team. In most cases, the order of nodes around its parent determine the order of execution, or the order in which nodes are computed in whatever process is involved.
|
||||
|
||||
An indicator may have several several processes and several products. In the case of Paula, she has two processes and four products.
|
||||
|
||||
The reason why Paula has two processes is related to the products Paula creates and the way each dataset is structured.
|
||||
|
||||
The Multi-Period-Market process stores data in *market files* while the Multi-Period-Daily process stores files in the *daily file* type of dataset. This is a common occurence in most indicators. The reason is that this is the desired behavior so that data may be consumed efficiently both in the lower and higher frequency time periods.
|
||||
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: Backups
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-backups.html
|
||||
---
|
||||
|
||||
> **NOTE:** To understand backups, you first need to be familiar with [*references*](References).
|
||||
|
||||
## Introduction
|
||||
|
||||
When you back up a single node, a structure of nodes, a complete hierarchy or even the workspace, all existing references are stored in the resulting JSON file.
|
||||
|
||||
When you restore a workspace backup, the current workspace is discarded entirely and replaced with the backup. Now, let's see what happens when you restore anything other than a workspace, that is, any of the data structures contained in the workspace.
|
||||
|
||||
In particular, what we want to analyze is what happens with each type of reference that may be present in the structure.
|
||||
|
||||
What happens with each type of reference when the back up is restored varies depending on one factor: the original structure is present in the workspace, or instead, it has been deleted prior to restoring the backup.
|
||||
|
||||
## Outgoing References
|
||||
|
||||
**Outgoing references are kept no matter if the original structure of nodes still exists or not.**
|
||||
|
||||
For example, in a task set up for running a testing session, the trading bot process instance references to the trading bot Multi-Period process, and the session references a definition.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71101855-b2293c00-21b7-11ea-864e-817f74e17a34.gif)
|
||||
|
||||
As the capture above shows, when restoring the backup of a task, both outgoing references are maintained, even when the original task has not been deleted.
|
||||
|
||||
This means that restoring a back up is a viable way to duplicate structure of nodes with outgoing references when you expect outgoing references to be preserved.
|
||||
|
||||
## Incoming References
|
||||
|
||||
**Incoming references are restored only when the original structure of nodes is deleted before restoring the backup.**
|
||||
|
||||
Let's take a definition as an example. Definitions usually have several incoming references originating at different testing and live trading sessions.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71103003-ac345a80-21b9-11ea-947c-6e2c59c299c5.gif)
|
||||
|
||||
The capture above shows that restoring a backup of a definition when the orginal definition is still in the workspace causes the incoming references to be lost.
|
||||
|
||||
However, as the capture below shows, if the original structure of nodes is deleted before the backup is restored, then the incoming references are restored as well.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71103005-ac345a80-21b9-11ea-8c0f-5ee78f15aa7a.gif)
|
||||
|
||||
## Internal References
|
||||
|
||||
**Internal references are kept *internally* only when the original structure of nodes is deleted before restoring the backup. If the original structure of nodes is present, then the references will point to the original nodes on the original structure of nodes.**
|
||||
|
||||
Continuing with the example explored earlier, on the [references](References) page, let's see what happens when we restore a backup of a *shapes* node without deleting the original node first:
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71107152-de958600-21c0-11ea-8667-d7d56ed24bfb.gif)
|
||||
|
||||
As expected, the references from vertices in the restored backup do not point to the points in the same structure, but instead point to the original points in the original strucutre.
|
||||
|
||||
On the other hand, if the original structure of nodes is deleted before restoring the backup, then the references point to the nodes within the same structure:
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71107153-de958600-21c0-11ea-9855-532e2d0631d2.gif)
|
||||
|
||||
## Conclusion
|
||||
|
||||
The backup feature is designed to preserve the integrity of references as you would expect when you wish to restore a data structure to a previous state of affairs.
|
||||
|
||||
However, the tool's particular behavior when restoring a backup without deleting the original structure may be of use in certain ocassions. This is particularly true because in such cases, the backup feature behaves differently than the clone feature, as you will learn on the next page.
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: Bots
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-bots.html
|
||||
---
|
||||
|
||||
There are three different kinds of bots, sometimes called *algorithms* interchangeably:
|
||||
|
||||
* **Sensor Bots:** they extract raw data from external sources (*i.e.: exchanges, Twitter, etc.*) and store it in the platform's standardized format for others to consume;
|
||||
|
||||
* **Indicator Bots:** they process available information that other bots may have generated to produce elaborate datasets for others to consume;
|
||||
|
||||
* **Trading Bot:** based on datasets exposed as products by other bots (counting sensors, indicators and even other trading bots), a trading bot applies the trading logic defined on a trading system to, on one side, generate a complete trading simulation (outputting datasets that include trades, the action of strategies, validation of conditions, etc.), and on the other side, manages the execution of orders when on a forward testing or live trading session.
|
||||
|
||||
What these different kinds of bots have in common is that they all create _products_ that others can consume. To do this, they run _processes_ that produce and store _datasets_. That is, the product a bot creates may result in one or more datasets.
|
||||
|
||||
Each bot may have several processes, and processes don't necessarily have a one-to-one relationship with products. That is, a product can be the result of the work of one or more processes.
|
||||
|
||||
The datasets processes create are part of the _output_ of bots, and are stored in the file system. Processes also produce and store a second valuable piece of information: _status reports_.
|
||||
|
||||
Status reports serve as temporal annotations that bots read every time they are called by the platform to know what was done in the previous run and what the state of affairs is at present. Status reports are dynamic, and they change constantly, with updates after every single run of the associated process.
|
||||
|
||||
Upon execution, bots run in a branched sequence determined by their *status and data dependecies*. For instance, if bot A depends on the data produced by bot B, then bot A will be configured to run as soon as bot B finishes it's execution.
|
||||
|
||||
Each bot runs for as long as it may require to perform its job, usually in the order of a few seconds, and remain asleep until the next cycle is due.
|
||||
|
||||
The last pages of this chapter will go deeper into these few concepts, for those who may want to learn the intricacies.
|
||||
@@ -0,0 +1,355 @@
|
||||
---
|
||||
title: Build a Plotter
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-build-a-plotter.html
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
A *plotter* is a device used to produce a graphic representation of the data generated by indicators. They usually have a one-to-one relationship with indicators, as they are often created as a customized solution.
|
||||
|
||||
However, in practice, there is no constraint to creating any number of plotters for a single indicator or a single plotter for multiple indicators.
|
||||
|
||||
This page takes you through the process of creating a plotter. for further reference, feel free to explore the following list of plotters that ship with the app:
|
||||
|
||||
* Team Masters: Plotters-Bollinger-Bands, Percentage B *module*.
|
||||
|
||||
* Team Sparta: SMA, RSI and EMA, all *modules*.
|
||||
|
||||
| Team | Plotter |
|
||||
| :---: | :---: |
|
||||
|  |  |
|
||||
|
||||
Plotters are created at the root of the *Teams* hierarchy and have the most basic configuration:
|
||||
|
||||
```js
|
||||
{
|
||||
"codeName": "Plotter Name"
|
||||
}
|
||||
```
|
||||
|
||||
## Plotter Module
|
||||
|
||||
| Plotter | Plotter Module |
|
||||
| :---: | :---: |
|
||||
|  |  |
|
||||
|
||||
A plotter module is a device within a plotter that contains the definitions to create the visualization for a particular layer populating the *Layers Panel* in the Charts.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71016077-eab41180-20f4-11ea-87e7-7262ff10a1ab.gif)
|
||||
|
||||
A single plotter may have several modules. You may choose to use different modules to plot each product of the indicator, or as best suits the expected use-pattern.
|
||||
|
||||
In cases in which the module's job is to render graphics directly over the same *price scale* used by candles (*i.e.: Moving Averages, Bollinger Bands, etc.*), then its configuration is very simple:
|
||||
|
||||
```js
|
||||
{
|
||||
"codeName": "Plotter-Name",
|
||||
"banner": "Band"
|
||||
}
|
||||
```
|
||||
|
||||
In other cases, you will want to render information on a different scale, for example, in the case of oscillators (*i.e.: Relative Strength Index, Percentage Bandwidth, etc.*). For such cases, you will use the following type of configuration:
|
||||
|
||||
```js
|
||||
{
|
||||
"codeName": "Plotter-Name",
|
||||
"slot": {
|
||||
"number": 3,
|
||||
"minValue": 0,
|
||||
"maxValue": 100
|
||||
},
|
||||
"banner": "Oscillator"
|
||||
}
|
||||
```
|
||||
* ```codeName``` is the name used in the code to refer to the module.
|
||||
|
||||
* ```slot, number``` is an integer from 2 to 11, 2 representing the top-most section of the screen and 11 the bottom-most section.
|
||||
|
||||
* ```slot, minValue``` is the minimum possible value of the scale (for example, 0 for RSI).
|
||||
|
||||
* ```slot, maxValue``` is the maximum possible value of the scale (for example, 100 for RSI).
|
||||
|
||||
* ```banner``` is the name of the image that illustrates the corresponding layer in the Layers Panel. In case the banner is not specified, the *default banner* is used. Current possible values are:
|
||||
|
||||
| Value | Image|
|
||||
| :---: | :---: |
|
||||
| ```Default``` |  |
|
||||
| ```Histogram``` |  |
|
||||
| ```Band``` |  |
|
||||
| ```Moving Average``` |  |
|
||||
| ```Oscillator``` |  |
|
||||
| ```Trend``` |  |
|
||||
|
||||
You may also add and use your own images. To do that:
|
||||
|
||||
1. name your image in the following format: ```Your-Image-Banner.png```;
|
||||
|
||||
1. place your images in the ```WebServer\Images\``` folder;
|
||||
|
||||
1. in the configuration of the module, use the name without the *-Banner* ending (e.g.: ```"banner": "Your-Image"```)
|
||||
|
||||
Beyond the module's configuration, the most important aspect of a module's behavior is obtaining data from bot's *products*. For a module to be able to obtain data from a certain product, you need to link the said product to your module.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71016079-eab41180-20f4-11ea-8afb-96321f9c68d8.gif)
|
||||
|
||||
### Shapes
|
||||
|
||||
| Plotter Module | Shapes |
|
||||
| :---: | :---: |
|
||||
|  |  |
|
||||
|
||||
The *shapes* node contains all of the definitions required to render graphics on the screen.
|
||||
|
||||
A plotter recursively renders graphics for each period (or candle). This means that you will define—in generic terms—what shapes need to be drawn for a single period, and the plotter will do the same thing for every candle that is visible on the screen at any point in time, for any time period, as long as the corresponding data is available.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71016080-eab41180-20f4-11ea-84c6-a514b87d568f.gif)
|
||||
|
||||
In general terms, the process of defining what is going to be rendered on the screen consist of the following four steps:
|
||||
|
||||
#### 1. Identifying points defined by ```[x,y]``` coordinates
|
||||
|
||||
| Points Chart | Point | Point Formula |
|
||||
| :---: | :---: | :---: |
|
||||
|  |  |  |
|
||||
|
||||
Add a *points chart* node to define the *points* you will use. The points are ultimately defined by their *point formulas*.
|
||||
|
||||
In the case you wish to represent some form of variation of the price over time, then a typical point formula consists of the following two coordinates: ```x = datatime``` and ```y = rate```.
|
||||
|
||||
For example:
|
||||
|
||||
**Point *SMA 20 Begin***
|
||||
```js
|
||||
x = record.begin
|
||||
y = record.previous.sma20
|
||||
```
|
||||
|
||||
The example above shows the definition of the first of two points necessary to draw the segment of the 20-periods SMA curve for any particular period or candle. In this case, ```x = record.begin``` is the starting datetime of the period (or candle) and ```y = record.previous.sma20``` is the rate of the 20-periods SMA of the previous candle.
|
||||
|
||||
> **NOTE:** Make sure you give each point a significant name, as you will later need to reference them when you define the styles of the polygons you are drawing.
|
||||
|
||||
To complete the line segment corresponding to a single candle, you will need the closing datetime of the candle and the closing rate for the 20-periods SMA:
|
||||
|
||||
**Point *SMA 20 End***
|
||||
```js
|
||||
x = record.end
|
||||
y = record.sma20
|
||||
```
|
||||
|
||||
The above system works very well for plotting all sorts of information over the candles, on the charts.
|
||||
|
||||
Let's see what happens when instead of plotting graphics directly over the candles, you are building, for example, an oscillator.
|
||||
|
||||
An oscillator like RSI will too need the definition of the starting and ending datetime of the period as the value for the *x-axis*. However, the value for *axis y* will fit the scale defined on the plotter module configuration.
|
||||
|
||||
Anyway, the points definition is just as straight forward, for example:
|
||||
|
||||
**Point *RSI Begin***
|
||||
```js
|
||||
x = record.begin
|
||||
y = record.previous.value
|
||||
```
|
||||
|
||||
**Point *RSI End***
|
||||
```js
|
||||
x = record.end
|
||||
y = record.value
|
||||
```
|
||||
|
||||
The chart points you define on this first step may be used as many times as you may need for as many polygons as you wish. For example, the current RSI 14 plotter module features the following four points:
|
||||
|
||||
**Point *Begin 20***
|
||||
```js
|
||||
x = record.begin
|
||||
y = 20
|
||||
```
|
||||
|
||||
**Point *End 20***
|
||||
```js
|
||||
x = record.end
|
||||
y = 20
|
||||
```
|
||||
|
||||
**Point *Begin 30***
|
||||
```js
|
||||
x = record.begin
|
||||
y = 30
|
||||
```
|
||||
|
||||
**Point *End 30***
|
||||
```js
|
||||
x = record.end
|
||||
y = 30
|
||||
```
|
||||
|
||||
Those four points are later used to paint the background of the RSI 20 to 30 value range of the RSI chart slot. The first two points are also used to draw the dotted line that signaling the 20-value mark, and the last two are used for the dotted line indicating the 30-value mark.
|
||||
|
||||
#### 2. Defining polygons
|
||||
|
||||
| Polygon | Vertex |
|
||||
| :---: | :---: |
|
||||
| |  |
|
||||
|
||||
The first few nodes that define a polygon are its vertices. All you need to do to define the vertices of a polygon is to create them and establish a reference to the corresponding *chart points* you previously defined.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71016081-eb4ca800-20f4-11ea-8fee-4d38ecfb0596.gif)
|
||||
|
||||
As stated earlier, for drawing curves you will need two vertices. For painting the background of a chart, you will likely need four.
|
||||
|
||||
> **NOTE:** Bear in mind that the order in which you create the vertices in a polygon, or actually, the final order in which they are arranged around the parent polygon node when their *rotational symmetry* property is selected, is the order in which the plotter will compute the points. This means that, if you are drawing a box, you need to make sure the points are ordered appropriately. Imagine you need to draw a box on a piece of paper without lifting the pencil... that is how the plotter will do it.
|
||||
|
||||
You may define as many polygons as you need.
|
||||
|
||||
> **NOTE:** The order in which polygons are ordered around the parent *shapes* node determines the order in which they are drawn on the screen. If you have intersecting polygons, those drawn last will be drawn on top of those drawn first.
|
||||
|
||||
#### 3. Defining default styles
|
||||
|
||||
Now that your polygons are mathematically defined, all that is left is defining their style. To do that, you have the following nodes available:
|
||||
|
||||
| Polygon | Body | Border | Style |
|
||||
| :---: | :---: | :---: | :---: |
|
||||
| |  |  |  |
|
||||
|
||||
You will create a *body* node when you wish to create a *fill* for a closed polygon of at least three vertices.
|
||||
|
||||
You will create a *border* node when you wish to create a *stroke* for the outlines of any sort of polygon, either closed or open.
|
||||
|
||||
Both of these nodes feature the option to add a style. When you add a style to a *body* or *border* node, the style acts as the default style.
|
||||
|
||||
A typical definition for a *body* node looks like this:
|
||||
|
||||
```js
|
||||
{
|
||||
"default": {
|
||||
"opacity": 0.2,
|
||||
"paletteColor": "UI_COLOR.DARK_TURQUOISE"
|
||||
},
|
||||
"atMousePosition": {
|
||||
"opacity": 0.3,
|
||||
"paletteColor": "UI_COLOR.DARK_TURQUOISE"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
A typical definition for a *border* node has a couple more properties:
|
||||
|
||||
```js
|
||||
{
|
||||
"default": {
|
||||
"opacity": 0.2,
|
||||
"lineWidth": 1,
|
||||
"lineDash": [0,0],
|
||||
"paletteColor": "UI_COLOR.DARK_TURQUOISE"
|
||||
},
|
||||
"atMousePosition": {
|
||||
"opacity": 0.3,
|
||||
"lineWidth": 2,
|
||||
"lineDash": [0,0],
|
||||
"paletteColor": "UI_COLOR.RUSTED_RED"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The first section of the definition refers, as explicitly stated, to the default state of the style.
|
||||
|
||||
The second section refers to the style assigned to the column or period on which the mouse pointer is located. This is very useful for highlighting the specific zone of interest as the user browses the charts.
|
||||
|
||||
* ```opacity``` is probably self-explanatory: it may range from ```0``` for a fully transparent object to ```1``` for a solid object.
|
||||
|
||||
* ```paletteColor``` sets the color for the *fill* or *stroke* in cases of polygon bodies and polygon borders respectively. Use the variable ```UI_COLOR``` followed by a ```.``` and any of the properties in the following list for a selection of currently available colors:
|
||||
|
||||
| Variable Value | RGB Value |
|
||||
| :--- | :--- |
|
||||
| ```DARK``` | 48, 48, 54 |
|
||||
| ```LIGHT``` | 234, 226, 222 |
|
||||
| ```GREY``` | 150, 150, 150 |
|
||||
| ```LIGHT_GREY``` | 247, 247, 247 |
|
||||
| ```WHITE``` | 255, 255, 255 |
|
||||
| ```BLACK``` | 0, 0, 0 |
|
||||
| ```GOLDEN_ORANGE``` | 240, 162, 2 |
|
||||
| ```RUSTED_RED``` | 204, 88, 53 |
|
||||
| ```GREEN``` | 188, 214, 67 |
|
||||
| ```RED``` | 223, 70, 60 |
|
||||
| ```PATINATED_TURQUOISE``` | 27, 153, 139 |
|
||||
| ```TITANIUM_YELLOW``` | 244, 228, 9 |
|
||||
| ```MANGANESE_PURPLE``` | 91,80, 122 |
|
||||
| ```TURQUOISE``` | 74, 207, 217 |
|
||||
| ```DARK_TURQUOISE``` | 2, 149, 170 |
|
||||
|
||||
* ```lineWidth``` is the width of the border line, which should be greater than 0.
|
||||
|
||||
* ```lineDash``` is used to turn the border into a dashed-line; the first value corresponds to the length of the dash while the second value defines the length of the space.
|
||||
|
||||
> **NOTE:** When using dashed lines, bear in mind that the drawing from one column or period is independent of the next. Big values for dashes and spaces may not work well for lines that span several columns.
|
||||
|
||||
#### 4. Defining conditional styles
|
||||
|
||||
A great way to introduce additional intelligence on the visual representation of data is to use styles that respond to certain conditions.
|
||||
|
||||
For example, the *Percentage Bandwidth* plotter module assigns a different color to the Moving Average line when it's going up than to when it's going down.
|
||||
|
||||
To do that, after defining the default style, you may select *Add Style Condition* from the *body* or *border* node menu.
|
||||
|
||||
| Style Condition | Style |
|
||||
| :---: | :---: |
|
||||
|  |  |
|
||||
|
||||
*Style conditions* work pretty much like conditions you use on your trading systems. The main difference is that the variables available are solely those provided by the indicator products that may be linked to the plotter.
|
||||
|
||||
To continue the example of the Percentage Bandwidth plotter, the following is the condition that determines the newly added styles:
|
||||
|
||||
```js
|
||||
record.previous.movingAverage > record.movingAverage
|
||||
```
|
||||
|
||||
As hinted earlier, when the condition is met, the default style is modified by a second style that may be created on the menu of the *style condition* node.
|
||||
|
||||
The definition of secondary styles is slightly different from that of the default style, as—in such cases—you may no longer define the ```atMousePosition``` property:
|
||||
|
||||
```js
|
||||
{
|
||||
"opacity": 0.55,
|
||||
"lineWidth": 1,
|
||||
"lineDash": [0,0],
|
||||
"paletteColor": "UI_COLOR.RED"
|
||||
}
|
||||
```
|
||||
|
||||
You may define as many *style conditions* as you wish. The system evaluates all style conditions in a sequential order determined by their position in the rotational symmetry around the parent node.
|
||||
|
||||
Each condition that is met may modify or add up to the resulting style that is rendered on screen. That is, the final style is the result of the sequential application of the styles defined for each condition that is met, on top of the default style.
|
||||
|
||||
### Panels
|
||||
|
||||
Beyond the graphic representation of data over the charts, plotters may also feature a *data panel*, that is, a numerical representation of the data showing the exact figures corresponding to the column or period that is in focus (the point of the charts where the mouse pointer is at any point in time).
|
||||
|
||||
| Panel | Panel Data | Data Formula |
|
||||
| :---: | :---: | :---: |
|
||||
|  |  |  |
|
||||
|
||||
Once you select *Add Plotter Panel* on the plotter module menu, you may start adding as many data fields as you wish.
|
||||
|
||||
The platform will render a panel featuring a centered, single-column vertical arrangement of data. The label of each data field on the panel is given (by default) by the label you set for the *panel data* node.
|
||||
|
||||
The configuration of a *panel data* node allows you to determine the number of decimal places for the corresponding data field:
|
||||
|
||||
```js
|
||||
{
|
||||
"valueDecimals": 2
|
||||
}
|
||||
```
|
||||
|
||||
If you wish to override the default manner in which the data is assembled on the panel, you may include and define the following properties:
|
||||
|
||||
```js
|
||||
{
|
||||
"labelText": "Your Label",
|
||||
"labelPosition": 15,
|
||||
"valuePosition": 20,
|
||||
"valueDecimals": 2
|
||||
}
|
||||
```
|
||||
|
||||
* ```labelPosition``` and ```valuePosition``` represent the vertical distance of the corresponding field with the top margin of the panel.
|
||||
@@ -0,0 +1,407 @@
|
||||
---
|
||||
title: Build an Indicator
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-build-an-indicator.html
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
We will go through the process required to set up a new indicator bot from scratch, using the Simple Moving Average (SMA) indicator that ships with the platform as example.
|
||||
|
||||
The indicator's *Popular* product calculates the SMA on 20, 50, 100 and 200 periods, using Olivia's candles as input, storing two datasets of market and daily files.
|
||||
|
||||
You may follow these sets of instructions to build your first indicator. If that is what you are doing, you will follow the same process described herein, but some of the actions may vary depending on what exactly you are trying to achieve.
|
||||
|
||||
In that sense, a little planning is in order before you start. You will need to ask yourself some questions so that you have a clear idea of what you wish to do:
|
||||
|
||||
* What dataset do you need as input? Is it available? Which of the existing bots produces the dataset you need as input?
|
||||
|
||||
* What products do you intend to build?
|
||||
|
||||
* What type of files will you be producing as outputs? Do you wish your indicator to be available in all timeperiods?
|
||||
|
||||
Let's get on with the task at hand...
|
||||
|
||||
Remember instructions will be given as if you were builing the SMA indicator. You should adapt this guide to fit your purpouse.
|
||||
|
||||
## Add Team and Indicator
|
||||
|
||||
Go to your workspace, select *Add Team* and edit its configuration with the following code:
|
||||
|
||||
```js
|
||||
{
|
||||
"codeName": "YourTeamName"
|
||||
}
|
||||
```
|
||||
In this case, the team's name is *Sparta*.
|
||||
|
||||
> **NOTE:** Needless to say, the code offered here is to be customized with the details corresponding to your own bot.
|
||||
|
||||
Within your team, select *Add Indicator Bot* and edit its configuration as follows:
|
||||
|
||||
```js
|
||||
{
|
||||
"codeName": "YourBotName",
|
||||
"repo": "YourBotName-Indicator-Bot"
|
||||
}
|
||||
```
|
||||
|
||||
## Multi-Period-Market Process Definition
|
||||
|
||||
Within the indicator, select *Add Process Definition*, label it as *Multi-Period-Market* and edit its configuration as follows:
|
||||
|
||||
```js
|
||||
{
|
||||
"codeName": "Multi-Period-Market",
|
||||
"description": "Describe what the process does.",
|
||||
"startMode": {
|
||||
"allMonths": {
|
||||
"run": "false",
|
||||
"minYear": "",
|
||||
"maxYear": ""
|
||||
},
|
||||
"oneMonth": {
|
||||
"run": "false",
|
||||
"year": "",
|
||||
"month": ""
|
||||
},
|
||||
"noTime": {
|
||||
"run": "true"
|
||||
},
|
||||
"fixedInterval": {
|
||||
"run": "false",
|
||||
"interval": 0
|
||||
}
|
||||
},
|
||||
"deadWaitTime": 0,
|
||||
"normalWaitTime": 0,
|
||||
"retryWaitTime": 10000,
|
||||
"sleepWaitTime": 3600000,
|
||||
"comaWaitTime": 86400000,
|
||||
"framework": {
|
||||
"name": "Multi-Period-Market",
|
||||
"startDate": {
|
||||
},
|
||||
"endDate": {
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Within the *Process Definition*, select *Add Missing Items*.
|
||||
|
||||
Go to the *Process Output* node recently added and select *Add Output Dataset*. The process will have one single output as the indicator has a single product.
|
||||
|
||||
Go to the *Process Dependencies* node and add two *Status Dependencies*.
|
||||
|
||||
Link the first *Status Dependecy* to the *Status Report* of the *Process Definition* to establish a reference, label it *Self*, and edit its code as follows:
|
||||
|
||||
```js
|
||||
{
|
||||
"mainUtility": "Self Reference"
|
||||
}
|
||||
```
|
||||
|
||||
> **NOTE:** It is good practice to use the label on top of nodes, in particular of those that are referencing other nodes, to describe precisely such relationships, as they may not be obvious when the node they link to is hidden. This makes references easier to track, and data becomes more usable in general.
|
||||
|
||||
Link the second *Status Dependency* to the *Status Report* of team Masters' Olivia's *Multi-Period-Market* *Process Definition*, label it as *Ending: Olivia*, and edit its code as follows:
|
||||
|
||||
```js
|
||||
{
|
||||
"mainUtility": "Market Ending Point"
|
||||
}
|
||||
```
|
||||
|
||||
Go back to the *Process Dependencies*, select *Add Data Dependency*, labelling the node as *Olivia Candles*. Link this dependency to Olivia's *Multi-Period-Market* *Dataset Definition* of the Candles *Product Definition*.
|
||||
|
||||
Go to the *Execution Started Event*, label it as *Olivia* and link it to Olivia's *Multi-Period-Market* *Process Definition* *Execution Finished Event*.
|
||||
|
||||
> **NOTE:** Notice how the label may be more or less descriptive depending on what node you are dealing with. For instance, we named the *Data Dependency* as *Olivia Candles*, because such a dependency may be linked to any of Olivia's products. However, we named the *Execution Started Event* simply *Olivia*, because such event will most likely be referencing the matching type of process (in this case *Multi-Period-Market*).
|
||||
|
||||
With this, the Multi-Period-Market process is defined.
|
||||
|
||||
## Multi-Period-Daily Process Definition
|
||||
|
||||
Let's proceed to define the Multi-Period-Daily process.
|
||||
|
||||
Within the indicator, select *Add Process Definition*, label it as *Multi-Period-Daily* and edit its configuration as follows:
|
||||
|
||||
```js
|
||||
{
|
||||
"codeName": "Multi-Period-Daily",
|
||||
"description": "Describe what the process does.",
|
||||
"startMode": {
|
||||
"allMonths": {
|
||||
"run": "false",
|
||||
"minYear": "",
|
||||
"maxYear": ""
|
||||
},
|
||||
"oneMonth": {
|
||||
"run": "false",
|
||||
"year": "",
|
||||
"month": ""
|
||||
},
|
||||
"noTime": {
|
||||
"run": "true"
|
||||
},
|
||||
"fixedInterval": {
|
||||
"run": "false",
|
||||
"interval": 0
|
||||
}
|
||||
},
|
||||
"deadWaitTime": 0,
|
||||
"normalWaitTime": 0,
|
||||
"retryWaitTime": 10000,
|
||||
"sleepWaitTime": 3600000,
|
||||
"comaWaitTime": 86400000,
|
||||
"framework": {
|
||||
"name": "Multi-Period-Daily",
|
||||
"startDate": {
|
||||
"takeItFromStatusDependency": 0
|
||||
},
|
||||
"endDate": {
|
||||
"takeItFromStatusDependency": 1
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Within the *Process Definition*, select *Add Missing Items*. Activate the *rotational symetry* option in each of the item's menu so that they get in order of precedence around the *Process Definition* node.
|
||||
|
||||
Go to the *Process Output* node recently added and select *Add Output Dataset*. The process will have one single output as the indicator has a single product.
|
||||
|
||||
Go to the *Process Dependencies* node and add three *Status Dependencies*.
|
||||
|
||||
Link the first *Status Dependecy* to the *Status Report* of the *Process Definition*, label it as *Self*, and edit its code as follows:
|
||||
|
||||
```js
|
||||
{
|
||||
"mainUtility": "Self Reference"
|
||||
}
|
||||
```
|
||||
|
||||
Link the second *Status Dependency* to the *Status Report* of team Masters' Olivia's *Multi-Period-Daily* *Process Definition*, label is as *Ending: Olivia*, and edit its code as follows:
|
||||
|
||||
```js
|
||||
{
|
||||
"mainUtility": "Market Ending Point"
|
||||
}
|
||||
```
|
||||
|
||||
Link the third *Status Dependency* to the *Status Report* of team Masters' Charly's *Historic-Trades* *Process Definition*, label it as *Starting: Charly Historic Trades*, and edit its code as follows:
|
||||
|
||||
```js
|
||||
{
|
||||
"mainUtility": "Market Starting Point"
|
||||
}
|
||||
```
|
||||
|
||||
Go back to the *Process Dependencies* and select *Add Data Dependency*, labelling it *Olivia Candles*. Link this dependency to Olivia's *Multi-Period-Daily* *Dataset Definition* of the Candles *Product Definition*.
|
||||
|
||||
Go to the *Execution Started Event*, label it *Olivia*, and link it to Olivia's *Multi-Period-Market* *Process Definition* *Execution Finished Event*.
|
||||
|
||||
That's it! *Multi-Period-Daily* *Process Definition* is done.
|
||||
|
||||
## Product Definition
|
||||
|
||||
Go back to the indicator's menu and select *Add Product Definition*, label it as *Popular SMAs* and edit its configuration as follows:
|
||||
|
||||
```js
|
||||
{
|
||||
"codeName": "Popular-SMAs",
|
||||
"singularVariableName": "popularSMA",
|
||||
"pluralVariableName": "popularSMAs"
|
||||
}
|
||||
```
|
||||
|
||||
Go to the *Product Definition* and select *Add Record Definition*, and continue to add 6 *Record Properties*.
|
||||
|
||||
| | |
|
||||
| :-------: | :--- |
|
||||
|  | **NOTE:** Make sure the resulting *Record Properties* have the *rotational symmetry* activated in the menu, as the order of these *Record Properties* determine the order of the fields in the resulting *record*. **TIP:** Activate the rotational symmetry on the *Record Definition* before creating the *Record Properties* so that they inherit the rotational symmetry upon creation. |
|
||||
|
||||
We will label each of the *Record Properties* and set their configurations as follows:
|
||||
|
||||
**Begin**
|
||||
```js
|
||||
{
|
||||
"codeName": "begin",
|
||||
"isString": false
|
||||
}
|
||||
```
|
||||
|
||||
**End**
|
||||
```js
|
||||
{
|
||||
"codeName": "end",
|
||||
"isString": false
|
||||
}
|
||||
```
|
||||
|
||||
**SMA20**
|
||||
```js
|
||||
{
|
||||
"codeName": "sma20",
|
||||
"isString": false
|
||||
}
|
||||
```
|
||||
|
||||
**SMA50**
|
||||
```js
|
||||
{
|
||||
"codeName": "sma50",
|
||||
"isString": false
|
||||
}
|
||||
```
|
||||
|
||||
**SMA100**
|
||||
```js
|
||||
{
|
||||
"codeName": "sma100",
|
||||
"isString": false
|
||||
}
|
||||
```
|
||||
|
||||
**SMA200**
|
||||
```js
|
||||
{
|
||||
"codeName": "sma200",
|
||||
"isString": false
|
||||
}
|
||||
```
|
||||
|
||||
Go to each of the *Record Properties* and add a formula. You will assign the corresponding variable to each of them: ```record.current.begin```, ```record.current.end```, ```variable.sma20```, ```variable.sma50```, ```variable.sma100```, ```variable.sma200```.
|
||||
|
||||
Go to the *Product Definition* and add two *Dataset Definitions*. Label the first one *Multi-Period-Market* and configure it as follows:
|
||||
|
||||
```js
|
||||
{
|
||||
"codeName": "Multi-Period-Market",
|
||||
"type": "Market Files",
|
||||
"validPeriods": [ "24-hs", "12-hs", "08-hs", "06-hs", "04-hs", "03-hs", "02-hs", "01-hs" ],
|
||||
"filePath": "Sparta/SMA.1.0/AACloud.1.1/@Exchange/dataSet.V1/Output/Popular-SMAs/Multi-Period-Market/@Period",
|
||||
"fileName": "@AssetA_@AssetB.json"
|
||||
}
|
||||
```
|
||||
|
||||
Name the second one *Multi-Period-Daily* and use the following configuration:
|
||||
|
||||
```js
|
||||
{
|
||||
"codeName": "Multi-Period-Daily",
|
||||
"type": "Daily Files",
|
||||
"validPeriods": [ "45-min", "40-min", "30-min", "20-min", "15-min", "10-min", "05-min", "04-min", "03-min", "02-min", "01-min" ],
|
||||
"filePath": "Sparta/SMA.1.0/AACloud.1.1/@Exchange/dataSet.V1/Output/Popular-SMAs/Multi-Period-Daily/@Period/@Year/@Month/@Day",
|
||||
"fileName": "@AssetA_@AssetB.json",
|
||||
"dataRange": {
|
||||
"filePath": "Sparta/SMA.1.0/AACloud.1.1/@Exchange/dataSet.V1/Output/Popular-SMAs/Multi-Period-Daily",
|
||||
"fileName": "Data.Range.@AssetA_@AssetB.json"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Go to the *Process Output* of each of the process (*Multi-Period-Market* and *Multi-Period-Daily*) and link each of the *Output Datasets* with the corresponding *Dataset Definitions*.
|
||||
|
||||
Go to the *Product Definition* and select *Add Missing Items*. You may delete the *Calculations Procedure* as we will not need it for this product.
|
||||
|
||||
Go to the *Data Building Procedure*, add a *Procedure Initialization* and a *Procedure Loop* nodes.
|
||||
|
||||
Go to the *Procedure Initialization* node and use the following code:
|
||||
|
||||
```JS
|
||||
/*
|
||||
In Multi-Period-Daily we only have access to the last 2 days's worth of
|
||||
candles, which in 45 min for example, results in 36 candles from the
|
||||
current day and 36 from the previous one.
|
||||
|
||||
Because we will not have access to a long enough history while processing
|
||||
daily files, we will use an array to store the last 200 candle.close
|
||||
values. This is to overecome that limitation.
|
||||
*/
|
||||
|
||||
variable.last200 = []
|
||||
|
||||
//Debug code:
|
||||
//console.log(timePeriodLabel + " - Initialization of SMA - *************")
|
||||
|
||||
```
|
||||
|
||||
Go to the *Procedure Loop* and use the following code:
|
||||
|
||||
```js
|
||||
|
||||
let candle = record.current // Our main dependencies are candles
|
||||
variable.last200.push(candle.close) // Add the current close value to the last 200 array.
|
||||
|
||||
if (variable.last200.length > 200) {
|
||||
variable.last200.splice(0, 1) // Remove the first node of the array to keep it at a maximun of 200 nodes.
|
||||
}
|
||||
|
||||
variable.sma20 = calculateSMA(20)
|
||||
variable.sma50 = calculateSMA(50)
|
||||
variable.sma100 = calculateSMA(100)
|
||||
variable.sma200 = calculateSMA(200)
|
||||
|
||||
function calculateSMA(periods) { // Having a function avoids us to repeat code.
|
||||
/* We check we have enough values to make the calculation */
|
||||
if (variable.last200.length < periods) { return 0 } // If we dont, we define the value is zero.
|
||||
|
||||
let sum = 0 // Initialize sum variable.
|
||||
for (let i = variable.last200.length - periods; i < variable.last200.length; i++) { // Iterate through the last periods
|
||||
sum = sum + variable.last200[i]
|
||||
/*
|
||||
if (index > 18 && index < 22) { // You can debug what is going on by console logging whatever you need.
|
||||
console.log("index=" + index + " i=" + i + " variable.last200.length=" + variable.last200.length + " periods=" + periods + " sum=" + sum + " sum/periods=" + (sum / periods) + " currentValue=" + (variable.last200[i]))
|
||||
}
|
||||
*/
|
||||
}
|
||||
let sma = sum / periods
|
||||
return sma
|
||||
}
|
||||
```
|
||||
|
||||
We are done setting up the *Product Definition*. Now it's time to get the processes up and running!
|
||||
|
||||
## Network Setup
|
||||
|
||||
Go to the *My Computer* network node and create a new *task manager*. Create a new task, and select *Add New Indicator Bot Instance* and use the following configuration:
|
||||
|
||||
```js
|
||||
{
|
||||
"team": "YourTeamName",
|
||||
"bot": "YourBotName",
|
||||
"repo": "YourBotName-Indicator-Bot"
|
||||
}
|
||||
```
|
||||
|
||||
Select *Add a Process Instance*, name it *Market* and use the following configuration:
|
||||
|
||||
```js
|
||||
{
|
||||
"process": "Multi-Period-Market"
|
||||
}
|
||||
```
|
||||
|
||||
Go ahead and add a second *Process Instance*, name it *Daily* and use the following configuration:
|
||||
|
||||
```js
|
||||
{
|
||||
"process": "Multi-Period-Market"
|
||||
}
|
||||
```
|
||||
|
||||
Link each of the *Process Instances* to the corresponding *Process Definition* (*Multi-Period-Market* and *Multi-Period-Daily*)
|
||||
|
||||
That's it! You are now ready to run the *Indicator Bot Instance*.
|
||||
|
||||
> **NOTE:** Remember that the bot has dependencies that need to be running for it to start. Click *Run All Tasks* in the *Masters Datasets* task manager.
|
||||
|
||||
If everything works well, the bot should start logging the typical progress messages in the console, create the folders structure as specified before and start pilling files for each of the time periods.
|
||||
|
||||
## Debugging
|
||||
|
||||
In case something is not working properly, the console is the first place to look into. The platform will log handled errors just like it does with the rest of the components in the system.
|
||||
|
||||
You may also implement additional logging features in the code you use on the *Data Building Procedure*. Notice that the code used for this bot has such kind of code embeded, but commented.
|
||||
|
||||
@@ -0,0 +1,419 @@
|
||||
---
|
||||
title: Charting System Hierarchy
|
||||
summary: "Hover your mouse over a node for a quick definition, and click for the details."
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-charting-system-hierarchy.html
|
||||
toc: false
|
||||
---
|
||||
|
||||
|
||||
<table class='hierarchyTable'>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>
|
||||
<a href='#charting-system' data-toggle='tooltip' data-original-title='{{site.data.charting_system.charting_system}}'><img src='images/icons/charting-system.png' /><br />Charting System</a>
|
||||
</th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-fork.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#viewport' data-toggle='tooltip' data-original-title='{{site.data.charting_system.viewport}}'><img src='images/icons/viewport.png' /><br />Viewport</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-elbow.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#time-machine' data-toggle='tooltip' data-original-title='{{site.data.charting_system.time_machine}}'><img src='images/icons/time-machine.png' /><br />Time Machine</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-fork.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#time-scale' data-toggle='tooltip' data-original-title='{{site.data.charting_system.time_scale}}'><img src='images/icons/time-scale.png' /><br />Time Scale</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-fork.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#rate-scale' data-toggle='tooltip' data-original-title='{{site.data.charting_system.rate_scale}}'><img src='images/icons/rate-scale.png' /><br />Rate Scale</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-fork.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#time-frame-scale' data-toggle='tooltip' data-original-title='{{site.data.charting_system.time_frame_scale}}'><img src='images/icons/time-frame-scale.png' /><br />Time Frame Scale</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-elbow.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#timeline-chart' data-toggle='tooltip' data-original-title='{{site.data.charting_system.timeline_chart}}'><img src='images/icons/timeline-chart.png' /><br />Timeline Chart</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-fork.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#rate-scale' data-toggle='tooltip' data-original-title='{{site.data.charting_system.rate_scale}}'><img src='images/icons/rate-scale.png' /><br />Rate Scale</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-fork.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#time-frame-scale' data-toggle='tooltip' data-original-title='{{site.data.charting_system.time_frame_scale}}'><img src='images/icons/time-frame-scale.png' /><br />Time Frame Scale</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-elbow.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#layers-manager' data-toggle='tooltip' data-original-title='{{site.data.charting_system.layers_manager}}'><img src='images/icons/layers-manager.png' /><br />Layers Manager</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-elbow.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#layer' data-toggle='tooltip' data-original-title='{{site.data.charting_system.layer}}'><img src='images/icons/layer.png' /><br />Layer</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Charting System
|
||||
|
||||
<img src='images/icons/150-charting-system.png' />
|
||||
|
||||
**{{site.data.charting_system.charting_system}}**
|
||||
|
||||
There is only one charting system hierarchy, thus all charts are configured here. As is common throughout the system, different concepts and elements of the charts such as the scales, data layers and so on, are represented by nodes in the hierarchy. The system allows great flexibility on how to visualize information over the charts by adding, configuring, and arranging these nodes.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Viewport
|
||||
|
||||
<img src='images/icons/150-viewport.png' />
|
||||
|
||||
**{{site.data.charting_system.viewport}}**
|
||||
|
||||
At this point, the system supports one viewport only. When you navigate through the charts, panning, zooming or moving elements around, what you are doing is panning and zooming on the viewport. That is, you are not moving the charts, but the space that contains them.
|
||||
|
||||
Think of the viewport as a huge drawing board. You can have lots of information plotted on different parts of the board, so you move the viewport around and zoom in to focus on specific bits of information.
|
||||
|
||||
When you zoom out, you are bringing more information in focus. Because information is handled dynamically, reading data from files, interpretting it, and drawing the corresponding visual elements on the screen in real-time, zooming out or—in general—bringing lots of information in focus may slow your system down. The information that is out of focus, that is, out of the visible screen, is not processed.
|
||||
|
||||
The concept of the viewport allows having multiple charts configured all at once, so that you may consult different exchanges, different markets, or different technical studies on demand, simply by moving around and zooming in or out on the viewport. You may put any of those elements side by side, or even superimpose them to study market flows, search for arbitrage opportunities, or simply keep them in sight when you analyze particular market situations.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Time Machine
|
||||
|
||||
<img src='images/icons/150-time-machine.png' />
|
||||
|
||||
**{{site.data.charting_system.time_machine}}**
|
||||
|
||||
Think of a time machine as an aide that helps you keep any number of pieces of information syncronized on the same time scale. Every data structure that you set up within the same time machine, will always be syncronized in relation to time. Put in other words, the open and closing datetime of each dataset will always be aligned on the vertical axis.
|
||||
|
||||
On the other hand, when you arrange charts on different time machines, they are completely independent from one another.
|
||||
|
||||
### Adding a Time Machine
|
||||
|
||||
To add a time machine, select *Add Time Machine* on the charting system node menu.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Time Scale
|
||||
|
||||
<img src='images/icons/150-time-scale.png' />
|
||||
|
||||
**{{site.data.charting_system.time_scale}}**
|
||||
|
||||
### Adding a Time Scale
|
||||
|
||||
To add a time scale, select *Add Time Scale* on the time machine node menu.
|
||||
|
||||
### Scale Value
|
||||
|
||||
The time scale is represented by a numerical value between 0 and 100. When the scale is set to zero, the horizontal span of the time machine and charts within it is the smallest possible. When the scale is set to 100, it is the largest possible. In other words, the charts are compressed on the horizontal axis with low scale numbers and expanded as the scale increases.
|
||||
|
||||
### Setting a Time Scale
|
||||
|
||||
You may set a scale value from within the charts by placing the mouse pointer over the corresponding time machine datetime box and scrolling the mouse wheel.
|
||||
|
||||
{% include tip.html content="Pressing the mouse wheel while scrolling accelerates de process." %}
|
||||
|
||||
[IMAGE]
|
||||
|
||||
You may also set a scale value from within the designer by selecting *Configure Time Scale* on the time scale node menu and editing the corresponding configuration.
|
||||
|
||||
```json
|
||||
{"scale":"0"}
|
||||
```
|
||||
|
||||
{% include note.html content="The values entered via the designer and the charts are syncronized and stored in the node." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Rate Scale
|
||||
|
||||
<img src='images/icons/150-rate-scale.png' />
|
||||
|
||||
**{{site.data.charting_system.rate_scale}}**
|
||||
|
||||
Rate scales may exist both at the level of a time machine and at the level of a timeline chart, each affecting the corresponding concept.
|
||||
|
||||
When set at the level of the time machine, the scale setting affects all charts within the time machine. When set at the level of the timeline chart, the setting overrides the rate scale at the time machine level. This allows having multiple charts in the same time machine, each with a different rate scales.
|
||||
|
||||
### Adding a Rate Scale
|
||||
|
||||
To add a rate scale, select *Add Rate Scale* on the time machine or the timeline chart node menu.
|
||||
|
||||
### Rate Scale Value
|
||||
|
||||
The rate scale is represented by a numerical value between 0 and 100. When the scale is set to zero, the vertical span of the time machine or the timeline chart is the smallest possible. When the scale is set to 100, it is the largest possible. In other words, the charts are compressed on the vertical axis with low scale numbers and expanded as the scale increases.
|
||||
|
||||
### Rate Scale Minimum and Maximum
|
||||
|
||||
The rate scale remains the same at all times, unless you change it. This means that&mdashunlike in other platforms—the rate scale does not adjust dynamically depending on the information on the screen. This is a design choice so that rates may be easily comparable along the datetime span of the market.
|
||||
|
||||
### Offset Value
|
||||
|
||||
The offset is a property of the rate scale by which the scale may be shifted upwards or downwards. As a result, charts aligned in the vertical axis—syncronized in datetime by a shared time machinemdash;may be put one above the other. The offset value is a numerical value which may be positive or negative, with no specific minimum or maximum.
|
||||
|
||||
### Setting Rate Scale and Offset Values
|
||||
|
||||
You may set a scale value from within the charts by placing the mouse pointer over the corresponding time machine or timeline chart rate box and scrolling the mouse wheel. Add the <kbd>Shift</kbd> key to affect the offset.
|
||||
|
||||
{% include tip.html content="Pressing the mouse wheel while scrolling accelerates de process." %}
|
||||
|
||||
[IMAGE]
|
||||
|
||||
You may also set a scale setting, minimum and maximum values for the scale, and offset value from within the designer by selecting *Configure Rate Scale* on the rate scale node menu and editing the configuration.
|
||||
|
||||
```json
|
||||
{"scale":"50","offset":0,"minValue":0,"maxValue":25000}
|
||||
```
|
||||
|
||||
* The ```minValue``` sets the value for the orgin of the y axis, that is, the rate scale. Usually, this value would be zero, but it doesn't need to be zero, as it is configurable.
|
||||
|
||||
* The ```maxValue``` may be set to any positive number.
|
||||
|
||||
{% include note.html content="The values entered via the designer and the charts are syncronized and stored in the node." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Time Frame Scale
|
||||
|
||||
<img src='images/icons/150-time-frame-scale.png' />
|
||||
|
||||
**{{site.data.charting_system.time_frame_scale}}**
|
||||
|
||||
When the time frame scale is set at the level of the time machine, the scale setting affects all charts within the time machine. When set at the level of the timeline chart, the setting overrides the time frame scale at the time machine level. This allows comparing charts in different time frames, but still syncronized at the datetime level.
|
||||
|
||||
### Adding a Time Frame Scale
|
||||
|
||||
To add a time frame scale, select *Add Time Frame Scale* on the time machine or the timeline chart node menu.
|
||||
|
||||
### Time Frame Scale Value
|
||||
|
||||
The time frame scale value can be any of the time frames supported by the system:
|
||||
|
||||
* 1, 2, 3, 4, 5, 10, 15, 20, 30, 40, and 45 minutes
|
||||
|
||||
* 1, 2, 3, 4, 6, 8, 12, and 24 hours.
|
||||
|
||||
### Setting a Time Frame
|
||||
|
||||
You may set a time frame value from within the charts by placing the mouse pointer over the corresponding time machine or timeline chart time frame box and scrolling the mouse wheel.
|
||||
|
||||
[IMAGE]
|
||||
|
||||
You may also set a time frame from within the designer by selecting *Configure Rate Scale* on the rate scale node menu and editing the configuration.
|
||||
|
||||
```json
|
||||
{"value":"06-hs"}
|
||||
```
|
||||
|
||||
{% include note.html content="The values entered via the designer and the charts are syncronized and stored in the node." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Timeline Chart
|
||||
|
||||
<img src='images/icons/150-timeline-chart.png' />
|
||||
|
||||
**{{site.data.charting_system.timeline_chart}}**
|
||||
|
||||
In other words, a timeline chart is a set of information to be displayed over a timeline. The information may include candles—the main and foremost resource—as well as any other indicator, study or—in general—data product that may be available.
|
||||
|
||||
You may add as many charts as you wish. Charts within the same time machine are syncronized in the y axis, that is, at the datetime level. Charts in different time machines are independent from each other in relation to the datetime. In either case, you may also add rate scales and time frame scales at the timeline charts level.
|
||||
|
||||
The information that each timeline chart makes available on the screen is given by the layers set up in the corresponding layers manager.
|
||||
|
||||
### Adding a Timeline Chart
|
||||
|
||||
To add a timeline chart, select *Add Timeline Chart* on the preferred time machine node menu.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Layers Manager
|
||||
|
||||
<img src='images/icons/150-layers-manager.png' />
|
||||
|
||||
**{{site.data.charting_system.layers_manager}}**
|
||||
|
||||
In other words, you use the layers manager node to configure which data products you wish to be made available for visualization purposes on the charts, in particular, on a specific timeline chart to which the layers manager node is attached to.
|
||||
|
||||
### Adding a Layers Manager
|
||||
|
||||
To add a layers manager, select *Add Layers Manager* on the preferred timeline chart node menu.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Layer
|
||||
|
||||
<img src='images/icons/150-layer.png' />
|
||||
|
||||
**{{site.data.charting_system.layer}}**
|
||||
|
||||
### Adding Layers
|
||||
|
||||
To add a layer, select *Add Layer* on the layer manager node menu.
|
||||
|
||||
### Setting Up Layers
|
||||
|
||||
To set up a layer, you need to establish a <a href="suite-references.html" data-toggle="tooltip" data-original-title="{{site.data.concepts.reference}}">reference</a> with the <a href="suite-network-hierarchy.html#data-product" data-toggle="tooltip" data-original-title="{{site.data.network.data_product}}">data product</a> of your choice.
|
||||
|
||||
### Configuring Layers
|
||||
|
||||
Select *Configure Layer* on the menu to access the configuration.
|
||||
|
||||
```json
|
||||
{"status":"on", "showPanels":true}
|
||||
```
|
||||
|
||||
* ```status``` may be *on* or *off* and refers to the layer being visible or not on the charts.
|
||||
|
||||
* ```showPanels``` may be *true* or *false*; *true* shows the plotter panel that may be associated with the data product as per the plotter module definitions; *false* makes panels invisible.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: Charts Interface
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-charts-interface.html
|
||||
---
|
||||
|
||||
## Main Nodes
|
||||
|
||||
Notice the following three nodes relative to the position of the mouse pointer:
|
||||
|
||||
**1.** Above, the current datetime. This is the date and time at the mouse pointer position.
|
||||
|
||||
**2.** To the right, the current rate. This is the rate (in this case USDT per BTC) at the mouse pointer position.
|
||||
|
||||
**3.** Below, the current time period (time frame or candle size if you wish). This is the currently displayed time period—not only for candles but for any other object plotted across available layers.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67268983-141a3d80-f4b6-11e9-96cc-c0dc3d9188f7.gif)
|
||||
|
||||
## Mouse Navigation
|
||||
|
||||
Left-click on the charts and drag to move across the charts.
|
||||
|
||||
There are many things you can do with your mouse wheel:
|
||||
|
||||
1. Scroll over the Layers Panel to access layers that may be out of reach downwards.
|
||||
1. Scroll on top of or next to the datetime to produce a horizontal scaling.
|
||||
1. Scroll on top of or next to the displayed rate to produce a vertical scaling.
|
||||
1. Scroll on top of or next to the time period to change the time period to available values.
|
||||
1. Scroll elsewhere over the chart to zoom in and out. The Platform will not only zoom in and out of the chart, but also automatically adjust the time period to the most convenient one (for the current zoom level).
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67268341-7a9e5c00-f4b4-11e9-848d-c520b4a8f1ff.gif)
|
||||
|
||||
## Keyboard Navigation
|
||||
|
||||
When on the charts, you may use the following key combinations:
|
||||
|
||||
1. <kbd>Shift</kbd> + <kbd>←</kbd> to pan to the left.
|
||||
1. <kbd>Shift</kbd> + <kbd>→</kbd> to pan to the right.
|
||||
1. <kbd>Shift</kbd> + <kbd>↑</kbd> to pan upwards.
|
||||
1. <kbd>Shift</kbd> + <kbd>↓</kbd> to pan downwards.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67268342-7b36f280-f4b4-11e9-956d-109c65fdd5ba.gif)
|
||||
|
||||
## Layers Panel
|
||||
|
||||
This panel includes different layers you may visualize by toggling them on and off with a single mouse click.
|
||||
The layer title bar can have 3 possible background colors:
|
||||
|
||||
**1. Red**: the layer is off.
|
||||
|
||||
**2. Green**: the layer is on.
|
||||
|
||||
**3. Yellow**: the layer is loading; if it stays yellow, it means it can't load fully.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67267950-a836d580-f4b3-11e9-931b-81c8dff088ac.gif)
|
||||
|
||||
## Floating Panels
|
||||
|
||||
To minimize a panel, click on the small triangle on the right of its title bar. This will automatically position the panel at the bottom of the screen. Clicking again restores the panel to its previous position.
|
||||
|
||||
You may also drag and drop the panels by right-clicking on the title bar.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67281843-a0d1f500-f4d0-11e9-85ad-9843219953b4.gif)
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: Charts Overview
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-charts-overview.html
|
||||
---
|
||||
|
||||
Conceptually, the Superalgos Platform places the focus on the visual experience. Not just because it's *nice* to see data in graphical representations, but because humans excel when our senses take part in the analysis. Human's capacity to think abstractly may be more or less developed across individuals, but one thing is clear: our thought process benefits from being able to see.
|
||||
|
||||
The Charts offer a visual environment in which you will be able to see, analyze and go over every piece of data involved in the process of trading cryptocurrencies:
|
||||
|
||||
* Live and historic market data;
|
||||
* Data crunched in the form of indicators;
|
||||
* The specific effects of the rules you will program into your strategies, and how strategies behave during testing and live trading sessions.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67267949-a79e3f00-f4b3-11e9-9c0b-0c4aecf2d37d.gif)
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: Clones
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-clones.html
|
||||
---
|
||||
|
||||
> **NOTE:** To understand clones, you first need to be familiar with [*references*](References).
|
||||
|
||||
## Introduction
|
||||
|
||||
We will analyze the case of clones under the same lens we analyzed how backups work: we will study how clones treat outgoing, incoming and internal references.
|
||||
|
||||
Unlike with backups, clones behave in the same way independently of the existence of the original structure of nodes in the workspace, therefore, we will not make such distinction in the following paragraphs.
|
||||
|
||||
## Outgoing References
|
||||
|
||||
**Outgoing references are kept intact.**
|
||||
|
||||
Pretty much like with backups, a clone preserves outgoing references.
|
||||
|
||||
The same example as with backups apply: cloning a task running a session produces a copy of the task with the trading bot process instance maintaining the reference to the trading bot Multi-Period process, and the session maintaining the reference with the corresponding definition.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71164672-d7698900-224f-11ea-9985-eee1a448a4de.gif)
|
||||
|
||||
## Incoming References
|
||||
|
||||
**Incoming references are discarded.**
|
||||
|
||||
Let's go back to the example of a definition, like we did when exploring backups:
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71164674-d8021f80-224f-11ea-8365-56c455b89f55.gif)
|
||||
|
||||
The capture above shows that restoring a clone of a definition does not restore incoming references, even when the original structure of nodes is deleted before restoration.
|
||||
|
||||
## Internal References
|
||||
|
||||
**Internal references are kept intact.**
|
||||
|
||||
Going back to the *shapes* node example, the capture below shows how restonring a clone keeps internal references intact:
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71164677-d8021f80-224f-11ea-8707-5cde89de259c.gif)
|
||||
|
||||
## Conclusion
|
||||
|
||||
The clone feature is designed to produce copies of data structures when you need to replicate nodes and expect the copies to behave similarly to the original.
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Consulting Logs
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-consulting-logs.html
|
||||
---
|
||||
|
||||
If you are a technical person, you may be interested in consuting the logs of the different bots that run in the platform.
|
||||
|
||||
Each bot keeps its own set of execution log files, stored under a similar folder structure as bot's Output and Reports. The difference is that the Log-Files folder is at the root level of the release folder, instead of being inside Data-Storage:
|
||||
|
||||
```
|
||||
\Log-Files\AAMasters\AAMasters
|
||||
```
|
||||
Log files contain detailed information about each execution of the bot. As such, a new folder is created for each execution, labeled with the exact DateTime.
|
||||
|
||||
Each folder may contain more than one file. Lighter files tend to include data about the initialization stage, while heavier files usually feature the data corresponding to the actual work the bot does.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/63350228-4f38ad00-c35d-11e9-8074-bdd73ac68bd8.gif)
|
||||
@@ -0,0 +1,523 @@
|
||||
---
|
||||
title: Crypto Ecosystem Hierarchy
|
||||
summary: "Hover your mouse over a node for a quick definition, and click for the details."
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-crypto-ecosystem-hierarchy.html
|
||||
toc: false
|
||||
---
|
||||
|
||||
<table class='hierarchyTable'>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>
|
||||
<a href='#crypto-ecosystem' data-toggle='tooltip' data-original-title='{{site.data.crypto_ecosystem.crypto_ecosystem}}'><img src='images/icons/crypto-ecosystem.png' /><br />Crypto Ecosystem</a>
|
||||
</th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-elbow.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#crypto-exchanges' data-toggle='tooltip' data-original-title='{{site.data.crypto_ecosystem.crypto_exchanges}}'><img src='images/icons/crypto-exchanges.png' /><br />Crypto Exchanges</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-elbow.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#crypto-exchange' data-toggle='tooltip' data-original-title='{{site.data.crypto_ecosystem.crypto_exchange}}'><img src='images/icons/crypto-exchange.png' /><br />Crypto Exchange</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-fork.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#exchange-assets' data-toggle='tooltip' data-original-title='{{site.data.crypto_ecosystem.exchange_assets}}'><img src='images/icons/exchange-assets.png' /><br />Exchange Assets</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-line.png' />
|
||||
</td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-elbow.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#asset' data-toggle='tooltip' data-original-title='{{site.data.crypto_ecosystem.asset}}'><img src='images/icons/asset.png' /><br />Asset</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-fork.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#exchange-markets' data-toggle='tooltip' data-original-title='{{site.data.crypto_ecosystem.exchange_markets}}'><img src='images/icons/exchange-markets.png' /><br />Exchange Markets</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-line.png' />
|
||||
</td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-elbow.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#market' data-toggle='tooltip' data-original-title='{{site.data.crypto_ecosystem.market}}'><img src='images/icons/market.png' /><br />Market</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-line.png' />
|
||||
</td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-fork.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#market-base-asset' data-toggle='tooltip' data-original-title='{{site.data.crypto_ecosystem.market_base_asset}}'><img src='images/icons/market-base-asset.png' /><br />Market Base Asset</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-line.png' />
|
||||
</td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-elbow.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#market-quoted-asset' data-toggle='tooltip' data-original-title='{{site.data.crypto_ecosystem.market_quoted_asset}}'><img src='images/icons/market-quoted-asset.png' /><br />Market Quoted Asset</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-elbow.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#exchange-accounts' data-toggle='tooltip' data-original-title='{{site.data.crypto_ecosystem.exchange_accounts}}'><img src='images/icons/exchange-accounts.png' /><br />Exchange Accounts</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-elbow.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#user-account' data-toggle='tooltip' data-original-title='{{site.data.crypto_ecosystem.user_account}}'><img src='images/icons/user-account.png' /><br />User Account</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-fork.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#user-keys' data-toggle='tooltip' data-original-title='{{site.data.crypto_ecosystem.user_keys}}'><img src='images/icons/user-keys.png' /><br />User Keys</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-line.png' />
|
||||
</td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-elbow.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#exchange-account-key' data-toggle='tooltip' data-original-title='{{site.data.crypto_ecosystem.exchange_account_key}}'><img src='images/icons/exchange-account-key.png' /><br />Exchange Account Key</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-elbow.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#user-assets' data-toggle='tooltip' data-original-title='{{site.data.crypto_ecosystem.user_assets}}'><img src='images/icons/user-assets.png' /><br />User Assets</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>
|
||||
<img src='images/icons/tree-connector-elbow.png' />
|
||||
</td>
|
||||
<td>
|
||||
<a href='#exchange-account-asset' data-toggle='tooltip' data-original-title='{{site.data.crypto_ecosystem.exchange_account_asset}}'><img src='images/icons/exchange-account-asset.png' /><br />Exchange Account Asset</a>
|
||||
</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Crypto Ecosystem
|
||||
|
||||
<img src='images/icons/150-crypto-ecosystem.png' />
|
||||
|
||||
**{{site.data.crypto_ecosystem.crypto_ecosystem}}**
|
||||
|
||||
The crypto ecosystem is a hierarchy that contains definitions regarding information obtained from third-parties, including exchanges and their markets, as well as accounts of users with those third parties.
|
||||
|
||||
There is only one crypto ecosystem hierarchy. You will use it to define which exchanges and which markets you wish to work with, as well as the details of your accounts with those exchanges.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Crypto Exchanges
|
||||
|
||||
<img src='images/icons/150-crypto-exchanges.png' />
|
||||
|
||||
**{{site.data.crypto_ecosystem.crypto_exchanges}}**
|
||||
|
||||
### Adding a Crypto Exchanges Node
|
||||
|
||||
To add a crypto exchanges node, select *Add Crypto Exchanges* on the crypto ecosystem node menu.
|
||||
|
||||
{% include note.html content="Only one crypto exchanges node may exist on the hierarchy." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Crypto Exchange
|
||||
|
||||
<img src='images/icons/150-crypto-exchange.png' />
|
||||
|
||||
**{{site.data.crypto_ecosystem.crypto_exchange}}**
|
||||
|
||||
### Adding a Crypto Exchange
|
||||
|
||||
To add a crypto exchange, select *Add Crypto Exchange* on the crypto exchanges node menu. The crypto exchange node is created along with the rest of the basic structure of nodes required to define assets, markets and user accounts.
|
||||
|
||||
### Configuring a Crypto Exchange
|
||||
|
||||
Select *Configure Crypto Exchange* on the menu to access the configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"codeName": "Poloniex"
|
||||
}
|
||||
```
|
||||
|
||||
* codeName is the name of the exchange as handled in the code of the system.
|
||||
|
||||
{% include note.html content="Consult the list of supported exchanges for the list of possible values for the ```codeName``` field. When a supported exchange is successfully configured, the standard crypto exchange icon is replaced with the logotype of the corresponding exchange." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Exchange Assets
|
||||
|
||||
<img src='images/icons/150-exchange-assets.png' />
|
||||
|
||||
**{{site.data.crypto_ecosystem.exchange_assets}}**
|
||||
|
||||
### Adding an Exchange Assets Node
|
||||
|
||||
To add an exchange assets node, select *Add Exchange Assets* on the crypto exchanges node menu. The exchange assets node is created along with a first asset.
|
||||
|
||||
{% include note.html content="Only one exchange assets node may exist on each exchange." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Asset
|
||||
|
||||
<img src='images/icons/150-asset.png' />
|
||||
|
||||
**{{site.data.crypto_ecosystem.asset}}**
|
||||
|
||||
### Adding an Asset
|
||||
|
||||
To add an asset, select *Add Asset* on the crypto exchange assets node menu.
|
||||
|
||||
### Configuring an Asset
|
||||
|
||||
Select *Configure Asset* on the menu to access the configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"codeName": "BTC"
|
||||
}
|
||||
```
|
||||
|
||||
* codeName is the ticker of the asset as listed by the exchange (*i.e.:* BTC, BTH, ETH, LTC, BNB, USDT, USD, etc.)
|
||||
|
||||
{% include note.html content="Consult the list of supported assets for the list of possible values for the ```codeName``` field. When a configured asset is within the system's icon catalog, the standard asset icon is replaced with the logotype of the corresponding asset." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Exchange Markets
|
||||
|
||||
<img src='images/icons/150-exchange-markets.png' />
|
||||
|
||||
**{{site.data.crypto_ecosystem.exchange_markets}}**
|
||||
|
||||
### Adding an Exchange Markets Node
|
||||
|
||||
To add an exchange markets node, select *Add Exchange Markets* on the crypto exchange node menu. The exchange markets node is created along with the basic structure of nodes to define the first market.
|
||||
|
||||
{% include note.html content="Only one exchange assets node may exist on each exchange." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Market
|
||||
|
||||
<img src='images/icons/150-market.png' />
|
||||
|
||||
**{{site.data.crypto_ecosystem.market}}**
|
||||
|
||||
{% include important.html content="Only markets that are effectively listed on the exchange may be configured and used with the system. Check with the exchange and make sure you understand what tickers they are using, which is the base asset and which the quoted asset on the listed markets." %}
|
||||
|
||||
### Adding a Market
|
||||
|
||||
To add a market, select *Add Market* on the crypto exchange node menu. The market node is created along with the basic structure of nodes used to define the market.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Market Base Asset
|
||||
|
||||
<img src='images/icons/150-market-base-asset.png' />
|
||||
|
||||
**{{site.data.crypto_ecosystem.market_base_asset}}**
|
||||
|
||||
A market base asset must reference an asset defined under the exchange assets node.
|
||||
|
||||
### Adding a Market Base Asset
|
||||
|
||||
To add a market base asset, select *Add Market Base Asset* on the market node menu.
|
||||
|
||||
{% include note.html content="Remember to establish a reference with an asset defined under the exchange assets node." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Market Quoted Asset
|
||||
|
||||
<img src='images/icons/150-market-quoted-asset.png' />
|
||||
|
||||
**{{site.data.crypto_ecosystem.market_quoted_asset}}**
|
||||
|
||||
A market quoted asset must reference an asset defined under the exchange assets node.
|
||||
|
||||
### Adding a Market Quoted Asset
|
||||
|
||||
To add a market quoted asset, select *Add Market Quoted Asset* on the market node menu.
|
||||
|
||||
{% include note.html content="Remember to establish a reference with an asset defined under the exchange assets node." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Exchange Accounts
|
||||
|
||||
<img src='images/icons/150-exchange-accounts.png' />
|
||||
|
||||
**{{site.data.crypto_ecosystem.exchange_accounts}}**
|
||||
|
||||
### Adding an Exchange Accounts Node
|
||||
|
||||
To add an exchange accounts node, select *Add Exchange Account* on the crypto exchange node menu. The exchange account node is created along with the basic structure of nodes used to define keys and user assets with the exchange.
|
||||
|
||||
{% include note.html content="Only one exchange accounts node may exist on each exchange." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## User Account
|
||||
|
||||
<img src='images/icons/150-user-account.png' />
|
||||
|
||||
**{{site.data.crypto_ecosystem.user_account}}**
|
||||
|
||||
### Adding a User Account
|
||||
|
||||
To add user account, select *Add User Account* on the exchange accounts node menu. The user account node is created along with the basic structure of nodes used to define keys and user assets with the exchange.
|
||||
|
||||
{% include tip.html content="You may add and administer as many user accounts as you wish." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## User Keys
|
||||
|
||||
<img src='images/icons/150-user-keys.png' />
|
||||
|
||||
**{{site.data.crypto_ecosystem.user_keys}}**
|
||||
|
||||
### Adding a User Keys Node
|
||||
|
||||
To add user keys node, select *Add User Keys* on the user account node menu. The user keys node is created along with the first exchange account key.
|
||||
|
||||
{% include note.html content="Only one user keys node may exist under a user account." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Exchange Account Key
|
||||
|
||||
<img src='images/icons/150-exchange-account-key.png' />
|
||||
|
||||
**{{site.data.crypto_ecosystem.exchange_account_key}}**
|
||||
|
||||
### Adding an Exchange Account Key
|
||||
|
||||
To add an exchange account key, select *Add Key* on the user keys node menu.
|
||||
|
||||
### Configuring an Exchange Account Key
|
||||
|
||||
Select *Configure Key* on the menu to access the configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"codeName": "Paste your exchange API name or label here",
|
||||
"secret": "Paste your exchange API secret key here."
|
||||
}
|
||||
```
|
||||
|
||||
* ```codeName``` is the name or label of your key, as supplied by the exchange.
|
||||
|
||||
* ```secret``` is the *secret key* as supplied by the exchange.
|
||||
|
||||
{% include warning.html content="To keep your exchange keys safe, never share data structures you may download from the system, as downloads contain all information in the data structure, including personal information such as exchange keys. Use the share option on the menu instead. The share option strips sensitive information and outputs a file that is safe for sharing." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## User Assets
|
||||
|
||||
<img src='images/icons/150-user-assets.png' />
|
||||
|
||||
**{{site.data.crypto_ecosystem.user_assets}}**
|
||||
|
||||
### Adding a User Assets Node
|
||||
|
||||
To add user assets node, select *Add User Assets* on the user account node menu. The user assets node is created along with the first exchange account asset.
|
||||
|
||||
{% include note.html content="Only one user assets node may exist under a user account." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Exchange Account Asset
|
||||
|
||||
<img src='images/icons/150-exchange-account-asset.png' />
|
||||
|
||||
**{{site.data.crypto_ecosystem.exchange_account_asset}}**
|
||||
|
||||
File diff suppressed because it is too large.
Load diff
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: Overview
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-data-mining-overview.html
|
||||
---
|
||||
|
||||
The Superalgos Platform puts a powerful data processing system in your hands. Use it to the fullest and you will see your *intelligence* increasing by orders of magnitude.
|
||||
|
||||
Anyone may access raw trades and order book data from exchanges. Anyone may access information in the form of standard indicators and technical studies.
|
||||
|
||||
However, only this platform allows you to perform custom calculations and any sort of processing over existing information, and store it into new datasets that you can later access from within your strategies.
|
||||
|
||||
The platform's data processing functionality is highly flexible and works under the same paradigm you are already familiar with while building strategies. It provides you with a visual interface and a framework that leads you through the process, with minimal coding skills required.
|
||||
|
||||
The vast majority of the complexity of processing data is handled internally by the bots and you don't really need to deal with that complexity or even understand it. The platform isolates complexity and only exposes you to the crucial elements that determine what you wish to accomplish.
|
||||
|
||||
This section of the User Manual will first provide you with some technical understanding of how data is handled by the platform. Once the theoretical framework is laid out, it will guide you through the process of modifying existing datasets and building your own.
|
||||
|
||||
The core of the functionality this section unveils covers—in essence—the following points:
|
||||
|
||||
* The capacity to define any number of calculation processes that may feed from each other's outputs, resulting in a wealth of *information* that may be consumed by trading strategies.
|
||||
|
||||
* The properties and characteristics of datasets resulting from the execution of such processes (how and where they are stored, in what format, how they are consumed internally and potentially by other systems).
|
||||
|
||||
We will first lay out the conceptual framework and explore the architecture, and only then go into the details of how to use the data processing functionality.
|
||||
@@ -0,0 +1,100 @@
|
||||
---
|
||||
title: Datasets
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-datasets.html
|
||||
---
|
||||
|
||||
Bots have two types of outputs: datasets, and status reports.
|
||||
|
||||
## Datasets File Formats
|
||||
|
||||
Bots store data in the form of arrays of records, in a minimized plain text file with in the standard JSON format, although not as objects with named properties, but as arrays.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/68998023-303eae00-08ad-11ea-9baa-ddea801c7d6d.png)
|
||||
|
||||
The choice of plain text for storage of large volumes of information has benefits in terms of not requireing any sophisticated technology to store and serve the data (*i.e.:* no database is required).
|
||||
|
||||
Best practice indicates that there needs to be a balance between the amount of data that is stored and calculations that may be performed at runtime.
|
||||
|
||||
Storing objects with named properties in the JSON format would be innapropriate as labels would repeat over and over, creating ridiculous amount of unnecessary information. However, storing arrays in the JSON standard facilitates the manipulatioon of files in the context of JavaScript and Node.JS.
|
||||
|
||||
## Types of Datasets
|
||||
|
||||
A dataset is a file or a collection of files.
|
||||
|
||||
Different products may require—for different reasons—to store data in different kinds of structures.
|
||||
|
||||
For instance, writting a single file with all historic trades in a market spanning several years would be unreasonable, as the file would be too heavy, with hundreds of millions of records. In such case, accessing particular information concerning a specific point in time would require loading the whole market.
|
||||
|
||||
Let's look into a specific example...
|
||||
|
||||
The Charts offer the possibility to navigate market data in the form of candles over different time periods. It is reasonable to keep candles in time periods of 1 hour and above (up to the 24-hour time period) in a single file. A market spanning 5 years would have less than 44 thousand records ```(5 * 365 * 24)``` of 1-hour candles. It seems reasonable for the Charts to load a single file so as to allow the user to seamlessly navigate large sections of the market in this time period, for instance, several days or weeks.
|
||||
|
||||
However, if the user wishes to browse 1 minute candles it is obvious his or her focus does not span days or weeks, let alone the whole market. The person is surely interested in analyzing a very specific point in time. Therefore, loading a single file with over 2.5 million records ```(5 * 365 * 24 * 60)``` would be unreasonable.
|
||||
|
||||
In other words, different densities of information require different data structures so that data may be consumed efficiently.
|
||||
|
||||
Moreover, bear in mind that data may eventually need to be transferred over the Internet, for intance when consuming indicators from a third-party node in the network. In such settings, the structure of the data becomes a critical issue and not just a matter of convenience or efficiency.
|
||||
|
||||
In addition, you wish the trading bot to be able to evaluate conditions and situations as fast as possible, therefore, loading the minimum data required is also a performance concern.
|
||||
|
||||
With all this in mind, lets go through the five different types of datasets existing at the moment: *market files*, *daily files*, *minutes files*, *single file*, and *file sequence*. These types of datasets define the structure of the data and how it is stored.
|
||||
|
||||
* A _market file_ contains data spanning the whole existence of the market, that is, from the day the pair _(e.g. USDT-BTC)_ started trading up to the present time. The data is stored in one single file, which is appended every time the process runs generating new data.
|
||||
|
||||
* A _daily file_ contains data segmented by day. That is, the process generates one file per day and stores it in the deepest level of a folder tree structure of the following type: ```Year > Month > Day```.
|
||||
|
||||
* A _minutes file_ contains data corresponding to one single minute and is stored in the deepest level of a folder tree structure of the following type: ```Year > Month > Day > Hour > Minute```.
|
||||
|
||||
* A _file sequence_ consists of sequential information that is not necessarily structured on any particular timeframe. The process stores two types of files: the one ending in _.Sequence.json_ contains the number of files in the sequence, and the sequence is formed by multiple files ending in a sequential number _(e.g. 15.json)_.
|
||||
|
||||
## Sensors and Indicators Output
|
||||
|
||||
The route for writing bot's output is built as follows:
|
||||
|
||||
```Bot Name and version > the version of AACloud (an internal platform component) > the version of the dataset > Output folder```
|
||||
|
||||
_e.g.:_
|
||||
|
||||
```
|
||||
\AAOlivia.1.0\AACloud.1.1\Poloniex\dataSet.V1\Output
|
||||
```
|
||||
|
||||
The format in which bots store their output is standardized. In an attempt to make data highly accessible, a tree-like folder structure is built following this pattern (which may slightly differ from bot to bot, depending on the specific dataset):
|
||||
|
||||
```
|
||||
Dataset Name > Process Name > Time Period > Year > Month > Day > Hour
|
||||
```
|
||||
|
||||
_e.g.:_
|
||||
|
||||
```
|
||||
\Candles\Multi-Period-Daily\01-min\2019\08\15
|
||||
```
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/63342762-979b9f00-c34c-11e9-8975-4735f0778d35.gif)
|
||||
|
||||
## Trading Bot Output
|
||||
|
||||
The trading bot is a particular case, as it stores data from multiple simulation and live-trading sessions.
|
||||
|
||||
To do this efficiently, the trading bot creates folders for storing the output and status reports of each session, naming each folder after the session ID.
|
||||
|
||||
If for some reason you wish to change the name of an output folder for something easier to read, you may include the following snippet under the *Edit Session* option in the menu of the corresponding session:
|
||||
|
||||
```
|
||||
"folderName":"YourName"
|
||||
```
|
||||
|
||||
Your custom name will be displayed along with the session ID in the name of the folder, in the following format:
|
||||
|
||||
```
|
||||
YourName - 3e139ae2-138c-42ac-99d6-e0cf9c7c6ee6
|
||||
```
|
||||
|
||||
If you wish to know which ID corresponds to a certain session without defining a custom name, you may obtain it by clicking <kbd>Ctrl</kbd> + <kbd>.</kbd> while hovering the mouse pointer over the target session node.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67281472-c1e61600-f4cf-11e9-85dc-d81d7b2d014b.gif)
|
||||
|
||||
> **NOTE:** Replace <kbd>Ctrl</kbd> with <kbd>Command</kbd> in Mac systems.
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: Definitions
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-definitions.html
|
||||
---
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Icon</th>
|
||||
<th>Node</th>
|
||||
<th>Definition</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
|
||||
<tr>
|
||||
<td></td>
|
||||
<td>Basketball</td>
|
||||
<td>{{site.data.definitions.basketball}}</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td></td>
|
||||
<td>Baseball</td>
|
||||
<td>{{site.data.definitions.baseball}}</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td></td>
|
||||
<td>Football</td>
|
||||
<td>{{site.data.definitions.football}}</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td></td>
|
||||
<td>Soccer</td>
|
||||
<td>{{site.data.definitions.soccer}}</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td></td>
|
||||
<td>Workspace</td>
|
||||
<td>{{site.data.definitions.workspace}}</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
title: Dependencies
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-dependencies.html
|
||||
---
|
||||
|
||||
We established that bots produce products for others to consume. _Others_ include other algorithms, meaning that bots usually depend on the datasets produced by other bots. We call these _data dependencies_.
|
||||
|
||||
Bots consume their own status report and they might as well consume status reports from other algorithms. We call these _status dependencies_.
|
||||
|
||||
There are three types of *status dependencies*:
|
||||
|
||||
* *Self Reference* is the status dependency a process establishes with its own status report so as to learn what was done in the previous run.
|
||||
|
||||
* *Market Starting Point* is the status dependency a process may establish with another bot's status report to learn what is the date time of the begining of the market.
|
||||
|
||||
* *Market Ending Point* is a similar concept as the *market starting point* only that the goal is to learn how far the bot producing the input dataset (the data dependency) has processed so far.
|
||||
|
||||
The declaration of such dependencies is what allows bots to add value over the product of other bots, generating new, more elaborate products by further processing datasets that other bots have created.
|
||||
|
||||
As you may figure, the possibilities are endless when you have the power to combine information from different sources, produce an analysis on top of that information, and store the new information separately to be consumed by other bots, including the trading bot, through the trading logic behind strategies.
|
||||
|
||||
Let's go through the dependencies existing among the current set of bots shipped with the platform...
|
||||
|
||||
## Charly
|
||||
|
||||
Charly is a _sensor bot_. He gets both historic and live trades data from exchanges and assures consistency using recursive processes before storing it in a highly fragmented and usable dataset.
|
||||
|
||||
Charly has three different processes: Live-Trades, Historic-Trades, and Hole-Fixing. These three processes combined create the one Charly product: Trades, stored in a single dataset.
|
||||
|
||||
The dataset is stored under the _minutes_ file structure. This structure is very efficient to store large amounts of data the is to be consumed in one-minute chunks by another bot, as you will soon learn.
|
||||
|
||||
The process *Historic-Trades* provides the information about the starting point of the market to all other bots. It's logical, as Charly is the only bot in contact with the exchange.
|
||||
|
||||
## Bruce
|
||||
|
||||
Now, let's see what Bruce, an *indicator bot*, does with Charly's product. Bruce offers two products, *Candles* and *Volumes*, stored in two datasets: candles at 1-minute resolution and volumes at 1-minute resolution. The datasets are stored under the _daily file_ type of dataset.
|
||||
|
||||
Can you guess what is Bruce's data dependency? That's right! Bruce depends on Charly's product.
|
||||
|
||||
Bruce takes the trades data that Charly extracted from the exchange in intervals of one minute, and processes it as follows:
|
||||
|
||||
* finds the first and last trades to come up with the open and close values,
|
||||
|
||||
* goes over all trades to extract minimum and maximum values,
|
||||
|
||||
* agregates buy and sell trades volume,
|
||||
|
||||
With that information Bruce builds a dataset of 1-minute candles and 1-minute volumes, each of them stored under the _daily file_ structure.
|
||||
|
||||
Notice how Charly storing 1-minute files makes Bruce's work straightforward. Bruce needs to load a single file that contains all the data it needs to build each 1-minute candle and 1-minute volume.
|
||||
|
||||
In other words, Bruce is adding value to Charly's product and offering a new value-added product of his own. But the value-adding chain does not stop there...
|
||||
|
||||
## Olivia
|
||||
|
||||
Let's take a look at another indicator, Olivia. She offers four different products: candles at sub-hour resolutions, candles in resolutions above one hour, volumes in sub-hour resolutions and volumes in resolutions above one hour.
|
||||
|
||||
And guess what? Indeed, Olivia uses Bruce's 1-minute candles and 1-minute volumes to produce complementary candles and volumes at different resolutions.
|
||||
|
||||
As a result, Olivia stores data in two different types of datasets: *daily files* for resolutions below one hour and *market files* for resolutions of one hour and above.
|
||||
|
||||
From this point and onwards, all bots processing Olivia's products and subsequent derivatives will likely store data in the same two types of datasets, so as to maintain the most efficient possible data structures to serve the intended purposes.
|
||||
|
||||
## Tom
|
||||
|
||||
Tom uses candles from Bruce and Olivia to produce the candle-stairs pattern indicator.
|
||||
|
||||
## Chris
|
||||
|
||||
Chris uses Olivia's candles to produce the Bollinger Bands indicator.
|
||||
|
||||
## Paula
|
||||
|
||||
Paula uses Chris' Bollinger Bands dataset to build the Bollinger Channel and Bollinger SubChannel indicators.
|
||||
|
||||
## Jason
|
||||
|
||||
The last link in the chain usually comes in the form of user strategies handled by the trading bot, Jason—consuming data from indicators to make trading decisions.
|
||||
|
||||
Of course, the main goal of a strategy is to perform profitable trading. However, notice that Jason has outputs too: Simulations, Formulas & Conditions, Trades, Strategies and Live are products that Jason exposes so that the Trading Simulation Plotter may create a visual representation of strategies' actions over the charts.
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
title: "Interface"
|
||||
summary: "Navigation allows the use of mouse and keyboard. You may also create shortcuts. Node's menu controls allows overiding the physics of the environment."
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-designer-interface.html
|
||||
---
|
||||
|
||||
## Navigation
|
||||
|
||||
Left-click on the black background and drag to move around the workspace.
|
||||
|
||||
You may also use the following key combinations on your keyboard:
|
||||
|
||||
1. <kbd>Ctrl or ⌘</kbd> + <kbd>←</kbd> to pan to the left.
|
||||
1. <kbd>Ctrl or ⌘</kbd> + <kbd>→</kbd> to pan to the right.
|
||||
1. <kbd>Ctrl or ⌘</kbd> + <kbd>↑</kbd> to pan upwards.
|
||||
1. <kbd>Ctrl or ⌘</kbd> + <kbd>↓</kbd> to pan downwards.
|
||||
|
||||
You may also use your keyboard as follows:
|
||||
|
||||
1. <kbd>Alt</kbd> + <kbd>↑</kbd> to close the charts and open the designer.
|
||||
1. <kbd>Alt</kbd> + <kbd>↓</kbd> to close the designer and open the charts.
|
||||
1. <kbd>Alt</kbd> + <kbd>→</kbd> to open both the designer and the charts, assigning each one-half of the screen.
|
||||
1. <kbd>Ctrl or ⌘</kbd> + <kbd>Shift</kbd> + <kbd>↑</kbd> to pull the separation bar up incrementally.
|
||||
1. <kbd>Ctrl or ⌘</kbd> + <kbd>Shift</kbd> + <kbd>↓</kbd> to pull the separation bar down incrementally.
|
||||
|
||||
## Node Shortcuts
|
||||
|
||||
You may define shortcuts for frequently-used nodes with the following procedure:
|
||||
|
||||
1. Hover the mouse pointer over the target node until the menu opens up. This puts the node *in focus*.
|
||||
1. Click <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + your preferred key to assign the shortcut.
|
||||
1. A sign will appear below the node confirming the assignation of the shortcut.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/70344838-f123cd00-185a-11ea-819f-92c4cf1e93ea.gif)
|
||||
|
||||
Repeat the same procedure to remove a shortcut.
|
||||
|
||||
When attempting to assign a shortcut with a keyboard combination that is already in use, the platform will notify of the issue. If you insist by hitting the same keyboard combination two more times, the platform will assign the shortcut as expected.
|
||||
|
||||
## Node's Menu
|
||||
|
||||
Hovering the mouse pointer over nodes causes a menu to pop up. In this situation, the node is *in focus*.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/63047274-621e2e00-bed4-11e9-90ff-614b279c9910.gif)
|
||||
|
||||
The designer functions under the paradigm of a *self-organizing workspace* in which nodes tend to find their place guided by certain laws of physics, and constrained by their chain relationships.
|
||||
|
||||
This self-organizing paradigm saves users the effort of maintaining the arrangement of nodes in a logical manner, in particular when manipulating or creating new nodes.
|
||||
|
||||
However, there will be times in which you will want to override this self-organizing nature. The following menu options are tools that will help you manipulate the arrangement of nodes, overriding the physics that affect their default floating nature.
|
||||
|
||||
| Icon | Status / Action |
|
||||
| --- | --- |
|
||||
|  | The node is pinned to the workspace on a specific X-Y coordinate. |
|
||||
|  | The node is free to find its place, unpinned. |
|
||||
|  | The node's chain connections with its parent and offspring are frozen. Connecting lines are blue. If you freeze the head node of a hierarchy, then the whole hierarchy is frozen. Freezing node structures releases CPU resources, as the platform stops calculating node's positions and status. |
|
||||
|  | The node's connections are unfrozen. If you click the option to unfreeze a node and the node does not change its status, that is because a higher node in the hierarchy is still frozen. |
|
||||
|  | The node is locked to a *rotational symmetry* in relation with the rest of the nodes at the same level of the hierarchy, thus all angles between nodes are equal. The connection lines are orange.|
|
||||
|  | The node is not locked in a rotational symmetry; instead, angles are free. The connection lines are yellow.|
|
||||
|  | Clicking the _minus_ button contracts the structure hiding offspring nodes. This also has the effect of releasing CPU resources as the platform stops calculating their position and status. In general, it is good practice to keep hierarchies closed when not being actively worked on. |
|
||||
|  | Clicking the _plus_ button expands the structure of offspring nodes. |
|
||||
|
||||
The rest of the menu options available in most nodes are the following:
|
||||
|
||||
| Icon | Action |
|
||||
| --- | --- |
|
||||
|  | **Backup**: Downloads a JSON file with the data structure and references concerning the particular node and the structure of offspring nodes in the hierarchy. Use this feature to save your entire workspace or any particular structure of nodes within your workspace so that you may later restore the information, including all references, should you need to. For your reference, the file downloaded is named ```Backup``` followed by the name of the node you are backing up. |
|
||||
|  | **Clone**: Downloads a JSON file containing information similar to a backup. The main difference is that the feature is built to facilitate the production of identical copies of any particular structure of nodes of a hierarchy, or a complete hierarchy. Use this feature to accelerate your work process when you need to replicate nodes, for example, to create multiple testing sessions. The file downloaded is named ```Clone``` followed by the name of the node you are cloning. |
|
||||
|  | **Share**: Downloads a JSON file containing information similar to a backup. The only difference is that no personal information is included. This is particularly important so that you do not share sensitive information accidentally, such as your API keys. Always use this function when you intend to share work. Do not share your backups. The file downloaded is named ```Share``` followed by the name of the node you are sharing. |
|
||||
|  | **Delete**: Deletes the node and all its offspring. A confirmation in the form of an additional click is required. |
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: "Designer, Workspace and Data Structures"
|
||||
summary: "Workspace, nodes, structure of nodes and their parent-offspring relationships are the overarching concepts giving structure to all information handled by the system."
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-designer-workspace-and-data-structures.html
|
||||
---
|
||||
|
||||
The Superalgos Suite handles lots of concepts encompassing fields such as markets information, intelligence in the form of data and trading strategies, visualization features, workflows, technical resources, and many more.
|
||||
|
||||
All of these concepts need to be structured for the user to make sense of them, and use them intuitively after learning the Suite's conceptual paradigm.
|
||||
|
||||
This page explains the concepts that deal with the structuring and managing of the rest of the concepts.
|
||||
|
||||
## Designer
|
||||
|
||||
{{site.data.concepts.designer}}
|
||||
|
||||
In practical terms, is the portion of the system you access when you pull up the sliding panel, hidding the charts in the process.
|
||||
|
||||
IMAGE
|
||||
|
||||
## Workspace
|
||||
|
||||
{{site.data.concepts.workspace}}
|
||||
|
||||
It contains:
|
||||
|
||||
* all hierarchies with all of their nodes;
|
||||
|
||||
* nodes that may be floating around detached from hierarchies;
|
||||
|
||||
* information regarding the physical position and status of all nodes within the Designer, even those detached from the hierarchies.
|
||||
|
||||
The <a href="" data-toggle="tooltip" data-original-title="{{site.data.concepts.workspace}}">workspace</a> is not part of any of the hierarchies; instead, it contains them.
|
||||
|
||||
{% include note.html content="Backing up your workspace is the best way to store all the information within the Designer, ready to be deployed. Your workspace is saved at the browser level every time you make a change, but still, you should back up your workspace once in a while so that you can go back to past versions or recover from the occasional crash. " %}
|
||||
|
||||
## Node
|
||||
|
||||
{{site.data.concepts.node}}
|
||||
|
||||
## Structure of Nodes
|
||||
|
||||
{{site.data.concepts.structure_of_nodes}}
|
||||
|
||||
As a concequence, structures of nodes are hierarchical structures, and a logical representation of how the concepts embodied by each node relate to each other.
|
||||
|
||||
IMAGE
|
||||
|
||||
## Parent-Offspring Relationships
|
||||
|
||||
{{site.data.concepts.parent-offspring_relationships}}
|
||||
|
||||
The direction of the relationship is determined, in most cases, by the hability of a node to produce the offspring node. That is, the parent node is the one which, by software design, may produce the offspring node.
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "Attachment and Detachment of Nodes"
|
||||
summary: "Nodes may be detached and reatached to its parents, following the logic dictated by the system."
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-detachment-and-attachment-of-nodes.html
|
||||
toc: false
|
||||
---
|
||||
|
||||
{{site.data.concepts.chain}}
|
||||
|
||||
This feature may be handy when testing different configurations, rules or parameters, as it allows to keep alternatives handy in the workspace.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/63227849-6d7e9b80-c1eb-11e9-9a02-6f760f383751.gif)
|
||||
|
||||
{% include note.html content="The verbs *to chain* and *to attach* may be used interchangeably, as synonyms. Similarly, *to unchain* and *to detach* are both valid." %}
|
||||
|
||||
To detach a node, right-click on it and drag it away from the parent node. To attach a node, right-click on it and move it closer to the node you wish to attach it to.
|
||||
|
||||
Nodes may be attached only to potential parents. The system limits the way in which nodes may be attached, according to the logic of the information they contain.
|
||||
|
||||
Nodes may not be detached or attached to frozen nodes. You need to unfreeze them before attaching or detaching.
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: Download and Set Up
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-download-and-set-up.html
|
||||
---
|
||||
|
||||
This *Getting Started Guide* will quickly show you the very basics of the platform so that you can rapidly grasp the platform's potential. It will take you through a sequence of instructions that you need to follow to download and install the platform, run it for the first time, import an existing strategy, run your first backtest, and, if you are up for it, start trading live.
|
||||
|
||||
Please follow the version of the explanation that best suits your profile:
|
||||
|
||||
* [The quick version for experienced PC operators](#the-quick-version-for-experienced-pc-operators)
|
||||
* [The extended version for regular folks](#the-extended-version-for-regular-folks)
|
||||
|
||||
## The Quick Version for Experienced PC Operators
|
||||
|
||||
### 1. Downloads
|
||||
|
||||
Download the software package from the [latest software release](https://github.com/Superalgos/DesktopApp/releases/tag/v.0.0.5-beta) (```Superalgos-Platform.zip```) and extract the file in an accessible route (you will launch the platform from the extracted folders).
|
||||
|
||||
Download historic market data from the [latest data release](https://github.com/Superalgos/DesktopApp/releases/tag/data.poloniex.btc.usdt.2019.12.06) (```Poloniex.BTC.USDT.Historic.Data.zip```) and extract the file inside the ```Superalgos Platform``` folder generated by the software ZIP package.
|
||||
|
||||
You should end up with the following folder structure:
|
||||
|
||||
|
||||
|
||||
> **NOTE:** Make sure the data ended up as the ```Data-Storage``` folder, right inside the ```Superalgos Platform``` root folder.
|
||||
|
||||
### 2. Continue with [Running the Platform](Running-the-Platform)
|
||||
|
||||
## The Extended Version for Regular Folks
|
||||
|
||||
### 1. Download the Software Package
|
||||
|
||||
Go to the [latest Superalgos Platform release](https://github.com/Superalgos/DesktopApp/releases/tag/v.0.0.5-beta) and download ```Superalgos-Platform.zip```.
|
||||
|
||||
### 2. Extract the ZIP File
|
||||
|
||||
How you extract/unpack the files depends on the software you use to handle ZIP files. Double-clicking the ZIP file should work in most scenarios, however, some systems may "open" the file instead of "extracting" or "unpacking" it. Make sure you are "extracting" and not just "opening" the file. You may also right-click the file and check the options available on the pop-up menu.
|
||||
|
||||
When you extract the ZIP file, a folder structure will be created with the root folder being ```Superalgos Platform```.
|
||||
|
||||
You may extract/unpack the files in any location of your drive, however, we recommend unpacking in an accessible route *(i.e.: ```C:\```)*, as you will later need to fit an additional folder inside the ```Superalgos Platform``` folder, and you will also need to access these folders every time you launch the platform.
|
||||
|
||||
### 3. Download the Data Package
|
||||
|
||||
For your convenience and [the reasons explained elsewhere](What-to-Expect), we maintain a market-data file that you can download, so that you may be up and running as quickly as possible.
|
||||
|
||||
Go to the [latest Data release](https://github.com/Superalgos/DesktopApp/releases/tag/data.poloniex.btc.usdt.2019.12.06) and download ```Poloniex.BTC.USDT.Historic.Data.zip```.
|
||||
|
||||
The ZIP file includes highly-compressed complete historic BTC/USDT Poloniex market data. Expect decompression to take from 30 to 60 minutes, depending on your system. Once you have the historic data, the platform will make sure the data stays up to date.
|
||||
|
||||
### 4. Extract the ZIP file
|
||||
|
||||
You need to extract the file inside the ```Superalgos Platform``` folder generated by the first ZIP file. You can achieve this in two ways:
|
||||
|
||||
A. Move ```Poloniex.BTC.USDT.Historic.Data.zip``` inside the ```Superalgos Platform``` folder, right-click the ZIP file and select *Extract here* in the pop-up menu. This is the quickest method.
|
||||
|
||||
B. Extract the ZIP file anywhere else and then move the resulting ```Data-Storage``` folder inside the ```Superalgos Platform``` folder. This will take more than double the time.
|
||||
|
||||
You should end up with the following folder structure:
|
||||
|
||||
|
||||
|
||||
> **NOTE:** Make sure the data ended up as the ```Data-Storage``` folder, right inside the ```Superalgos Platform``` root folder.
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: Execution Limitations
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-execution-limitations.html
|
||||
---
|
||||
|
||||
At the current stage of development, users have no control whatsoever over the execution of orders.
|
||||
|
||||
The way execution works at this stage is quite basic: once conditions are met for taking a position, or once a take profit or stop target is hit, **one single market order is placed at the exchange**.
|
||||
|
||||
When taking a position, the Take Position price shown in simulations is defined by the formula you use in your ```Open Stage > Position Rate > Formula```.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/63421629-3980c180-c409-11e9-837e-212e69588ebb.gif)
|
||||
|
||||
**However, this is overridden during live-trading, and replaced with a market order.**
|
||||
|
||||
When taking profit or hitting a stop, that is, when attempting to close a position, the price in simulations is determined by the intersection of the corresponding candle with the values resulting from the active take profit and stop phases formulas.
|
||||
|
||||
**However, during live-trading, once a take profit or stop target is hit, the order to close the trade is placed as a market order.**
|
||||
|
||||
Let's quickly review one of the implications these limitations may have, with an example:
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/63420370-d2faa400-c406-11e9-9d0d-ce82cdd078c9.gif)
|
||||
|
||||
The image above, featuring 10-minutes candles, shows a sudden drop in price. As you may see, there where only three executions of the trading bot during the price drop.
|
||||
|
||||
Had there been a stop somewhere in the range of the sudden price drop, chances are that the price would trigger the stop in-between executions. This means that the engine would place the sell order some time after the price hit the stop, and the order would fill at a price lower than intended.
|
||||
|
||||
An additional limitation is that there currently is no feature to break up orders, therefore, the size of your orders and the likeliness of them getting filled depend on the liquidity of the market/exchange.
|
||||
|
||||
> **NOTE: It is important that you fully understand the implications of these limitations if you are considering to trade live with the platform at this stage, as you will need to adapt to the current state of affairs.**
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: Getting Ready to Trade Live
|
||||
summary: ""
|
||||
sidebar: suitev_sidebar
|
||||
permalink: suite-getting-ready-to-trade-live.html
|
||||
---
|
||||
|
||||
To start forward-testing or live-trading with your own strategy, you need to follow the same steps explained in the *Getting Started* guide.
|
||||
|
||||
Not mentioned there is the following detail:
|
||||
|
||||
Make sure the following nodes are present in your strategy. If they are not, simply add them: go to the _Open Stage_ node and select _Add Open Execution_ on the menu; do the same with the _Close Stage_, adding _Close Execution_). No need to configure anything, simply make sure the nodes are there).
|
||||
|
||||
| Icon | Node | Stage |
|
||||
| :---: | :---: | :--- |
|
||||
|  | Open Execution | Open Stage |
|
||||
|  | Close Execution | Close Stage |
|
||||
|
||||
As soon as you click *Run* in your session, your bot will be forward testing or trading live. What happens is that you are still running a simulation—thus all the simulation layers keep plotting the same kind of information over the Charts.
|
||||
|
||||
The difference is that orders will now go to the exchange.
|
||||
|
||||
**For maximum efficiency, we recommend you run live trading sessions on the 01-min time period. Your bot will then be executed every 60 seconds to evaluate your strategy rules and decide if any action needs to be taken.**
|
||||
|
||||
This is important even if your strategy operates at a lower frequency, as running the live session at the 01-min time period guarantees that the trading bot will exit trades as soon as the one-minute candle closes tagging your stop or take profit target. On the contrary, if you run the live trading session at a time period higher than 01-min, slippage when closing the position may be considerably greater.
|
||||
|
||||
> **WARNING:** The Superalgos Platform is at a very early stage of development. As such, errors may occur at any point, including errors that can cause you to lose money. You are responsible for taking all precautions before starting trading live. Make sure you test with small amounts of money, the kind you can afford losing. Also, make sure you understand the [Execution Limitations](Execution-Limitations). Trade live at your own risk.
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: "Hierarchies"
|
||||
summary: "There are four different types of hierarchies: Trading Systems, Data Mines, Network, and Crypto Ecosystem."
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-hierarchies.html
|
||||
---
|
||||
|
||||
{{site.data.concepts.hierarchy}}
|
||||
|
||||
On the designer, the head or parent node of each hierarchy is represented by the corresponding icon surrounded by an ever-present white ring, so that they are easier to locate within the workspace.
|
||||
|
||||
IMAGE
|
||||
|
||||
## Charting System
|
||||
|
||||
{{site.data.charting_system.charting_system}}
|
||||
|
||||
## Trading System
|
||||
|
||||
{{site.data.trading_system.trading_system}}
|
||||
|
||||
## Data Mine
|
||||
|
||||
{{site.data.data_mine.data_mine}}
|
||||
|
||||
## Network
|
||||
|
||||
{{site.data.network.network}}
|
||||
|
||||
## Crypto Ecosystem
|
||||
|
||||
{{site.data.crypto_ecosystem.crypto_ecosystem}}
|
||||
|
||||
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
title: Indicators Included in the Data Release
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-indicators-included-in-the-data-release.html
|
||||
---
|
||||
|
||||
The following indicators are those readily available as soon as you fire up the platform, as the corresponding datasets are included in the data release.
|
||||
|
||||
## Candles
|
||||
|
||||
The product ```candle``` features five different properties that you may use.
|
||||
|
||||
| Product Name | Product Variable | Property Variables |
|
||||
| :---: | :---: | :--- |
|
||||
| Candles | ```candle``` | ```min```, ```max```, ```open```, ```close```, ```direction``` |
|
||||
|
||||
```candle.min```: The minimum price of the last closed candle (low).
|
||||
|
||||
```candle.max```: The maximum price of the last closed candle (high).
|
||||
|
||||
```candle.open```: The price at which the last closed candle opened.
|
||||
|
||||
```candle.close```: The price at which the last closed candle closed.
|
||||
|
||||
```candle.direction```:
|
||||
* ```"Down"```: candle.close < candle.open (bearish candle)
|
||||
* ```"Up"```: candle.close > candle.open (bullish candle)
|
||||
* ```"Side"```: candle.close = candle.open (neutral candle)
|
||||
|
||||
## Bollinger Bands (BB)
|
||||
|
||||
The product ```bollingerBand``` features four different properties that you may use.
|
||||
|
||||
| Product Name | Product Variable | Property Variables |
|
||||
| :---: | :---: | :--- |
|
||||
| Bollinger Bands | ```bollingerBand``` | ```movingAverage```, ```standardDeviation```, ```deviation```, ```direction``` |
|
||||
|
||||
```bollingerBand.movingAverage```: The value of the current moving average (20 periods).
|
||||
|
||||
```bollingerBand.standardDeviation```: The value of current the [standard deviation](https://en.wikipedia.org/wiki/Standard_deviation).
|
||||
|
||||
```bollingerBand.deviation```: bollingerBand.standardDeviation * 2
|
||||
|
||||
```bollingerBand.direction```:
|
||||
* ```"Down"```: bollingerBand.previous.movingAverage > bollingerBand.movingAverage
|
||||
* ```"Up"```: bollingerBand.previous.movingAverage < bollingerBand.movingAverage
|
||||
* ```"Side"```: bollingerBand.previous.movingAverage = bollingerBand.movingAverage)
|
||||
|
||||
## Percentage Bandwidth (%B)
|
||||
|
||||
The product ```percentageBandwidth``` features four different properties that you may use.
|
||||
|
||||
| Product Name | Product Variable | Property Variables |
|
||||
| :---: | :---: | :--- |
|
||||
| Percentage Bandwidth | ```percentageBandwidth``` | ```value```, ```movingAverage```, ```bandwidth```, ```direction``` |
|
||||
|
||||
```percentageBandwidth.value```: A numeric value between 0 and 100; the current value of the percentage bandwidth.
|
||||
|
||||
```percentageBandwidth.movingAverage```: A numeric value between 0 and 100; the current value of the percentage bandwidth moving average.
|
||||
|
||||
```percentageBandwidth.bandwidth```: A numeric value between 0 and 100; the current bandwidth.
|
||||
|
||||
```percentageBandwidth.direction```:
|
||||
* ```"Down"```: percentageBandwidth.previous.movingAverage > percentageBandwidth.movingAverage
|
||||
* ```"Up"```: percentageBandwidth.previous.movingAverage < percentageBandwidth.movingAverage
|
||||
* ```"Side"```: percentageBandwidth.previous.movingAverage = percentageBandwidth.movingAverage)
|
||||
|
||||
## Bollinger Channels (BC)
|
||||
|
||||
The product ```bollingerChannel``` features two different properties that you may use.
|
||||
|
||||
| Product Name | Product Variable | Property Variables |
|
||||
| :---: | :---: | :--- |
|
||||
| Bollinger Channels | ```bollingerChannel``` | ```direction```, ```period``` |
|
||||
|
||||
```bollingerChannel.direction```: Possible values are ```"Down"```, ```"Up"```, and ```"Side"```.
|
||||
|
||||
```bollingerChannel.period```: The number of periods the channel spans at the moment the variable is being read. For instance, if a channel spans 10 candles and the variable is checked on the fourth candle, then _bollingerChannel.period_ = 4. Put in other words, it is the current span of the channel.
|
||||
|
||||
## Bollinger SubChannels (BSC)
|
||||
|
||||
The product ```bollingerSubChannel``` features three different properties that you may use.
|
||||
|
||||
| Product Name | Product Variable | Property Variables |
|
||||
| :---: | :---: | :--- |
|
||||
| Bollinger SubChannels | ```bollingerSubChannel``` | ```direction```, ```period```, ```slope``` |
|
||||
|
||||
```bollingerSubChannel.direction```: Possible values are ```"Down"```, ```"Up"```, and ```"Side"```.
|
||||
|
||||
```bollingerSubChannel.period```: The number of periods the subchannel spans at the moment the variable is being read. For instance, if a subchannel spans 10 candles and the variable is checked on the fourth candle, then _bollingerChannel.period_ = 4. Put in other words, it is the current span of the subchannel.
|
||||
|
||||
```bollingerSubChannel.slope```: Indicates how steep the slope of the subchannel is. Possible values are ```"Side"```, ```"Gentle"```, ```"Medium"```, ```"Steep"```, ```"Extreme"``` (in order from lowest to highest).
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
title: Indicators Not Included in the Data Release
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-indicators-not-included-in-the-data-release.html
|
||||
---
|
||||
|
||||
## Simple Moving Average (SMA)
|
||||
|
||||
There are three products pre-configured to start calculating as soon as you start the corresponding task, each with different period configurations:
|
||||
|
||||
| Product Name | Product Variable | Period Variables |
|
||||
| :---: | :---: | :--- |
|
||||
| Popular SMAs | ```popularSMA``` | ```sma20```, ```sma50```, ```sma100```, ```sma200``` |
|
||||
| Base 7 | ```base7SMA``` | ```sma7```, ```sma14```, ```sma21```, ```sma28```, ```sma35```, ```sma70```, ```sma140```, ```sma210```, ```sma280```, ```sma350```, ```sma700```, ```sma1400```|
|
||||
| Base 11 | ```base11SMA``` | ```sma11```, ```sma22```, ```sma33```, ```sma55```, ```sma111``` |
|
||||
|
||||
There are four more products available but they will not be calculated unless you create the corresponding data outputs and reference them to the corresponding data sets:
|
||||
|
||||
| Product Name | Product Variable | Period Variables |
|
||||
| :---: | :---: | :--- |
|
||||
| Base 5 | ```base5SMA``` | ```sma5```, ```sma10```, ```sma15```, ```sma20```, ```sma25```, ```sma50```, ```sma100```, ```sma150```, ```sma200```, ```sma250```, ```sma500```, ```sma1000``` |
|
||||
| Base 6 | ```base6SMA``` | ```sma6```, ```sma12```, ```sma18```, ```sma24```, ```sma30```, ```sma60```, ```sma120```, ```sma180```, ```sma240```, ```sma300```, ```sma600```, ```sma1200``` |
|
||||
| Base 12 | ```base12SMA``` | ```sma12```, ```sma24```, ```sma36```, ```sma48```, ```sma60```, ```sma120```, ```sma240```, ```sma360```, ```sma480```, ```sma600```, ```sma1200``` |
|
||||
| Base 30 | ```base30SMA``` | ```sma30```, ```sma60```, ```sma90```, ```sma120```, ```sma150```, ```sma300```, ```sma600```, ```sma900```, ```sma1200```, ```sma1500``` |
|
||||
|
||||
**Examples:**
|
||||
|
||||
1. ```chart.at24hs.popularSMA.sma50 > chart.at24hs.popularSMA.sma200``` — An indication of a bull market? Is the 50-day moving average above the 200-day moving average?
|
||||
|
||||
1. ```chart.at24hs.popularSMA.sma200 > chart.at24hs.base7SMA.sma350``` — Looking even further in the past, comparing a 200-day with a 350-day moving average. Notice how the two MA belong to different products.
|
||||
|
||||
## Exponential Moving Average (EMA)
|
||||
|
||||
The products and periods available in EMA map exactly the products and periods available in SMA. To use EMA you simply need to replace the S with an E. That said, for your reference, this is the complete list...
|
||||
|
||||
Like with SMAs, there are three products pre-configured to start calculating as soon as you start the corresponding task, each with different period configurations:
|
||||
|
||||
| Product Name | Product Variable | Period Variables |
|
||||
| :---: | :---: | :--- |
|
||||
| Popular EMAs | ```popularEMA``` | ```ema20```, ```ema50```, ```ema100```, ```ema200``` |
|
||||
| Base 7 | ```base7EMA``` | ```ema7```, ```ema14```, ```ema21```, ```ema28```, ```ema35```, ```ema70```, ```ema140```, ```ema210```, ```ema280```, ```ema350```, ```ema700```, ```ema1400```|
|
||||
| Base 11 | ```base11EMA``` | ```ema11```, ```ema22```, ```ema33```, ```ema55```, ```ema111``` |
|
||||
|
||||
There are four more products available but they will not be calculated unless you create the corresponding data outputs and reference them to the corresponding data sets:
|
||||
|
||||
| Product Name | Product Variable | Period Variables |
|
||||
| :---: | :---: | :--- |
|
||||
| Base 5 | ```base5EMA``` | ```ema5```, ```ema10```, ```ema15```, ```ema20```, ```ema25```, ```ema50```, ```ema100```, ```ema150```, ```ema200```, ```ema250```, ```ema500```, ```ema1000``` |
|
||||
| Base 6 | ```base6EMA``` | ```ema6```, ```ema12```, ```ema18```, ```ema24```, ```ema30```, ```ema60```, ```ema120```, ```ema180```, ```ema240```, ```ema300```, ```ema600```, ```ema1200``` |
|
||||
| Base 12 | ```base12EMA``` | ```ema12```, ```ema24```, ```ema36```, ```ema48```, ```ema60```, ```ema120```, ```ema240```, ```ema360```, ```ema480```, ```ema600```, ```ema1200``` |
|
||||
| Base 30 | ```base30EMA``` | ```ema30```, ```ema60```, ```ema90```, ```ema120```, ```ema150```, ```ema300```, ```ema600```, ```ema900```, ```ema1200```, ```ema1500``` |
|
||||
|
||||
**Examples:**
|
||||
|
||||
1. ```chart.at01hs.base5EMA.ema5 < chart.at01hs.base5EMA.ema25``` — May the trend be reversing? Checking if a fast 5-hours exponential moving average goes below the slower 25-hours EMA.
|
||||
|
||||
## Moving Average Convergence/Divergence (MACD)
|
||||
|
||||
There are four different products, each configured with a specific setting for the fast and slow moving avarages and the MACD Signal line.
|
||||
|
||||
| Product Setting | Product Variable | EMAs |
|
||||
| :---: | :---: | :--- |
|
||||
| MACD (12, 26, 9) | ```macd122609``` | ```ema12```, ```ema26``` |
|
||||
| MACD (3, 10, 16) | ```macd031016``` | ```ema3```, ```ema10``` |
|
||||
| MACD (8, 17, 9) | ```macd081709``` | ```ema8```, ```ema17``` |
|
||||
| MACD (24, 52, 9) | ```macd245209``` | ```ema24```, ```ema52``` |
|
||||
|
||||
The first few variables you may use from these products are those corresponding to the EMAs used to calculate the MACD line and the MACD signal line, as shown in the table above.
|
||||
|
||||
Also, each of the products in the above table feature the following properties:
|
||||
|
||||
| Property | Description |
|
||||
| :---: | :--- |
|
||||
| ```line``` | The MACD line, that is, the fast EMA minus the slow EMA. |
|
||||
| ```signal``` | The Signal line, that is, the *n-period* EMA of the MACD line (*n* is the last setting) |
|
||||
| ```histogram``` | The value of the histogram, that is, the difference between the MACD line and the MACD signal line. |
|
||||
|
||||
**Examples:**
|
||||
|
||||
1. ```chart.at30min.macd122609.line <= 0 && chart.at30min.macd122609.previous.line >= 0``` — A centerline crossover at the 30-minutes chart.
|
||||
|
||||
1. ```chart.at15min.macd031016.line >= chart.at15min.macd031016.signal && chart.at15min.macd031016.previous.line <= chart.at15min.macd031016.previous.signal``` — A signal line crossover at the 15-minutes chart.
|
||||
|
||||
|
||||
## Relative Strength Index (RSI)
|
||||
|
||||
The RSI product currently available uses the standard setting of 14 periods, and features a single property: ```rsi14.value```
|
||||
|
||||
**Examples:**
|
||||
|
||||
1. ```chart.at24hs.rsi14.value >= 70``` — How's the trend going at the 24-hours chart?
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: Input-to-Output Cycle
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-input-to-output-cycle.html
|
||||
---
|
||||
|
||||
Indicators use datasets produced by sensors or by other indicators as input. That is, they read an existing dataset, perform calculations over the input data, and store a desired output—hopefully, a value-added product.
|
||||
|
||||
Let's review the mechanics of the cycle that turns an input into an output, as that is—in essense—what building a new indicator or creating new datasets entails.
|
||||
|
||||
## Input
|
||||
|
||||
### 1. Loading Arrays
|
||||
|
||||
As explained earlier, indicators store information in arrays of data fields constituting records, in a plain text file. This is highly appropriate for storing data with the minimum possible weight.
|
||||
|
||||
For example, a typical record in the Multi-Period-Market Bollinger Bands dataset looks like this:
|
||||
|
||||
```
|
||||
[1425945600000,1426031999999,253.17351109,15.293043836574176,30.586087673148352]
|
||||
```
|
||||
|
||||
That is what the platform will encounter at the time of reading a typical dataset.
|
||||
|
||||
|
||||
### 2. Conversion to Objects with Named Properties
|
||||
|
||||
To make data usable for humans, it maps the content of each record with concepts that describe the data. Put in other words, the platform labels each field so that the user doesn't need to know or remember what each data field represents, and stores the data a JSON objetcs in memory.
|
||||
|
||||
### 3. Calculation of Not-Stored Properties
|
||||
|
||||
When an indicator stores data in the minimized array format discussed earlier, it may chose not to save information that is easily calculable.
|
||||
|
||||
For example, imagine the indicator stores buy and sell volumes... does it really need to store the total volume? Given that it is so easy to calculate, the answer is no.
|
||||
|
||||
**It is not worthy to store information that may be easily calculated at a later stage.**
|
||||
|
||||
Another example is Paula storing the information about the direction and slope of Bollinger Sub-Channels. In it's current state, Paula stores the following record structure:
|
||||
|
||||
```
|
||||
[1425945600000,1426031999999,"Up","Extreme",1,253.17351109,253.17351109,30.586087673148352,30.586087673148352]
|
||||
```
|
||||
|
||||
If instead of storing "Up" and "Extreme" Paula would map text strings with numbers—for instance 0 for "Up" and 1 for "Down", and do the same with the slope—her dataset would be 10 to 15% lighter. And such descriptive values could easily be assigned upon reading the file.
|
||||
|
||||
## Output
|
||||
|
||||
### 4. User Code Processing
|
||||
|
||||
The in-memory data structure resulting from point 3 above is finally ready to be used as input to perform whatever calculations or general procesing the code of the new indicator may perform.
|
||||
|
||||
Once all new desired properties are calculated, a somewhat reverse process is started so as to end up with an output in the similar format as the input. This involves deciding which properties will be written and which will be left out.
|
||||
|
||||
### 5. Writting the Output
|
||||
|
||||
The final stage is turning the Objects-formatted records back into a minimized array-form and storing it in the corresponding type of dataset.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: Internal Variables
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-internal-variables.html
|
||||
---
|
||||
|
||||
These are properties managed internally by the platform that are made available for using within strategies.
|
||||
|
||||
```strategyStage```: Possible values are ```"No Stage"```, ```"Trigger Stage"```, ```"Open Stage"```, ```"Manage Stage"```, and ```"Close Stage"```.
|
||||
|
||||
```stopLoss```: The value of your Stop in the active phase.
|
||||
|
||||
```stopLossPhase```: The number of the active Stop phase (0, 1, 2, ...).
|
||||
|
||||
```takeProfit```: The value of the Take Profit in the active phase.
|
||||
|
||||
```takeProfitPhase```: The number of the active Stop phase (0, 1, 2, ...).
|
||||
|
||||
```positionRate```: The price at which the position was taken.
|
||||
|
||||
```positionSize```: The size of the position.
|
||||
|
||||
```balanceAssetA```: Your BTC balance.
|
||||
|
||||
```balanceAssetB```: Your USDT balance.
|
||||
|
||||
```lastTradeProfitLoss```: The P&L value for the latest completed trade (roundtrip).
|
||||
|
||||
```lastTradeROI```: The ROI of your latest trade.
|
||||
|
||||
```profit```: The total P&L during the current execution period.
|
||||
|
||||
```roundtrips```: The total number of trades in the current execution.
|
||||
|
||||
```fails```: The number of trades resulting in losses in the current execution.
|
||||
|
||||
```hits```: The number of trades resulting in profits in the current execution.
|
||||
|
||||
```periods```: The number of candles evaluated in the current execution.
|
||||
|
||||
```positionPeriods```: The number of candles in the current open position.
|
||||
|
||||
```positionDays```: The number of days in the current open position.
|
||||
|
||||
```distanceToLast.triggerOn```: The number of periods between the last Trigger On and the current candle.
|
||||
|
||||
```distanceToLast.triggerOff```: The number of periods between the last Trigger Off and the current candle.
|
||||
|
||||
```distanceToLast.takePosition```: The number of periods between the last Take Position and the current candle.
|
||||
|
||||
```distanceToLast.closePosition```: The number of periods between the last Close Position and the current candle.
|
||||
@@ -0,0 +1,104 @@
|
||||
---
|
||||
title: Layers Panel
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-layers-panel.html
|
||||
---
|
||||
|
||||
## Indicators Included in the Data Release
|
||||
|
||||
### Candles
|
||||
|
||||
Typical candlesticks.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67269992-0a91d500-f4b8-11e9-9c67-a2bf3607d913.gif)
|
||||
|
||||
### Volumes
|
||||
|
||||
We innovated a bit placing the buy volume at the bottom (in green), and the sell volume at the top (in red).
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67269993-0b2a6b80-f4b8-11e9-8951-a1fbf12652b8.gif)
|
||||
|
||||
### Candle Stairs Patterns
|
||||
|
||||
This is an unusual pattern proving any dataset may be plotted on the charts (and by extension, that anything can be added to the system). A Stair Pattern is defined as a set of candles going in the same direction, either up or down. You can think of these patterns as "Candle Channels", as they represent channels with an up or down direction based on underlying candles direction.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67270464-05815580-f4b9-11e9-8a8d-7d18b8c470d7.gif)
|
||||
|
||||
### Volume Stairs Patterns
|
||||
|
||||
A similar concept, this time with volumes. Whenever a sequence of volume bars is found where each one is bigger than the previous one, they are bundled together in a "Stair". The same applies when they are going down (the next is smaller than the previous one). For a trading bot, this serves to identify if sell or buy volumes are rising or declining.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67270466-0619ec00-f4b9-11e9-8f62-8c227696c0fc.gif)
|
||||
|
||||
### Bollinger Bands
|
||||
|
||||
This is the traditional [Bollinger Bands indicator](https://en.wikipedia.org/wiki/Bollinger_Bands). Bollinger Bands have a moving average, in our case calculated with the last 20 periods (the line in the middle of the bands). We are plotting the moving average with one color when it is going up, and with a different color when it's going down. The upper band is at 2 Standard Deviations from the moving average, pretty much like the lower band, also at 2 Standard Deviations. These are the most widely used Bollinger Bands settings.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67270467-0619ec00-f4b9-11e9-9482-fbec44f0bf83.gif)
|
||||
|
||||
### Percentage Bandwidth
|
||||
|
||||
This is a well-known indicator that derives from the Bollinger Bands. In a nutshell, it tells you how close the price is either to the upper band or the lower band at any point in time. When the price is in the middle of the bands (it is calculated with the close value of each candle), then %B is in the middle of its chart, at value 50. When the price touches the upper band, then %B is at 100, and finally when the price is at the lower band, then %B is at 0.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67270468-0619ec00-f4b9-11e9-9dd5-e1def0d8c246.gif)
|
||||
|
||||
The chart features lines at %B values 30 and 70 since those are the most common values for traders to forecast when a reversal may happen. In our chart, %B is the one represented at #1. We've found useful to add a moving average to smooth volatility a bit and to be able to ask—at any time—if it is going up or down. The moving average calculated with the last 5 %B values is plotted as line #2. Finally, we've also added a property called Bandwidth, which represents the separation of the upper band from the lower band. It is a measure of volatility and is plotted at #3.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67270469-0619ec00-f4b9-11e9-8334-135bb54db1bf.gif)
|
||||
|
||||
### Bollinger Channels
|
||||
|
||||
This is a non-standard indicator derived from the Bollinger Bands. These types of channels are calculated using the Bollinger Bands moving average. Essentially an upward channel begins when the moving average changes _direction_ from going down to going up, and the channel finishes when it turns from going up to down. A downward channel starts when the Bollinger Band moving average turns from going up to down, and it finishes when it starts going up again. Upward channels are plotted in green, while downward channels in red. Additional information can be found at the indicator's panel, like the number of periods contained at the channel.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67271113-34e49200-f4ba-11e9-8365-070738856f2a.gif)
|
||||
|
||||
### Bollinger Sub-Channels
|
||||
|
||||
If we consider that one Bollinger Channel can have sub-channels in the same direction (up or down) but different slopes, then we get to the concept of Bollinger Sub-Channels. The most important property of a sub-channel is its slope. The possible values are Side, Gentle, Medium, High and Extreme. With this information, a trading bot could easily ask if it is in a sub-channel with a certain slope and for how many periods. The slope or inclination of the moving average may be an indication of momentum.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67271114-34e49200-f4ba-11e9-90c8-77623de1dd04.gif)
|
||||
|
||||
## Indicators Not Included in the Data Release
|
||||
|
||||
**The following list of indicators are not included in the data release, therefore, they will show nothing when you switch the corresponding layer on, until you get the appropriate bots to calculate the data.**
|
||||
|
||||
To learn how to get ready to use these indicators, please refer to the [Using indicators not included in the data release](Using-Indicators-Not-Included-in-the-Data-Release) page.
|
||||
|
||||
Most of the indicators listed here come with several *products*, each with different settings for the said indicator. To learn all the details, check the [Indicators not included in the data release](Indicators-Not-Included-in-the-Data-Release) page under the *Writing Conditions & Formulas* section of this User Manual.
|
||||
|
||||
### Relative Strength Index (RSI 14)
|
||||
|
||||
[According to Investopedia](https://www.investopedia.com/terms/r/rsi.asp), "The relative strength index (RSI) is a momentum indicator that measures the magnitude of recent price changes to evaluate overbought or oversold conditions in the price of a stock or other asset. The RSI is displayed as an oscillator (a line graph that moves between two extremes) and can have a reading from 0 to 100."
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71260426-2213ff80-233b-11ea-8a1f-447e00da3ec7.gif)
|
||||
|
||||
The chart for this indicator shows the RSI oscillating in a scale ranging from 0 at the bottom to 100 at the top. The bottom section of the chart shows a blue background covering the range from 0 to 20, also marked by a dotted line. When the RSI value falls below the 20 mark, the RSI line turns red, for easier viasualization. Also in the bottom section, there is a second dotted line signaling the 30 mark.
|
||||
|
||||
The equivalent (although reversed) effect is featured on the top half of the charts, with dotted lines signaling the 70 and 80 levels, and a blue background above 80.
|
||||
|
||||
There is also a dotted line at the 50 mark, signaling the median of the chart.
|
||||
|
||||
For the time being, the chart is fixed on the screen and the user may not move it.
|
||||
|
||||
### Simple Moving Average (SMA)
|
||||
|
||||
[According to Investopedia](https://www.investopedia.com/terms/e/ema.asp), "A simple moving average (SMA) is an arithmetic moving average calculated by adding recent closing prices and then dividing that by the number of time periods in the calculation average. Short-term averages respond quickly to changes in the price of the underlying asset, while long-term averages are slow to react."
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71260423-217b6900-233b-11ea-9229-d838f8a071da.gif)
|
||||
|
||||
You will find several layers with different settings for SMAs, calculated on different periods. Each layer corresponds to a *product* made available by the indicator.
|
||||
|
||||
The information panel shows the numeric value for each SMA in the layer, in ascending order (i.e. SMA 20, SMA 50, SMA 100, etc.).
|
||||
|
||||
### Exponential Moving Average (EMA)
|
||||
|
||||
[According to Investopedia](https://www.investopedia.com/terms/e/ema.asp), "An exponential moving average (EMA) is a type of moving average (MA) that places a greater weight and significance on the most recent data points. The exponential moving average is also referred to as the exponentially weighted moving average. An exponentially weighted moving average reacts more significantly to recent price changes than a simple moving average (SMA), which applies an equal weight to all observations in the period."
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71260424-217b6900-233b-11ea-830d-e445a01aca65.gif)
|
||||
|
||||
The same explanations offered for SMAs apply to EMAs.
|
||||
|
||||
## Simulation Layers
|
||||
|
||||
Simulation layers are those resulting from the graphic representation of strategies' actions, and are explained further down this User Manual, when discussing [Simulation layers](Simulation-Layers) and the [Live trading history layer](Live-Trading-History-Layer).
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: Live Trading History Layer
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-live-trading-history-layer.html
|
||||
---
|
||||
|
||||
In addition to the simulation layers, you will now be able to use the Live Trading History layer to get information about your trades.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/63526577-e9385b00-c4ff-11e9-898a-81880cfa0c7d.gif)
|
||||
|
||||
The layer plots tiny orange circles to indicate the precise point in time and price of each execution of the bot.
|
||||
|
||||
When a buy order is successfully placed and filled at the exchange, a green triangle pointing upwards is drawn on the screen. The lower tip of the triangle signals the point in time and rate of the order.
|
||||
|
||||
When a sell order fills, a red triangle is plotted over the charts.
|
||||
|
||||
> **TEMPORARY LIMITATION**: When live-trading, the simulation layers do not currently reflect the actual live trades, but the simulated ones. This means the take position rate and the exit rate (whether it is a take profit or stop loss) will be taken from the ideal rate (factoring fees and slippage as per the session's configuration) and not from the actual rate the orders filled at the exchange.
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: Overview
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-live-trading-overview.html
|
||||
---
|
||||
|
||||
Once you are happy with your strategy after extensive backtesting and paper-trading sessions, running it as a fully automated bot to trade live is quite simple. Truth be told, your strategy running as a simulation is pretty much a trading bot already—only that orders don't go to the exchange.
|
||||
|
||||
| Forward Testing | Live Trading |
|
||||
| :---: | :---: |
|
||||
|  |  |
|
||||
|
||||
It is recommended to forward test your strategy before committing serious capital to live-trading. Forward testing is usually the final testing phase before going live. It involves placing orders at the exchange for a fraction of the capital that you intend to use when trading live, and that is actually the only difference between a forward testing session and a live trading session.
|
||||
|
||||
Forward testing sessions and live trading sessions need to be configured under their corresponding tasks, pretty much like was explained for backtesting and paper-trading sessions, with a few minor nuances:
|
||||
|
||||
**1. Datetime Range**
|
||||
|
||||
Like with paper trading sessions, you only require a *finalDatetime*. If you do not set one either at the level of the session or the trading system then the session will run for one year.
|
||||
|
||||
```
|
||||
{
|
||||
"finalDatetime": "2020-12-31T23:59:99.999Z"
|
||||
}
|
||||
```
|
||||
|
||||
> **NOTE:** The *Exchange Rate* and *Slippage* parameters do not affect forward testing or live trading. However, those parameters are taken into account when creating simulation layers, which are also available during forward-testing and live-trading.
|
||||
|
||||
**2. Forward Testing Session Configuration**
|
||||
|
||||
In the case of forward testing you will want to configure what is the percentage of your balance that you wish to use for testing. You do this by clicking the *Edit Session* option on the session's menu and entering the desired value in the code snippet:
|
||||
|
||||
```
|
||||
{"balancePercentage": 1}
|
||||
```
|
||||
[](https://user-images.githubusercontent.com/13994516/67281056-e42b6400-f4ce-11e9-9f95-2a17b20db0c5.gif)
|
||||
|
||||
The number you enter is applied as a percentage of *balanceAssetA* or *balanceAssetB* (for BTC and USDT-based strategies respectively) to obtain the forward-testing balance that will be available to the *positionSize* formula you defined on the [Open Stage](#open-stage) of the strategy.
|
||||
|
||||
For instance, ```"balancePercentage": 1``` means that 1% of your balance will be made available.
|
||||
|
||||
Let's draw a quick example:
|
||||
|
||||
Your base asset is USDT and your *initialBalance* is USDT 10,000.
|
||||
|
||||
If you set up your forward-testing session with ```"balancePercentage": 1```, then USDT 10,000 * 1% = **USDT 100**. This is the balance that will be available to your forward-testing session.
|
||||
|
||||
> **NOTE:** You need to take this into account at the time of defining your *positionSize* formula. If the formula is a constant, you may easily run out of balance, as only a fraction of the balance will be available for the strategy to use. It may be a good idea to set up your *positionSize* as a function of your available balance instead.
|
||||
|
||||
Just like the balance is scaled down, the *minimumBalance* and *maximumBalance* are also scaled down accordingly.
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
title: Managing Processes
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-managing-processes.html
|
||||
---
|
||||
|
||||
| Task Manager | Task | Sensor Bot | Indicator Bot | Trading Bot | Process |
|
||||
| :---: | :---: | :---: | :---: | :---: | :---: |
|
||||
|  |  |  |  |  |  |
|
||||
|
||||
A *task manager* is an entity that controls any number of *tasks*, and tasks are used to control *bots*, which in turn may run any number of *processes*.
|
||||
|
||||
In other words, a task manager starts and stops tasks, and tasks are the devices you will use to start and stop bots.
|
||||
|
||||
Each task is an independent process at the *operating system* level, which handles its own memory allotment, and may be controlled and killed independently.
|
||||
|
||||
One task manager may have several tasks under its control, but each task should control only one bot instance.
|
||||
|
||||
Each bot may perform more than one job, thus, a bot instance may run one or more processes. Bots and processes are preconfigured so that you don't need to worry about their technical intricacies.
|
||||
|
||||
**All you need to do is the basic operation: starting and stopping them via the corresponding tasks whenever you need them.**
|
||||
|
||||
There currently are three kinds of bots that you will run to provide you with the data and functions you need:
|
||||
|
||||
* **Sensor Bots:** they extract raw data from external sources (*i.e.: exchanges, Twitter, etc.*);
|
||||
|
||||
* **Indicator Bots:** they process data to produce elaborate datasets;
|
||||
|
||||
* **Trading Bot:** based on datasets exposed as products by other bots (counting sensors, indicators and even other trading bots), a trading bot applies the trading logic defined on a trading system to, on one side, generate a complete trading simulation (outputting datasets that include trades, the action of strategies, validation of conditions, etc.), and on the other side, manages the execution of orders when on a live-trading session.
|
||||
|
||||
## Current Task Managers
|
||||
|
||||
All workspaces in the ```Quick-Start-Examples``` folder include the Superalgos Network, a network node representing your local machine, and four different task managers.
|
||||
|
||||
Each task manager has a name, which becomes visible only upon hovering the mouse pointer.
|
||||
|
||||
### Masters Datasets
|
||||
|
||||
Hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>D</kbd> (*D* for *Datasets*) to quickly find the *Masters Datasets* task manager, named after the *team* that created the bots in it.
|
||||
|
||||
This task manager has several tasks, each controlling one of the bot instances required to keep the datasets you downloaded with the data release up-to-date.
|
||||
|
||||
Having all data your strategy consumes up-to-date is a requirement for paper trading, forward testing, and live trading sessions. If you wish to have the data up-to-date, you need to *Start All Tasks* using the menu.
|
||||
|
||||
### Sparta Indicators
|
||||
|
||||
Hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>I</kbd> (*I* for *Indicators*) to quickly find the *Sparta Indicators* task manager. Again,Sparta is the name of the *team* that created this particular set of indicators.
|
||||
|
||||
If you wish to use these indicators in your strategies, please follow the guide about [Using indicators not included in the data release](Using-Indicators-Not-Included-in-the-Data-Release).
|
||||
|
||||
|
||||
### Testing Sessions
|
||||
|
||||
Hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>T</kbd> (*T* for *Testing*) to find the *Testing Sessions* task manager.
|
||||
|
||||
This is the task manager you will use to run the trading bot instances in charge of running both backtesting and paper-trading sessions.
|
||||
|
||||
### Live Sessions
|
||||
|
||||
Hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>T</kbd> (*L* for *Live trading*) to find the *Live Trading Sessions* task manager.
|
||||
|
||||
We keep the forward testing and live trading sessions separate from the backtesting and paper-trading sessions as there is money involved in the former. Keeping live sessions apart may help avoid unpleasant mistakes, turning on or off live sessions inadvertently.
|
||||
|
||||
> **PRO TIP:** The Getting Started guide instructed you to start all tasks on the *Masters Datasets* task manager, but only the required task to start a backtesting session on the *Testing Sessions* task manager. Once you become proficient with the platform, you may want to start only individual tasks according to your specific needs.
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: Market Data or Indicators Seem to be Outdated
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-market-data-indicators-seem-to-be-outdated.html
|
||||
---
|
||||
|
||||
If you are running the platform for the first time or you stopped running the platform for some time, data will not be up to date. Every time you start the platform, it will take some time for data to catch up with the present time.
|
||||
|
||||
To update your datasets until the present time you need to *Run All Tasks* in your *Masters Datasets* task manager, and allow enough time for the processes to go through the missing data.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67281294-5b60f800-f4cf-11e9-8f22-27655ec9e2a6.gif)
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: Multiple Live Trading Sessions
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-multiple-forward-testing-and-live-trading-sessions.html
|
||||
---
|
||||
|
||||
The platform allows running multiple forward testing and live trading sessions at the same time. This enables trading with multiple trading systems, from within the same instance of the platform.
|
||||
|
||||
The one thing you need to be aware of is that—due to restrictions on API use imposed by exchanges—you may not use the same exchange API key with different processes.
|
||||
|
||||
If you ever need to create a new trading session, you will create a copy of an existing one by cloning the whole task. Once you drop the clone back on the Designer, the new task will have all of the nodes required for trading, including an *exchange account key*.
|
||||
|
||||
Just make sure you don't use the same key on more than one session: you need to get a new API key from the exchange and edit the *exchange account key** accordingly.
|
||||
|
||||
> **NOTE:** If you don't specify which API Key to use at the session level, the platform's fallback mechanism will look for an API Key at the level of the parameters of the trading system. If more than one forward testing or live trading session ends up using the same API Key, you should expect errors to occur.
|
||||
|
||||
Also, make sure the new process instance is referencing Jason's Multi-Period process definition, and the actual session is referencing the definition you intend to run the session on. Follow the same procedure as you would for new testing sessions, as described in the [Advanced backtesting](Advanced-Backtesting) page.
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: My System Gets Slow
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-my-system-gets-slow.html
|
||||
---
|
||||
|
||||
Dynamically rendering all the visual features we use on the platform tends to put a significant load on the machine's processor. Depending on your machine's capacity, this may result in the system getting slow and sometimes even unresponsive.
|
||||
|
||||
If you experience such symptoms, there are several workarounds you may implement to mitigate them:
|
||||
|
||||
## Display Less Data on the Charts
|
||||
|
||||
If you are zooming out too far in the horizontal time scale with too many candles on the screen, try zooming-in a bit or changing time periods so that candle density decreases.
|
||||
|
||||
You may also want to switch off the layers you may not be using. Remember, every piece of graphical information you see on screen represents data your system is reading from your disk and processing to display in a visual environment.
|
||||
|
||||
## Close Unused Hierarchies
|
||||
|
||||
The physics that govern nodes in the Designer help the hierarchical structure of information to self-organize. This comes at a cost in terms of processing power.
|
||||
|
||||
Make sure the two exiting team hierarchies are closed:
|
||||
|
||||
* Hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>M</kbd> (*M* for *Masters*) to go the the Masters team hierarchy and click  if the hierarchy is open.
|
||||
|
||||
* Hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>S</kbd> (*S* for *Sparta*) to go the the Sparta team hierarchy and click  if the hierarchy is open.
|
||||
|
||||
* Hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>M</kbd> (*N* for *Network*) to go the the Network hierarchy and click  if the hierarchy is open.
|
||||
|
||||
You may also want to close any of the structure of nodes in your trading system that you may not be using.
|
||||
|
||||
## Freeze the Nodes You Need to Remain Visible
|
||||
|
||||
| Definition | Freeze |
|
||||
| :---: | :---: |
|
||||
|  |  |
|
||||
|
||||
You will find that freezing the nodes that you need to remain visible contributes to reducing the load in your CPU.
|
||||
|
||||
> **NOTE:** If these workarounds do not solve your problem and you often experience slowness or unresponsiveness when using your computer, you may want to consider upgrading your equipment. You shouldn't risk your capital with an insufficient trading infrastructure.
|
||||
@@ -0,0 +1,834 @@
|
||||
---
|
||||
title: Network Hierarchy
|
||||
summary: "Hover your mouse over a node for a quick definition, and click for the details."
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-network-hierarchy.html
|
||||
toc: false
|
||||
---
|
||||
|
||||
<table class='hierarchyTable'><thead><tr><th><a href='#network' data-toggle='tooltip' data-original-title='{{site.data.network.network}}'><img src='images/icons/network.png' /><br />Network</a></th><th></th><th></th><th></th><th></th><th></th><th></th><th></th><th></th></tr></thead><tbody>
|
||||
<tr><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#network-node' data-toggle='tooltip' data-original-title='{{site.data.network.network_node}}'><img src='images/icons/network-node.png' /><br />Network Node</a></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#task-manager' data-toggle='tooltip' data-original-title='{{site.data.network.task_manager}}'><img src='images/icons/task-manager.png' /><br />Task Manager</a></td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#task' data-toggle='tooltip' data-original-title='{{site.data.network.task}}'><img src='images/icons/task.png' /><br />Task</a></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#sensor-bot-instance' data-toggle='tooltip' data-original-title='{{site.data.network.sensor_bot_instance}}'><img src='images/icons/sensor-bot-instance.png' /><br />Sensor Bot Instance</a></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#sensor-process-instance' data-toggle='tooltip' data-original-title='{{site.data.network.sensor_process_instance}}'><img src='images/icons/sensor-process-instance.png' /><br />Sensor Process Instance</a></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#market-reference' data-toggle='tooltip' data-original-title='{{site.data.network.market_reference}}'><img src='images/icons/market-reference.png' /><br />Market Reference</a></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#key-instance' data-toggle='tooltip' data-original-title='{{site.data.trading_system.key_instance}}'><img src='images/icons/key-instance.png' /><br />Key Instance</a></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#indicator-bot-instance' data-toggle='tooltip' data-original-title='{{site.data.network.indicator_bot_instance}}'><img src='images/icons/indicator-bot-instance.png' /><br />Indicator Bot Instance</a></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#indicator-process-instance' data-toggle='tooltip' data-original-title='{{site.data.network.indicator_process_instance}}'><img src='images/icons/indicator-process-instance.png' /><br />Indicator Process Instance</a></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#market-reference' data-toggle='tooltip' data-original-title='{{site.data.network.market_reference}}'><img src='images/icons/market-reference.png' /><br />Market Reference</a></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#trading-bot-instance' data-toggle='tooltip' data-original-title='{{site.data.network.trading_bot_instance}}'><img src='images/icons/trading-bot-instance.png' /><br />Trading Bot Instance</a></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#trading-process-instance' data-toggle='tooltip' data-original-title='{{site.data.network.trading_process_instance}}'><img src='images/icons/trading-process-instance.png' /><br />Trading Process Instance</a></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td></td><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#market-reference' data-toggle='tooltip' data-original-title='{{site.data.network.market_reference}}'><img src='images/icons/market-reference.png' /><br />Market Reference</a></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td></td><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#key-instance' data-toggle='tooltip' data-original-title='{{site.data.trading_system.key_instance}}'><img src='images/icons/key-instance.png' /><br />Key Instance</a></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td></td><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#backtesting-session' data-toggle='tooltip' data-original-title='{{site.data.network.backtesting_session}}'><img src='images/icons/backtesting-session.png' /><br />Backtesting Session</a></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td></td><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#paper-trading-session' data-toggle='tooltip' data-original-title='{{site.data.network.paper_trading_session}}'><img src='images/icons/paper-trading-session.png' /><br />Paper Trading Session</a></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td></td><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#forward-testing-session' data-toggle='tooltip' data-original-title='{{site.data.network.forward_testing_session}}'><img src='images/icons/forward-testing-session.png' /><br />Forward Testing Session</a></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td></td><td></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#live-trading-session' data-toggle='tooltip' data-original-title='{{site.data.network.live_trading_session}}'><img src='images/icons/live-trading-session.png' /><br />Live Trading Session</a></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td></td><td></td><td></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#parameters' data-toggle='tooltip' data-original-title='{{site.data.trading_system.parameters}}'><img src='images/icons/parameters.png' /><br />Parameters</a></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td></td><td></td><td></td><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#base-asset' data-toggle='tooltip' data-original-title='{{site.data.trading_system.base_asset}}'><img src='images/icons/base-asset.png' /><br />Base Asset</a></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td></td><td></td><td></td><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#quoted-asset' data-toggle='tooltip' data-original-title='{{site.data.trading_system.quoted_asset}}'><img src='images/icons/quoted-asset.png' /><br />Quoted Asset</a></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td></td><td></td><td></td><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#time-range' data-toggle='tooltip' data-original-title='{{site.data.trading_system.time_range}}'><img src='images/icons/time-range.png' /><br />Time Range</a></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td></td><td></td><td></td><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#time-frame' data-toggle='tooltip' data-original-title='{{site.data.trading_system.time_frame}}'><img src='images/icons/time-frame.png' /><br />Time Frame</a></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td></td><td></td><td></td><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#slippage' data-toggle='tooltip' data-original-title='{{site.data.trading_system.slippage}}'><img src='images/icons/slippage.png' /><br />Slippage</a></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td></td><td></td><td></td><td></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#fee-structure' data-toggle='tooltip' data-original-title='{{site.data.trading_system.fee_structure}}'><img src='images/icons/fee-structure.png' /><br />Fee Structure</a></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#data-storage' data-toggle='tooltip' data-original-title='{{site.data.network.data_storage}}'><img src='images/icons/data-storage.png' /><br />Data Storage</a></td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#session-based-data' data-toggle='tooltip' data-original-title='{{site.data.network.session-based_data}}'><img src='images/icons/session-based-data.png' /><br />Session-based Data</a></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#session-reference' data-toggle='tooltip' data-original-title='{{site.data.network.session_reference}}'><img src='images/icons/session-reference.png' /><br />Session Reference</a></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#single-market-data' data-toggle='tooltip' data-original-title='{{site.data.network.single_market_data}}'><img src='images/icons/single-market-data.png' /><br />Single Market Data</a></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td></td><td><img src='images/icons/tree-connector-line.png' /></td><td></td><td></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#data-product' data-toggle='tooltip' data-original-title='{{site.data.network.data_product}}'><img src='images/icons/data-product.png' /><br />Data Product</a></td><td></td><td></td></tr>
|
||||
<tr><td></td><td></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#session-independent-data' data-toggle='tooltip' data-original-title='{{site.data.network.session-independent_data}}'><img src='images/icons/session-independent-data.png' /><br />Session-independent Data</a></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td></td><td></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#single-market-data' data-toggle='tooltip' data-original-title='{{site.data.network.single_market_data}}'><img src='images/icons/single-market-data.png' /><br />Single Market Data</a></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td></td><td></td><td></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#data-product' data-toggle='tooltip' data-original-title='{{site.data.network.data_product}}'><img src='images/icons/data-product.png' /><br />Data Product</a></td><td></td><td></td><td></td></tr></tbody></table>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Network
|
||||
|
||||
<img src='images/icons/150-network.png' />
|
||||
|
||||
**{{site.data.network.network}}**
|
||||
|
||||
You will use the network hierarchy for three main purposes:
|
||||
|
||||
* To control processes running sensor and indicator bots. These keep your data feeds up to date so that you may trade live.
|
||||
|
||||
* To control sessions.
|
||||
|
||||
* To set up which data products will be made available to your strategies, and for visualization purposes on the charts.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Network Node
|
||||
|
||||
<img src='images/icons/150-network-node.png' />
|
||||
|
||||
**{{site.data.network.network_node}}**
|
||||
|
||||
At the moment, processes run locally in a network node representing your computer. In the future, you will also be able to deploy other nodes, such as virtual machines in the cloud, and control execution in those remote computers from within your local instance of the system.
|
||||
|
||||
In a more distant future, you will also be able to connect to and consume services from other people’s nodes.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Task Manager
|
||||
|
||||
<img src='images/icons/150-task-manager.png' />
|
||||
|
||||
**{{site.data.network.task_manager}}**
|
||||
|
||||
A task manager facilitates the organization of tasks. For example, you may wish to set up a task manager to handle tasks related to a particular set of indicators you use with a certain strategy. Or, for example, to organize multiple backtesting sessions.
|
||||
|
||||
Also, a task manager allows starting and stopping all tasks under it at once, with a single click.
|
||||
|
||||
### Adding a Task Manager
|
||||
|
||||
To add a task manager, select *Add Task Manager* on the *My Computer* network node menu. A task manager is added along with a task.
|
||||
|
||||
### Starting / Stopping All Tasks
|
||||
|
||||
Select *Run All Tasks* or *Stop All Tasks* on the menu to start and stop all tasks respectively.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Task
|
||||
|
||||
<img src='images/icons/150-task.png' />
|
||||
|
||||
**{{site.data.network.task}}**
|
||||
|
||||
Each task may control a single bot. A bot instance running on its own task is independent from other bots at the operating system level, thus, may not be affected by errors ocurring on those other bots.
|
||||
|
||||
### Adding a Task
|
||||
|
||||
To add a task, select *Add Task* on the task manager node menu.
|
||||
|
||||
{% include tip.html content="Instead of adding nodes, configuring them, and setting references one by one, you may want to clone an existing, fully functional task with all its offspring." %}
|
||||
|
||||
### Starting / Stopping a Task
|
||||
|
||||
Select *Run* on the menu to start a task. When a task is started, the process instance of the bot instance attached to the task is started. Also, a visual indication that both the task and the process instance are running appear surrounding the corresponding nodes, in the form of a progress ring.
|
||||
|
||||
[IMAGE]
|
||||
|
||||
To stop a task, select *Stop* on the menu.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Sensor Bot Instance
|
||||
|
||||
<img src='images/icons/150-sensor-bot-instance.png' />
|
||||
|
||||
**{{site.data.network.sensor_bot_instance}}**
|
||||
|
||||
{{site.data.concepts.sensor_bot}}
|
||||
|
||||
The sensor bot instance holds no definitions as to what the bot does. Instead, its process instance references a process definition in the corresponding data mine. That is how the sensor bot instance obtains the information regarding what it needs to do once it is run.
|
||||
|
||||
### Adding a Sensor Bot Instance
|
||||
|
||||
To add a sensor bot instance, select *Add Sensor Bot Instance* on the task node menu. When a sensor bot instance is added, it is created with one sensor process instance, and a market reference.
|
||||
|
||||
### Starting / Stopping a Sensor Bot Instance
|
||||
|
||||
You do not start or stop a sensor bot instance directly. Instead, you start or stop the corresponding task.
|
||||
|
||||
### Configuring a Sensor Bot Instance
|
||||
|
||||
Select *Configure Sensor Bot Instance* on the menu to access the configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"startDate": "2020-01-01"
|
||||
}
|
||||
```
|
||||
|
||||
* ```startDate``` is the starting date of the data product the sensor bot instance builds. In other words, the sensor bot instance queries its data source for data starting on the configured ```startDate```. In cases when the sensor bot has built a data product starting on a certain date and the ```startDate``` is eventually changed for an earlier one, that is, a date further in the past, then the sensor bot discards the existing data product and starts over from the newly configured date.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Sensor Process Instance
|
||||
|
||||
<img src='images/icons/150-sensor-process-instance.png' />
|
||||
|
||||
**{{site.data.network.sensor_process_instance}}**
|
||||
|
||||
For example, in the case of an instance of the Masters data mine Charly sensor bot, the sensor bot process instance references the *Historic Trades* process definition. Once the reference is established, the sensor process instance adopts the name of the process definition it references.
|
||||
|
||||
### Adding a Sensor Process Instance
|
||||
|
||||
To add a sensor process instance, select *Add Sensor Process Instance* on the sensor bot instance node menu. When a sensor process instance is added, it is created with a market reference.
|
||||
|
||||
### Starting / Stopping a Sensor Process Instance
|
||||
|
||||
You do not start or stop a sensor process instance directly. Instead, you start or stop the corresponding task.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Indicator Bot Instance
|
||||
|
||||
<img src='images/icons/150-indicator-bot-instance.png' />
|
||||
|
||||
**{{site.data.network.indicator_bot_instance}}**
|
||||
|
||||
{{site.data.concepts.indicator_bot}}
|
||||
|
||||
The indicator bot instance holds no definitions as to what the bot does. Instead, its processes instances reference the process definitions in the corresponding data mine. That is how the indicator bot instance obtains the information of what it needs to do once it is run.
|
||||
|
||||
### Adding an Indicator Bot Instance
|
||||
|
||||
To add an indicator bot instance, select *Add Indicator Bot Instance* on the task node menu. When an indicator bot instance is added, it is created with one indicator process instance, and a market reference.
|
||||
|
||||
### Starting / Stopping an Indicator Bot Instance
|
||||
|
||||
You do not start or stop an indicator bot instance directly. Instead, you start or stop the corresponding task.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Indicator Process Instance
|
||||
|
||||
<img src='images/icons/150-indicator-process-instance.png' />
|
||||
|
||||
**{{site.data.network.indicator_process_instance}}**
|
||||
|
||||
Indicator bot instances usually require two indicator process instances. One of them references the indicator's *multi-period-market* process definition and the second references the *multi-period-daily* process definition.
|
||||
|
||||
Once the reference is established, the indicator process instance adopts the name of the process definition it references.
|
||||
|
||||
### Adding an Indicator Process Instance
|
||||
|
||||
To add an indicator process instance, select *Add Indicator Process Instance* on the indicator bot instance node menu. When an indicator process instance is added, it is created with a market reference.
|
||||
|
||||
### Starting / Stopping an Indicator Process Instance
|
||||
|
||||
You do not start or stop an indicator process instance directly. Instead, you start or stop the corresponding task.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Market Reference
|
||||
|
||||
<img src='images/icons/150-market-reference.png' />
|
||||
|
||||
**{{site.data.network.market_reference}}**
|
||||
|
||||
In other words, a market reference is the piece of information that let's the process instance know which market of which exchange it needs to process.
|
||||
|
||||
### Adding a Market Reference
|
||||
|
||||
To add a market reference, select *Add Market Reference* on the sensor, indicator or trading process instance node menu.
|
||||
|
||||
{% include note.html content="After adding a market reference node, make sure you establish the reference to the corresponding market of the corresponding exchange in the Crypto Ecosystem hierarchy." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Key Instance
|
||||
|
||||
<img src='images/icons/150-key-instance.png' />
|
||||
|
||||
**{{site.data.network.key_instance}}**
|
||||
|
||||
The key instance must be attached to market reference nodes that participate in forward testing and live trading sessions, as that is the scenario in which the user must validate the account with the exchange.
|
||||
|
||||
Some exchanges—like Binance—require validating the user even when retrieving data from the exchange. For such reasons, the key instance must also be attached to the market reference of the sensor process instance that connects to such exchanges.
|
||||
|
||||
In all cases, the key instance node must reference a valid exchange account key from an account with the exchange, as defined in the Crypto Ecosystem hierarchy.
|
||||
|
||||
{% include important.html content="Most exchanges do not allow the same exchange account key to be used with multiple processes querying the exchange API. This means that if you are trading with multiple trading systems or multiple sessions on the same exchange, each session requires different exchange account keys." %}
|
||||
|
||||
### Adding a Key Instance
|
||||
|
||||
To add a key instance, select *Add Key Instance* on the market reference node menu.
|
||||
|
||||
{% include note.html content="Remember to establish a reference with a valid exchange account key after creating the key instance." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Trading Bot Instance
|
||||
|
||||
<img src='images/icons/150-trading-bot-instance.png' />
|
||||
|
||||
**{{site.data.network.trading_bot_instance}}**
|
||||
|
||||
{{site.data.concepts.trading_bot}}
|
||||
|
||||
The trading bot instance holds no definitions as to what the bot does. Instead, its process instance references the process definition in the Masters data mine. That is how the indicator bot instance obtains the information of what it needs to do once it is run.
|
||||
|
||||
### Adding a Trading Bot Instance
|
||||
|
||||
To add a trading bot instance, select *Add Trading Bot Instance* on the task node menu. When a trading bot instance is added, it is created with one trading process instance, and a market reference.
|
||||
|
||||
### Starting / Stopping a Trading Bot Instance
|
||||
|
||||
You do not start or stop a trading bot instance directly. Instead, you start or stop the corresponding task.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Trading Process Instance
|
||||
|
||||
<img src='images/icons/150-trading-process-instance.png' />
|
||||
|
||||
**{{site.data.network.trading_process_instance}}**
|
||||
|
||||
The trading process instance must reference the *Multi-Period* process definition of the Jason trading bot in the Masters data mine.
|
||||
|
||||
### Adding a Trading Process Instance
|
||||
|
||||
To add a trading process instance, select *Add Trading Process Instance* on the trading bot instance node menu. When a trading process instance is added, it is created with a market reference.
|
||||
|
||||
{% include note.html content="After adding a trading process instance node, make sure you establish the reference to the *Multi-Period* process definition of the Jason trading bot in the Masters data mine." %}
|
||||
|
||||
### Starting / Stopping a Trading Process Instance
|
||||
|
||||
You do not start or stop a trading process instance directly. Instead, you start or stop the corresponding task.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Backtesting Session
|
||||
|
||||
<img src='images/icons/150-backtesting-session.png' />
|
||||
|
||||
**{{site.data.network.backtesting_session}}**
|
||||
|
||||
A backtesting session node must reference a trading system to gain access to the trading logic to be applied during the session. Other considerations framing the session come from the set of parameters attached to it.
|
||||
|
||||
### Adding a Backtesting Session
|
||||
|
||||
To add a backtesting session, select *Add Backtesting Session* on the trading process instance node menu. When a session is added, it is created with the full set of parameters.
|
||||
|
||||
{% include note.html content="After adding a session node, make sure you establish a reference to the trading system you want it to work with." %}
|
||||
|
||||
### Configuring a Backtesting Session
|
||||
|
||||
Select *Configure Session* on the menu to access the configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"folderName": "Session-Name"
|
||||
}
|
||||
```
|
||||
|
||||
* ```folderName``` allows you to set a significant name to the folder in which the data products—and logs—generated by the session are stored. If left blank, the system names the folders with the session id. This may be handy when you intend to consult the raw data generated by the session, as, otherwise, the folder would be hard to identify.
|
||||
|
||||
### Starting / Stopping a Backtesting Session
|
||||
|
||||
Before you start a backtesting session, the corresponding task needs to be running, as it is the task that puts the trading bot instance to run. Once the trading bot instance is running, select *Run* on the menu to start the session.
|
||||
|
||||
After a few seconds, a literal indication of the progress of the calculations appears below the session node, displaying the date that is currently being processed. Once the calculation is finished, the session stops and the date below the session node dissapears.
|
||||
|
||||
[IMAGE]
|
||||
|
||||
To stop a backtesting session, select *Stop* on the menu.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Paper Trading Session
|
||||
|
||||
<img src='images/icons/150-paper-trading-session.png' />
|
||||
|
||||
**{{site.data.network.paper_trading_session}}**
|
||||
|
||||
A paper trading session node must reference a trading system to gain access to the trading logic to be applied during the session. Other considerations framing the session come from the set of parameters attached to it.
|
||||
|
||||
### Adding a Paper Trading Session
|
||||
|
||||
To add a paper trading session, select *Add Paper Trading Session* on the trading process instance node menu. When a session is added, it is created with the full set of parameters.
|
||||
|
||||
{% include note.html content="After adding a session node, make sure you establish a reference to the trading system you want it to work with." %}
|
||||
|
||||
### Configuring a Paper Trading Session
|
||||
|
||||
Select *Configure Session* on the menu to access the configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"folderName": "Session-Name"
|
||||
}
|
||||
```
|
||||
|
||||
* ```folderName``` allows you to set a significant name to the folder in which the data products—and logs—generated by the session are stored. If left blank, the system names the folders with the session id. This may be handy when you intend to consult the raw data generated by the session, as, otherwise, the folder would be hard to identify.
|
||||
|
||||
### Starting / Stopping a Paper Trading Session
|
||||
|
||||
Before you start a paper trading session, the corresponding task needs to be running, as it is the task that puts the trading bot instance to run. Once the trading bot instance is running, select *Run* on the menu to start the session.
|
||||
|
||||
To stop a backtesting session, select *Stop* on the menu.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Forward Testing Session
|
||||
|
||||
<img src='images/icons/150-forward-testing-session.png' />
|
||||
|
||||
**{{site.data.network.forward_testing_session}}**
|
||||
|
||||
A forward testing session node must reference a trading system to gain access to the trading logic to be applied during the session. Other considerations framing the session come from the set of parameters attached to it.
|
||||
|
||||
### Adding a Forward Testing Session
|
||||
|
||||
To add a forward testing session, select *Add Forward Testing Session* on the trading process instance node menu. When a session is added, it is created with the full set of parameters.
|
||||
|
||||
{% include note.html content="After adding a session node, make sure you establish a reference to the trading system you want it to work with." %}
|
||||
|
||||
### Configuring a Forward Testing Session
|
||||
|
||||
Select *Configure Session* on the menu to access the configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"folderName": "Session-Name",
|
||||
"balancePercentage": 1
|
||||
}
|
||||
```
|
||||
|
||||
* ```folderName``` allows you to set a significant name to the folder in which the data products—and logs—generated by the session are stored. If left blank, the system names the folders with the session id. This may be handy when you intend to consult the raw data generated by the session, as, otherwise, the folder would be hard to identify.
|
||||
|
||||
* ```balancePercentage``` is a number defining the percentage of the initialBalance specified in the base aset configuration that will be used for trading. For instance, ```"balancePercentage": 1``` means that 1% of your balance will be made available. Just like the ```initialBalance``` is scaled down, the ```minimumBalance``` and ```maximumBalance``` are also scaled down accordingly (see base asset).
|
||||
|
||||
Let's draw a quick example:
|
||||
|
||||
Your base asset is USDT and your initialBalance is USDT 10,000.
|
||||
|
||||
If you set up your forward-testing session with "balancePercentage": "1", then USDT 10,000 * 1% = USDT 100. This is the balance that will be available to your forward-testing session.
|
||||
|
||||
{% include important.html content="You need to take this into account at the time of defining your positionSize formula. If the formula is a constant, you may easily run out of balance, as only a fraction of the balance will be available for the strategy to use. It may be a good idea to set up your positionSize as a function of your available balance instead." %}
|
||||
|
||||
### Starting / Stopping a Forward Testing Session
|
||||
|
||||
Before you start a forward testing session, the corresponding task needs to be running, as it is the task that puts the trading bot instance to run. Once the trading bot instance is running, select *Run* on the menu to start the session.
|
||||
|
||||
To stop a backtesting session, select *Stop* on the menu.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Live Trading Session
|
||||
|
||||
<img src='images/icons/150-live-trading-session.png' />
|
||||
|
||||
**{{site.data.network.live_trading_session}}**
|
||||
|
||||
A live trading session node must reference a trading system to gain access to the trading logic to be applied during the session. Other considerations framing the session come from the set of parameters attached to it.
|
||||
|
||||
### Adding a Live Trading Session
|
||||
|
||||
To add a live trading session, select *Add Live Trading Session* on the trading process instance node menu. When a session is added, it is created with the full set of parameters.
|
||||
|
||||
{% include note.html content="After adding a session node, make sure you establish a reference to the trading system you want it to work with." %}
|
||||
|
||||
### Configuring a Live Trading Session
|
||||
|
||||
Select *Configure Session* on the menu to access the configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"folderName": "Session-Name"
|
||||
}
|
||||
```
|
||||
|
||||
* ```folderName``` allows you to set a significant name to the folder in which the data products—and logs—generated by the session are stored. If left blank, the system names the folders with the session id. This may be handy when you intend to consult the raw data generated by the session, as, otherwise, the folder would be hard to identify.
|
||||
|
||||
### Starting / Stopping a Live Trading Session
|
||||
|
||||
Before you start a live trading session, the corresponding task needs to be running, as it is the task that puts the trading bot instance to run. Once the trading bot instance is running, select *Run* on the menu to start the session.
|
||||
|
||||
To stop a backtesting session, select *Stop* on the menu.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Parameters
|
||||
|
||||
<img src='images/icons/150-parameters.png' />
|
||||
|
||||
**{{site.data.trading_system.parameters}}**
|
||||
|
||||
Each testing session has its own set of parameters. This allows you to configure different trading sessions with different parameters, and go back and forth between them as required. For instance, you may have different backtesting sessions with different date ranges, different exchange fees or different slippage settings.
|
||||
|
||||
### Adding Parameters
|
||||
|
||||
To add a parameters node, select *Add Parameters* on the session or the trading system menu, depending on the context. When a parameters node is added, the full set of parameters are created with it.
|
||||
|
||||
If you already have a parameters node but are missing some of the parameters, then select *Add Missing Params* on the menu.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Base Asset
|
||||
|
||||
<img src='images/icons/150-base-asset.png' />
|
||||
|
||||
**{{site.data.trading_system.base_asset}}**
|
||||
|
||||
The basse asset must reference an asset in a specific market of a specific exchange in the Crypto Ecosystem hierarchy.
|
||||
|
||||
### Adding a Base Asset
|
||||
|
||||
To add a parameter that may be missing, select *Add Missing Params* on the parameters node menu.
|
||||
|
||||
{% include note.html content="After adding a base asset node, make sure you establish a reference to the asset in a specific market of a specific exchange in the Crypto Ecosystem hierarchy." %}
|
||||
|
||||
### Configuring the Base Asset
|
||||
|
||||
Select *Configure Base Asset* on the menu to access the configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"initialBalance": 0.001,
|
||||
"minimumBalance": 0.0001,
|
||||
"maximumBalance": 0.1
|
||||
}
|
||||
```
|
||||
|
||||
* ```initialBalance``` is the amount of capital you wish to allocate to the trading system.
|
||||
|
||||
* ```minimumBalance``` is the threshold of accummulated losses that switches off the session; when your overall balance (balanceAssetA + balanceAssetB) drops to this value, all trading stops; think of the ```minimumBalance``` as a general safety switch.
|
||||
|
||||
* ```maximumBalance``` is a similar concept as with the ```minimumBalance``` but on the high side of the ```initialBalance```.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Quoted Asset
|
||||
|
||||
<img src='images/icons/150-quoted-asset.png' />
|
||||
|
||||
**{{site.data.trading_system.quoted_asset}}**
|
||||
|
||||
The quoted asset must reference the second asset in the same market of the same exchange as the reference established with the base asset.
|
||||
|
||||
### Adding a Quoted Asset
|
||||
|
||||
To add a parameter that may be missing, select *Add Missing Params* on the parameters node menu.
|
||||
|
||||
{% include note.html content="After adding a quoted asset node, make sure you establish a reference to the second asset in the same market of the same exchange as the reference established with the base asset." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Time Range
|
||||
|
||||
<img src='images/icons/150-time-range.png' />
|
||||
|
||||
**{{site.data.trading_system.time_range}}**
|
||||
|
||||
### Adding a Time Range
|
||||
|
||||
To add a parameter that may be missing, select *Add Missing Params* on the parameters node menu.
|
||||
|
||||
### Configuring the Time Range
|
||||
|
||||
Select *Configure Time Range* on the menu to access the configuration. The configuration varies slightly depending on the type of session you are running.
|
||||
|
||||
#### On Backtesting Sessions
|
||||
|
||||
```json
|
||||
{
|
||||
"initialDatetime": "2019-09-01T00:00:00.000Z",
|
||||
"finalDatetime": "2019-09-25T00:00:00.000Z"
|
||||
}
|
||||
```
|
||||
|
||||
* ```initialDatetime``` is the datetime the session starts at. If you don't set an *initialDatetime* the system's fallback mechanism will try to get it from the parameters defined at the level of the trading system.
|
||||
|
||||
* ```finalDatetime``` is the datetime the session finishes at. If you don't set a *finalDatetime* at the level of the testing session or the trading system, then calculations will run until the date there is data available.
|
||||
|
||||
#### On Paper Trading, Forward Testing and Live Trading Sessions
|
||||
|
||||
These sessions always start at the datetime the session is run, therefore, there is no configuration of an initial datetime.
|
||||
|
||||
```json
|
||||
{
|
||||
"finalDatetime": "2019-09-25T00:00:00.000Z"
|
||||
}
|
||||
```
|
||||
|
||||
* ```finalDatetime``` is the datetime the session finishes at. If you don't set a *finalDatetime* at the level of the testing session or the trading system, then the session runs for one year.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Time Frame
|
||||
|
||||
<img src='images/icons/150-time-frame.png' />
|
||||
|
||||
**{{site.data.trading_system.time_frame}}**
|
||||
|
||||
In the context of backtesting sessions, what time frame you decide to run the session on depends on the strategies being tested. If strategies make decisions based on the 1 hour candle and above, then ```01-hs``` may be the best choice. However, if decisions are influenced by sub-hour candles then you should match the time frame accordingly.
|
||||
|
||||
In the context of live sessions, that is, paper trading, forward testing and live trading, you should run the session on the ```01-min``` time frame so that the trading bot reacts fast when the price tags the take profit or stop loss targets.
|
||||
|
||||
### Adding a Time Frame
|
||||
|
||||
To add a parameter that may be missing, select *Add Missing Params* on the parameters node menu.
|
||||
|
||||
### Configuring the Time Frame
|
||||
|
||||
Select *Configure Time Frame* on the menu to access the configuration.
|
||||
|
||||
```js
|
||||
{
|
||||
"value": "01-min"
|
||||
}
|
||||
```
|
||||
|
||||
* ```value``` is the setting for the time frame. You may use any of the values below.
|
||||
|
||||
Available options at the sub-hour level are:
|
||||
|
||||
```json
|
||||
01-min
|
||||
02-min
|
||||
03-min
|
||||
04-min
|
||||
05-min
|
||||
10-min
|
||||
15-min
|
||||
20-min
|
||||
30-min
|
||||
45-min
|
||||
```
|
||||
|
||||
Available options at larger time frames are:
|
||||
|
||||
```json
|
||||
01-hs
|
||||
02-hs
|
||||
03-hs
|
||||
04-hs
|
||||
06-hs
|
||||
08-hs
|
||||
12-hs
|
||||
24-hs
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Slippage
|
||||
|
||||
<img src='images/icons/150-slippage.png' />
|
||||
|
||||
**{{site.data.trading_system.slippage}}**
|
||||
|
||||
In the context of forward testing and live trading sessions, slippage does not affect the actual transactions. However, the parameter is taken into account when creating simulation layers, which are also available during forward testing and live trading.
|
||||
|
||||
Slippage is factored both in the session reports and in the graphic representation of each trade provided by the simulation trades product of the trading bot.
|
||||
|
||||
### Adding a Slippage
|
||||
|
||||
To add a parameter that may be missing, select *Add Missing Params* on the parameters node menu.
|
||||
|
||||
### Configuring the Slippage
|
||||
|
||||
Select *Configure Slippage* on the menu to access the configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"positionRate": 0.1,
|
||||
"stopLoss": 0.2,
|
||||
"takeProfit": 0.3
|
||||
}
|
||||
```
|
||||
|
||||
* ```positionRate``` is the slippage value to be applied to the rate of the take position order, expressed as a percentage (*i.e.:* 0.1 means 0.1%).
|
||||
|
||||
* ```stopLoss``` is the slippage value to be applied to the rate of the stop order, expressed as a percentage (*i.e.:* 0.2 means 0.2%).
|
||||
|
||||
* ```takeProfit``` is the slippage value to be applied to the rate of the take profit order, expressed as a percentage (*i.e.:* 0.3 means 0.3%).
|
||||
|
||||
The number you enter is applied as a percentage of the price of the order and added or subtracted from the price depending on the circumstances, always working against you. For instance, ```"positionRate": 0.1``` means the position will be set at a price 0.1% higher or lower depending on which of the assets in the pair is your base asset.
|
||||
|
||||
{% include note.html content="If the slippage parameter is left empty or detached both from your session and your trading system, slippage is not computed during simulations."%}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Fee Structure
|
||||
|
||||
<img src='images/icons/150-fee-structure.png' />
|
||||
|
||||
**{{site.data.trading_system.fee_structure}}**
|
||||
|
||||
Exchange fees are a crucial part of trading. A strategy may work like a charm when you leave fees out of the equation but would lead you to bankruptcy in a live trading situation.
|
||||
|
||||
Fee structures are factored both in the session reports and in the graphic representation of each trade provided by the simulation trades product of the trading bot.
|
||||
|
||||
To illustrate how fees affect your bottom line, take a look at the image below.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/63636432-8d8cdf80-c66f-11e9-86a3-480d157d8126.gif)
|
||||
|
||||
The trade hits the take profit target above the Position Rate level, however, due to fees, the trade has a negative 0.32% ROI.
|
||||
|
||||
In the context of forward testing and live trading sessions, the fee structure assumptions do not affect actual transactions. However, the parameter is taken into account when creating simulation layers, which are also available during forward testing and live trading.
|
||||
|
||||
### Adding a Fee Structure
|
||||
|
||||
To add a parameter that may be missing, select *Add Missing Params* on the parameters node menu.
|
||||
|
||||
### Configuring the Fee Structure
|
||||
|
||||
Select *Configure Fee Structure* on the menu to access the configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"maker": 0.15,
|
||||
"taker": 0.25
|
||||
}
|
||||
```
|
||||
|
||||
* ```maker``` is the setting for the fee the exchange charges when an order adds liquidity to the market, such as with limit orders.
|
||||
|
||||
* ```taker``` is the setting for the fee the exchange charges when an order takes liquidity from the market, such as with market or instant orders.
|
||||
|
||||
{% include note.html content="Check the fees structure in your exchange, carefully looking into the tier you fall in to feed accurate assumptions to your backtesting and paper trading sessions." %}
|
||||
|
||||
{% include note.html content="If the fee structure parameter is left empty or detached both from your session and your trading system, fees are not computed during simulations." %}
|
||||
|
||||
{% include important.html content="Remember that, for the time being, and until the new execution engine is released, all orders placed by the trading bot are *market orders*, thus, the *taker* fee applies in all cases." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Data Storage
|
||||
|
||||
<img src='images/icons/150-data-storage.png' />
|
||||
|
||||
**{{site.data.network.data_storage}}**
|
||||
|
||||
Data products generated by the bot instances you run need to be stored somewhere—specifically. The data storage node and its chain of offspring determine that the data is to be stored in the corresponding node.
|
||||
|
||||
{% include note.html content="At this point, the only node in which you may store data is your local *My Computer* node, however, in the future you will be able to store data, or even run bots, on remote machines that you will control from within your local deployment of the system." %}
|
||||
|
||||
### Adding a Data Storage
|
||||
|
||||
To add a data storage, select *Add Data Storage* on the network node menu.
|
||||
|
||||
{% include note.html content="Only one data storage may exist on each network node." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Session-based Data
|
||||
|
||||
<img src='images/icons/150-session-based-data.png' />
|
||||
|
||||
**{{site.data.network.session-based_data}}**
|
||||
|
||||
### Adding a Session-based Data Node
|
||||
|
||||
To add a session-based data node, select *Add Session-based Data* on the network node menu.
|
||||
|
||||
{% include note.html content="Only one session-based data node may exist on each data storage node." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Session Reference
|
||||
|
||||
<img src='images/icons/150-session-reference.png' />
|
||||
|
||||
**{{site.data.network.session_reference}}**
|
||||
|
||||
A such, the session reference node must establish a reference with a session. In addition, its offspring nodes determine precisely which data products are stored.
|
||||
|
||||
### Adding a Session-based Data Node
|
||||
|
||||
To add a session reference node, select *Add Session Reference* on the network node menu.
|
||||
|
||||
{% include note.html content="Remember to establish a reference with a session after adding the node." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Single Market Data
|
||||
|
||||
<img src='images/icons/150-single-market-data.png' />
|
||||
|
||||
**{{site.data.network.single_market_data}}**
|
||||
|
||||
The single market data node must establish a reference with a specific market defined in the Crypto Ecosystem hierarchy.
|
||||
|
||||
### Adding a Single Market Data Node
|
||||
|
||||
To add a single market data node, select *Add Single Market Data* on the network node menu.
|
||||
|
||||
{% include note.html content="Remember to establish a reference with a market defined in the Crypto Ecosystem hierarchy after adding the node." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Data Product
|
||||
|
||||
<img src='images/icons/150-data-product.png' />
|
||||
|
||||
**{{site.data.network.data_product}}**
|
||||
|
||||
A data product node must reference a product definition in the corresponding data mine.
|
||||
|
||||
### Adding a Data Product
|
||||
|
||||
To add a data product, select *Add Data Product* on the network node menu.
|
||||
|
||||
{% include note.html content="Remember to establish a reference with a product definition of the corresponding bot in the corresponding data mine." %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Session-independent Data
|
||||
|
||||
<img src='images/icons/150-session-independent-data.png' />
|
||||
|
||||
**{{site.data.network.session-independent_data}}**
|
||||
|
||||
### Adding a Session-independent Data Node
|
||||
|
||||
To add a session-independent data node, select *Add Session-independent Data* on the network node menu.
|
||||
|
||||
{% include note.html content="Only one session-independent data node may exist on each data storage node." %}
|
||||
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: Network Overview
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-network-overview.html
|
||||
---
|
||||
|
||||
| Network | Network Node |
|
||||
| :---: | :---: |
|
||||
|  |  |
|
||||
|
||||
The network hierarchy represents the Superalgos Network.
|
||||
|
||||
The hierarchy describes the physical location in which bots and their processes run, as well as the location in which data is stored.
|
||||
|
||||
It is through this hierarchy that you will control the instances of bots that run in your machine sourcing data from exchanges (sensor bots), processing data in the form of indicators (indicator bots), and running trading sessions (trading bot).
|
||||
|
||||
At the moment, the platform runs bots and their processes locally, in a *network node* representing your computer. In the future, you will also be able to deploy other nodes, such as virtual machines in the cloud, and control execution in those remote computers from within your local instance of the platform.
|
||||
|
||||
In a more distant future, you will also be able to connect and consume services from other people's nodes.
|
||||
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: On-Screen Errors and Warnings
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-on-screen-errors-and-warnings.html
|
||||
---
|
||||
|
||||
It may happen that your simulation or live trading is not working as expected. The first thing to do in such a case is to turn on the *Formulas & Conditions* layer of the corresponding session and look around within your workspace. Errors are signaled with a red circle surrounding the relevant node of the workspace. Hover the mouse pointer over the node and you should get a description of what is that is causing the unexpected behavior.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/63213696-b52ff500-c10f-11e9-9bc1-741ecb0858ef.gif)
|
||||
|
||||
Bear in mind that when the split tab is fully closed, errors will no longer show up in the Designer, as shown in the below video:
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/63213579-528a2980-c10e-11e9-8464-76cb4b369db4.gif)
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
title: Process Definition
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-process-definition.html
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
| Process Output | Process Dependencies | Status Report | Execution Started Event | Execution Finished Event |
|
||||
| :---: | :---: | :---: | :---: | :---: |
|
||||
|  |  |  |  |  |
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/68975616-06758080-07f4-11ea-8859-399c650aa733.png)
|
||||
|
||||
The two fundamental nodes of a process that need to be defined are the *process output* and the *process dependencies*. We will explore these two in detail.
|
||||
|
||||
You know from earlier explanations what a status report is. Status reports are handled internally by the bot and there isn't much more you need to know about them at this point. We will get back to status reports later on.
|
||||
|
||||
The *execution started event* and the *execution finished event* are too going to be described in detail.
|
||||
|
||||
## Process Output
|
||||
|
||||
| Output Dataset |
|
||||
| :---: |
|
||||
|  |
|
||||
|
||||
**The *process output* defines which datasets are impacted by the process. This definition is represented by the *output dataset* nodes under *process output* referencing the *dataset definition* of each of Paula's product.**
|
||||
|
||||
For the sake of clarity, let's expand on the above statement.
|
||||
|
||||
We stated earlier that Paula offeres four different products. Each of this products stores two datasets, one in the *market file* type of structure and one in the *daily file* type. These products are created by two processes: one of them creates the market file for each of the products, and the other one creates the daily files.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/68976798-f01cf400-07f6-11ea-9ffb-198b5853a220.gif)
|
||||
|
||||
The image above shows that relationship.
|
||||
|
||||
What we can see in the image above is the definition of the *process output* **of the Multi-Period-Market process**. Notice how the *process output* node has four offspring nodes named *output dataset*. One of the *output dataset* nodes **is referencing the Market** *dataset definition* of the Bollinger Channels *product definition*.
|
||||
|
||||
The rest of the *output dataset* nodes are linked to the corresponding Market *dataset definition* of the rest of Paula's products, which are out of the boundaries of the image.
|
||||
|
||||
Similarly, the *output dataset* nodes of the Multi-Period-Daily process are linked to the Daily *dataset definition* of each product. Feel free to go and check for yourself.
|
||||
|
||||
> **NOTE:** Notice how this link is represented by a faint grey dotted line, instead of an orange or yellow dotted line. As you already know, yellow (or orange) lines denote a hierarchical relationship between nodes. On the other hand, a grey dotted line represents a [reference](References)].
|
||||
|
||||
**The ultimate effect of establishing a reference from the *output dataset* to a product *dataset definition* is that—upon execution—every time the process finishes a processing cycle, it triggers an event that may be consumed by other entities. These events indicate that the corresponding datasets (the ones impacted by the process as per the *process output* definition) have been updated.**
|
||||
|
||||
An example of other entities that may be listening to such events is that of plotters. Plotters read datasets and create graphical representations of this data over the charts. You surely have noticed that the charts are constantly updating the information in form of candles and indicators in realtime, syncronized with the data being extracted from the exchange by Charly, the sensor bot. That kind of automatism is possible thanks to the events processes trigger every time an execution cycle is finished, signaling to everyone listening that new data is available on each of the impacted datasets.
|
||||
|
||||
## Process Dependencies
|
||||
|
||||
| Status Dependency |
|
||||
| :---: |
|
||||
|  |
|
||||
|
||||
**The definition of *status dependencies* tell us which other processes the process depends on.**
|
||||
|
||||
There are three kinds of status dependencies:
|
||||
|
||||
* **Self Reference** is mandatory, as a process will always need to read it's own status report every time it weaks up.
|
||||
|
||||
* **Market Starting Point** is a status dependency existing on Multi-Period-Daily processes (processes that store datasets in the *daily file* structure) so that the process knows the datetime of the start of the market. Usually, this will come from Charly's Hitoric-Trades process status report. Multi-Period-Market processes do not have this type of status dependency as the date of the start of the market is implied in their own dataset (a single file with all market data).
|
||||
|
||||
* **Market Ending Point** is a status dependency existing both in Multi-Period-Market and Multi-Period-Daily processes so that the process knows the datetime of the end of the market.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/68991956-dfa36280-0864-11ea-87ec-f0e4e3b7bf0f.gif)
|
||||
|
||||
The image above shows Paula's Multi-Period-Market process status dependencies. As explained above, both the ```Self Reference``` and ```Market Ending Point``` are present.
|
||||
|
||||
Paula builds different types of Bollinger Channels based on the Bollinger Bands created by Chris. That is why the Market Ending Point status dependency links to Chris' Multi-Period-Market status report. Paula needs to know up to what date Chris has updated its datasets so that she knows up to which date to process her own.
|
||||
|
||||
Bear in mind that all of these bots need to be autonomous and resilient. Figure that Chris may be manually stopped, it's data may be erased, or something else may happen that makes Chris fall behind. In such cases, if Paula finds that her data is up to date with Chris' or maybe even further ahead in datetime, she will not run until Chris catches up.
|
||||
|
||||
This means Paula will preserve her dataset so that other's may relie on it and use it independently of the fate of Chris' dataset.
|
||||
|
||||
| Data Dependency |
|
||||
| :---: |
|
||||
|  |
|
||||
|
||||
**The definition of *data dependencies* tell us which datasets the processes uses as input.**
|
||||
|
||||
The concept is quite straightforward. Paula depends on Chris' datasets as input to build her own.
|
||||
|
||||
In the image below, you will see Paula's Multi-Period-Market process *data dependecy* linking to Chris' Multi-Period-Market *dataset definition* of the Bollinger Bands product.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/68993034-7840df00-0873-11ea-804d-d24e88ce25f7.gif)
|
||||
|
||||
## Execution Started Event & Execution Finished Event
|
||||
|
||||
**The *execution started event* is the event that triggers the execution of a process. The *execution finished event* is the event that processes trigger once they have finished an execution cylce.**
|
||||
|
||||
You may think as the *execution finished event* as an event that is broadcasted to whoever wants to listen. It is the action of a process letting the world know it has finished its execution cycle.
|
||||
|
||||
This comes very handy for processes that need to wait for other processes to finish in order to start their own execution.
|
||||
|
||||
We have already established that Paula has a *data dependency* with Chris' datasets and that she reads Chris' status reports to know up to which datetime Chris has updated his datasets.
|
||||
|
||||
The one missing piece of information Paula requires is when she should run. By linking Paula's processes *execution started event* with Chris' processes *execution finished events* Paula knows exactly when to start her processes, right after Chris' have finished.
|
||||
|
||||
That link is what you can see in the below image.
|
||||
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/68993254-39605880-0876-11ea-9ee7-9f49976bd2dc.gif)
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: Quick Overview
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-quick-overview.html
|
||||
---
|
||||
|
||||
> **Start here:** Watch the [Superalgos Platform Quick Getting Started Guide](https://www.youtube.com/watch?v=_apiM49udL0) video for a quick intro. The video is slightly outdated in that the Superalgos Platform (the client version of the Platform) does not require a login and does not feature a menu on top. Otherwise, the content is still valid.
|
||||
|
||||
The first time you run the platform, you will see a screen split in half. The top half features the space used by the _Charts_ and the bottom half features the _Designer_.
|
||||
|
||||
Use the control in the center of the turquoise bar to pull the bar up and down to make more room for either application.
|
||||
|
||||
You may also use your keyboard as follows:
|
||||
|
||||
1. <kbd>Alt</kbd> + <kbd>↑</kbd> to close the Charts and open the Designer.
|
||||
1. <kbd>Alt</kbd> + <kbd>↓</kbd> to close the Designer and open the Charts.
|
||||
1. <kbd>Alt</kbd> + <kbd>→</kbd> to set the bar at the middle giving half of the screen to the Charts and the other half to the Designer.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67267448-9d2f7580-f4b2-11e9-8f5c-123f8b0f360b.gif)
|
||||
|
||||
> **TIP:** Pulling the bar to the very top of the screen causes the Charts to stop consuming resources in your machine, and gives you an ample view of the Designer.
|
||||
|
||||
**The Designer** is the place where you create. Think of the designer as your toolbox. This is where you will control every aspect of your data, your trading strategies and the overall behavior of the platform in general.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67267449-9d2f7580-f4b2-11e9-9ae8-1eb1355de07d.gif)
|
||||
|
||||
> **TIP:** Pulling the bar to the very bottom of the screen causes the Designer to stop consuming resources from your machine and offers a full-screen view of the Charts. The image above shows what you will see once you import your first *workspace* (you will learn about it in the next step).
|
||||
|
||||
**The Charts** show indicators data along with the actions taken by strategies, integrated with market data. This is the section of the platform in which you will see and analyze the result of your work.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67267949-a79e3f00-f4b3-11e9-9c0b-0c4aecf2d37d.gif)
|
||||
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "References"
|
||||
summary: "References enable nodes to acquire information and properties from other nodes."
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-references.html
|
||||
---
|
||||
|
||||
{{site.data.concepts.reference}}
|
||||
|
||||
As such, *references* have a *direction* property relative to each of the nodes involved in the reference: the node establishing the reference sets an *outgoing* reference, while the one accepting the reference sets an *incoming* reference.
|
||||
|
||||
For example, a session (testing or live) establishes an outgoing reference with a trading system. This allows the session to access the information within the whole trading system hierarchy, including strategies. At the trading system level, the same reference is viewed as an incoming reference.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/70355703-0e649580-1873-11ea-925e-1f0250148d2c.gif)
|
||||
|
||||
A reference established between nodes of any particular structure within a hierarchy is said to be an *internal* reference relative to the said structure of nodes. Similarly, a reference established with a node outside of the said structure, that is, in a different part of the hierarchy or in another hierarchy, is said to be an *external* reference.
|
||||
|
||||
Examples of internal references may be found in the Data Mine and Crypto Ecosystem hierarchies. For example, let's briefly look into one such case within a *plotter module*:
|
||||
|
||||
The capture below shows the *shapes* node and several offspring objects: on one hand, several *polygons*; on the other hand, the *chart points* node.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71106204-316e3e00-21bf-11ea-8ba0-df5fe9d0000e.gif)
|
||||
|
||||
Notice that *vertices* under each polygon reference to *points* under the *chart points* node.
|
||||
|
||||
This means that the node *shapes* feature several internal references.
|
||||
|
||||
The *backup*, *clone* and *share* operations described later in this section make different uses of the properties of references. We will cover the three of them extensively so that you may make the most of these features.
|
||||
|
||||
## Establishing and Removing References
|
||||
|
||||
To establish a reference, right-click on the first node and drag it close to the target node. Grey rings show which nodes you may establish a reference with. In case there are multiple nodes that would accept the reference, the one closer to the node where the reference originates will have its ring highlighted. Releasing the mouse button establishes the reference, or *links* both nodes.
|
||||
|
||||
{% include note.html content="The reference is visually represented by a faint grey dotted line. Such line is visible only when both ends of the reference are visible." %}
|
||||
|
||||
Throughout this documentation we may use the verb "*to link* interchangeably with *to establish a reference*, as synonyms.
|
||||
|
||||
To remove a reference or *delink* two nodes, simply right-click the node where the reference originates and make a dentle swipping motion away from the target node.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71175267-7057ce80-2267-11ea-8e97-4cffaa14b993.gif)
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: Reporting Bugs
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-reporting-bugs.html
|
||||
---
|
||||
|
||||
We highly appreciate bug reports. This is what you need to do:
|
||||
|
||||
**1.** Make sure you are running the latest release and that you have upgraded to the latest patch. You may find information about releases and patches on the [releases](https://github.com/Superalgos/Platform/releases) page. If you are not running the latest patch, please upgrade and test your issue again before reporting anything. We do not maintain of fix bugs on past versions.
|
||||
|
||||
**2.** Go to the [Issues](https://github.com/Superalgos/Platform/issues) page in this repository and take a moment to search for similar existing open issues. If you find one similar to yours, you may find helpful to follow the thread and may contribute by commenting and introducing new information about the issue.
|
||||
|
||||
**3.** If there are no similar issues, then open a new one. Do your best to describe the problem as thoroughly as possible.
|
||||
|
||||
**Developers will be interested in knowing how to reproduce the issue in their systems, so please describe the process that leads to the issue as clearly as possible. Capturing a GIF video showing the steps that lead to the issue would be of great help!**
|
||||
|
||||
[LICEcap](https://www.cockos.com/licecap/) is a lightweight, simple platform that can help you with that. If developers can reproduce the issue, half of the problem is solved already.
|
||||
|
||||
If the issue seems to happen under specific conditions, you might want to share your _Definitions_ with developers. To do this, go to the Definitions node in your workspace and select _Share_ in the menu. A file containing your strategy and other parameters, but NOT your API keys, will download to your browser's download folder. Upload this file to the issue only if you feel comfortable with sharing it openly. If not, then wait for developers to contact you.
|
||||
|
||||
Please make sure you enable Github notifications when someone responds to the issue, as developers may want to ask questions.
|
||||
|
||||
If the issue happens while using the platform at the browser, then please include a screen capture of Chrome's Console. Open DevTools with the F12 key (when the browser is in focus) and click the Console tab, then go back and reproduce the issue. Take a screen capture of the Console and paste it along with your report.
|
||||
|
||||
Feel free to also include screen captures of the platform itself if there is anything relevant you wish to show to developers.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/63112941-c18e4380-bf91-11e9-95e2-6fb064d5aead.png)
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: Run the Suite
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-run-the-suite.html
|
||||
---
|
||||
|
||||
## On Windows Systems
|
||||
|
||||
Use the executable file to run the platform:
|
||||
|
||||
Go to the ```Superalgos Platform``` folder and double click on ```Superalgos.exe```. Now, skip the *other systems* instructions and go directly to the title [What to Expect After Running the Platform](#what-to-expect-after-running-the-platform).
|
||||
|
||||
> **NOTE FOR DEVELOPERS:** Instead of using the executable file to run the platform, you may want to use ```node run``` from within the root ```Superalgos Platform``` folder, to run on your full Node Js installation.
|
||||
|
||||
## On All Systems (Mac OS, Linux, etc., and Windows too)
|
||||
|
||||
Download and install Node JS:
|
||||
|
||||
Node.js is an open-source server environment required for the platform to run. Go to the [Node Js downloads page](https://nodejs.org/en/download/) and download your system's installer (the *LTS Recommended for Most Users* version is enough). Run the installer and go through the process until Node Js is installed.
|
||||
|
||||
If you are on Mac, use the Finder platform to go to the ```Superalgos Platform``` folder and do a *secondary click* (tap the touchpad with two fingers) to open up the menu. Select *New Terminal Tab at Folder*. Once in the Terminal, type ```node run``` and hit *Enter*.
|
||||
|
||||
If you are on Linux, open a Terminal / Console, go to the ```Superalgos Platform``` folder, type ```node run``` and hit *Enter*.
|
||||
|
||||
## What to Expect After Running the Platform
|
||||
|
||||
This is what you should see in your console after running the ```node run``` command or double-clicking your executable:
|
||||
|
||||
|
||||
|
||||
Also, your browser should load the platform and show the following screen:
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67231207-2907ba00-f43f-11e9-83e8-e36cc844b0eb.gif)
|
||||
|
||||
The platform will load on your default browser. You should either [set Chrome as your default browser](https://support.google.com/chrome/answer/95417?co=GENIE.Platform%3DDesktop&hl=en) before executing the file or simply close the non-Chrome browser, open Chrome and go to http://localhost:9999/.
|
||||
|
||||
> **NOTE:** We highly recommend you use Chrome to run the platform so that you have a similar environment as developers in case you need help. We are not testing on any other browsers and it is a well-known fact that browsers do behave differently.
|
||||
|
||||
If you ran the *.exe* file on Windows, a Console/Command Line/Terminal window will open. If you ran the platform from within the console, the programs will run on the same console window.
|
||||
|
||||
The Console must be open for as long as the platform is running. Do not close the window or stop the processes running on it. You may minimize the Console if your Operating System allows you to do so.
|
||||
|
||||
> **NOTE:** Closing the Console/Command Line may cause your market data to become corrupt. The proper way of closing the application is closing your browser first, and allow a minute for processes to stop before closing the Console.
|
||||
|
||||
That's it! You are up and running!
|
||||
|
||||
Now you are ready to learn the basic operation of the platform so that you may run your first backtests or trade live with existing strategies.
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
title: Run Your First Backtest
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-run-your-first-backtest.html
|
||||
---
|
||||
|
||||
To run your first backtest you will need a functional strategy.
|
||||
|
||||
## Available Quick-Start Examples
|
||||
|
||||
* **```Share - Workspace - Combined Bull-run rider and Weak-hands buster.json```** features the [*Bull-run Rider*](https://github.com/Superalgos/Strategy-USDT-BullRunRider) strategy (USDT) and the [*Weak-hands Buster*](https://github.com/Superalgos/Strategy-BTC-WeakHandsBuster) strategy (BTC), combined on a single workspace. Use this template if you wish to use or learn about either or both of these strategies. You may delete the one you don't need if that is the case.
|
||||
|
||||
* **```Share - Workspace - Empty Strategy Structure.json```** features a template containing the minimum set of structure of nodes required to build your own strategy. Nodes are empty (undefined). This structure will guide you through the process of building your strategy. You will not be able to run a backtest or trade live with this template until you set up your own strategy.
|
||||
|
||||
## Import a Workspace
|
||||
|
||||
Go to the ```Superalgos Platform/Quick-Start-Examples``` folder, drag ```Share - Workspace - Combined Bull-run rider and Weak-hands buster.json``` and drop it on the _Designer_ to start with a workspace with functioning strategies.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67231208-2907ba00-f43f-11e9-82b4-d78c0ace4d0a.gif)
|
||||
|
||||
## Run Your First Backtest
|
||||
|
||||
| Task Manager | Task | Trading Bot | Process | Backtesting Session |
|
||||
| :---: | :---: | :---: | :---: | :---: |
|
||||
| |  |  |  |  |
|
||||
|
||||
Once on the Designer, hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>T</kbd> (*T* for *Testing*). This shortcut will take you to the *Network* hierachy of the Designer, where you will start the process to run a backtesting session. More precisely, it takes you to *Testing Sessions*, the *task manager* that controls testing sessions.
|
||||
|
||||
Look around the task manager by clicking and dragging the black background of the Designer. You may also use the following keyboard key combinations to move around:
|
||||
|
||||
1. <kbd>Ctrl or ⌘</kbd> + <kbd>←</kbd> to pan to the left.
|
||||
1. <kbd>Ctrl or ⌘</kbd> + <kbd>→</kbd> to pan to the right.
|
||||
1. <kbd>Ctrl or ⌘</kbd> + <kbd>↑</kbd> to pan upwards.
|
||||
1. <kbd>Ctrl or ⌘</kbd> + <kbd>↓</kbd> to pan downwards.
|
||||
|
||||
Notice how each *task* is followed by an instance of the *trading bot*, an instance of the trading bot *process*, and a *session*.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/70341072-650da780-1852-11ea-9940-60bd619ac266.gif)
|
||||
|
||||
|
||||
Locate either of the backtesting sessions named *Back HWB* or *Back BRR*. To run a session, you first need to run the corresponding task. To do this, hover the mouse over the task that controls the backtesting session and click *Run* on the menu, then go to the backtesting session and click *Run* on the menu as well.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/70341073-650da780-1852-11ea-80ac-f879be1d559e.gif)
|
||||
|
||||
|
||||
You just started a backtesting session with a series of pre-configured parameters, including, for instance, the date range on which the backtesting session runs. Later on, you will learn how to adjust these parameters (if you can't wait, click  on the backtesting session menu and you will find the parameters of the particular session).
|
||||
|
||||
Notice the date progress notification displayed below the backtesting session node. The session is configured to run starting on January 1st, 2019. It will run up to the latest date of your current datasets, or up to the present time if your datasets are up-to-date.
|
||||
|
||||
It may take anything between 2 to 10 minutes (depending on your machine's processing power) to finish. You can tell the process finished calculating the backtesting session once the progress date stops, and—eventually—disappears.
|
||||
|
||||
To see the backtest simulation on the charts, you first need to make sure that the *Layers Manager* for the corresponding session is visible in the Designer. This is what enables the corresponding simulation layers on the Layers Panel.
|
||||
|
||||
To do that, go back to the backtesting session and click  on the left-hand side.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/70341075-65a63e00-1852-11ea-9ae4-3b58a26b3c8c.gif)
|
||||
|
||||
Then, you may pull down the horizontal bar to go to the charts and see the simulation. Make sure you are standing on the 1-hour time period. Notice the time box at the bottom of the charts:
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67237146-fc599f80-f44a-11e9-8da4-c95fc6295d52.gif)
|
||||
|
||||
If you are not at the 1-hour time period use the wheel of your mouse while pointing at the charts to zoom in until you reach the 1-hour time period. You do this so that you may see the results of the backtesting session, which in the case of the example strategies, are calculated and plotted over the 1-hour charts.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67237088-d7fdc300-f44a-11e9-8ae5-d3fd394ffc22.gif)
|
||||
|
||||
Now go the *Layers Panel* on the left-hand side of the screen and use the wheel of your mouse to scroll down until you find the layers starting with *Back BRR* or *Back WHB*, depending on your previous choice of strategy. Turn each of the layers on with a single click.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67237090-d8965980-f44a-11e9-86ba-3eb1e6980ae2.gif)
|
||||
|
||||
You may now navigate the charts by clicking and dragging, or by zooming in and out with the wheel of your mouse. If you change the time period, you will not see the simulated data, as each time period may hold its own set of simulations.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67237276-3e82e100-f44b-11e9-977f-a02da0857b38.gif)
|
||||
|
||||
Congratulations! You've run your first backtesting session!
|
||||
|
||||
To learn more about how to interpret the information in the simulations, please refer to the [Simulation layers](Simulation-Layers) page on this User Manual.
|
||||
@@ -0,0 +1,150 @@
|
||||
---
|
||||
title: Session Parameters
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-session-parameters.html
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
| Parameters |
|
||||
| :---: |
|
||||
|  |
|
||||
|
||||
Each testing session has its own set of parameters. This allows you to configure different trading sessions with different parameters, and go back and forth between them as required. For instance, you may have different backtesting sessions with different date ranges, different exchange fees or different slippage settings.
|
||||
|
||||
> **NOTE:** If any of these parameters are missing from the configuration of the testing session, the platform's fallback mechanism will look for the parameters at the trading system level and use those settings instead.
|
||||
|
||||
We covered the *Base Asset* parameter when explaining trading systems. Let's now review the rest.
|
||||
|
||||
## Exchange Fees
|
||||
|
||||
Fees are a crucial part of the game. A strategy may work like a charm when you leave fees out of the equation but would lead you to bankruptcy in a live trading situation.
|
||||
|
||||
Simulations take fees into account when the following piece of code is present and properly configured in your *Fee Structure* parameter:
|
||||
|
||||
| Fee Structure |
|
||||
| :---: |
|
||||
|  |
|
||||
|
||||
```js
|
||||
{
|
||||
"maker": 0.15,
|
||||
"taker": 0.25
|
||||
}
|
||||
```
|
||||
|
||||
The above configuration corresponds to standard Poloniex maker and taker fees. Remember, for the time being, [all orders placed by the trading bot are *market orders*](execution-limitations), thus, the *taker* fee applies in all cases.
|
||||
|
||||
To illustrate how fees affect your bottom line, take a look at the image below.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/63636432-8d8cdf80-c66f-11e9-86a3-480d157d8126.gif)
|
||||
|
||||
The trade hits the take profit target above the Position Rate level, however, due to fees, the trade has a negative 0.32% ROI.
|
||||
|
||||
> **NOTE:** If the *Fee Structure* parameter is left empty or detached both from your testing session and your Trading System, fees will not be computed during simulations.
|
||||
|
||||
## Slippage
|
||||
|
||||
[Slippage](https://en.wikipedia.org/wiki/Slippage_(finance)) is another issue you need to be aware of to more realistically evaluate a strategy. The price at which the exchange will fill the order placed by the trading bot is seldom going to match the conditions of the simulation.
|
||||
|
||||
To account for slippage during simulations, you may enter slippage values for the three different occasions in which the trading bot will place orders: Take Position, Take Profit and Stop.
|
||||
|
||||
| Slippage |
|
||||
| :---: |
|
||||
|  |
|
||||
|
||||
Simulations take *slippage* into account when the following piece of code is present and properly configured in your *Slippage* parameter:
|
||||
|
||||
```js
|
||||
{
|
||||
"positionRate": 0.1,
|
||||
"stopLoss": 0.2,
|
||||
"takeProfit": 0.3
|
||||
}
|
||||
```
|
||||
|
||||
The number you enter is applied as a percentage of the price of the order and added or subtracted from the price depending on the circumstances, always working against you. For instance, ```"positionRate": 0.1``` means the position will be set at a price 0.1% higher if you stand on USDT or lower if you stand in BTC.
|
||||
|
||||
The result of slippage in simulations is taken into account by the graphic representation of each trade created by the Simulation Trades layer.
|
||||
|
||||
> **NOTE:** If the *Slippage* parameter is left empty or detached both from your testing session and your Trading System, slippage will not be computed during simulations.
|
||||
|
||||
## Datetime Range
|
||||
|
||||
| Datetime Range |
|
||||
| :---: |
|
||||
|  |
|
||||
|
||||
The Datetime Range parameter is used to control the period of time in which the simulation will be calculated.
|
||||
|
||||
**1. Backtesting**:
|
||||
|
||||
You will set an *initialDatetime* and a *finalDatetime*:
|
||||
|
||||
```js
|
||||
{
|
||||
"initialDatetime": "2019-09-01T00:00:00.000Z",
|
||||
"finalDatetime": "2019-09-25T00:00:00.000Z"
|
||||
}
|
||||
```
|
||||
|
||||
If you do not set an *initialDatetime* the platform's fallback mechanism will try to get it from the parameters at the level of the trading system. In case there is no *initialDatetime*, the calculation will start at the current position of the charts.
|
||||
|
||||
If you don't set a *finalDatetime* at the level of the testing session or the trading system, then calculations will run until the present time.
|
||||
|
||||
**2. Paper-trading**:
|
||||
|
||||
Paper trading sessions only require a *finalDatetime*. If you do not set one either at the level of the session or the trading system then the session will run for one year.
|
||||
|
||||
```js
|
||||
{
|
||||
"finalDatetime": "2020-09-25T00:00:00.000Z"
|
||||
}
|
||||
```
|
||||
|
||||
## Time Period
|
||||
|
||||
| Time Period |
|
||||
| :---: |
|
||||
|  |
|
||||
|
||||
Testing sessions run in the time period specified in this parameter.
|
||||
|
||||
```js
|
||||
{
|
||||
"value": "01-min"
|
||||
}
|
||||
```
|
||||
|
||||
Available options at the sub-hour level are:
|
||||
|
||||
```
|
||||
01-min
|
||||
02-min
|
||||
03-min
|
||||
04-min
|
||||
05-min
|
||||
10-min
|
||||
15-min
|
||||
20-min
|
||||
30-min
|
||||
45-min
|
||||
```
|
||||
|
||||
Available options at larger time periods are:
|
||||
|
||||
```
|
||||
01-hs
|
||||
02-hs
|
||||
03-hs
|
||||
04-hs
|
||||
06-hs
|
||||
08-hs
|
||||
12-hs
|
||||
24-hs
|
||||
```
|
||||
|
||||
In the context of backtesting sessions, what time period you decide to run the session on depends on the strategies being tested. If strategies make decisions based on the 1 hour candle and above, then ```01-hs``` may be the best choice. However, if decisions are influenced by sub-hour candles then you should match the time periods accordingly.
|
||||
|
||||
>**NOTE:** In the context of live sessions, that is, paper trading, forward testing and live trading, you should run the session on the ```01-min``` time period so that the trading bot reacts fast when the price tags the take profit or stop loss targets.
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: Shares
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-shares.html
|
||||
---
|
||||
|
||||
The share feature works almost the same as the back up feature, with the sole difference that shares *do not* store personal information, like exchange API keys.
|
||||
|
||||
On that note, we will not analyze this feature further, other than reminding the user that it is recommended to develop the habit to only share *shares* and not *backups*, to avoid the potential accidental dissemination of exchange keys.
|
||||
|
||||
On a different note, it is also critical to bring one more issue to your attention regarding sharing work and—what's more more important— using other people's work.
|
||||
|
||||
You may have noticed that the platform accepts JavaScript code in a multitude of input forms such as configurations, conditions, formulas and more. At this point, there is no restriction to the code that may be used. This is a design feature, as we wish advanced users to be able to use their programing skills to make the most out of the platform.
|
||||
|
||||
However, this also means that using workspaces or any other data structure coming from untrusted sources is not free of risks. On the contrary, it may be a high-risk choice, as it is not overly complex to introduce malicious code that may, for example, attempt to steal people's API keys.
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: Simulation Layers
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-simulation-layers.html
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
| Layers Manager |
|
||||
| :---: |
|
||||
|  |
|
||||
|
||||
The layers manager allows you to determine which visualization layers will be available at the Layers Panel to plot the results of testing sessions over the charts.
|
||||
|
||||
The layers manager and its offspring nodes must be visible in the Designer
|
||||
|
||||
Back on the charts, the following layers plot strategies' actions over the market data, providing a comprehensive set of visual clues showing how strategies would behave when trading.
|
||||
|
||||
> **NOTE:** The examples below illustrate the [*Weak-hands Buster*](https://github.com/Superalgos/Strategy-BTC-WeakHandsBuster) strategy, designed to sell BTC as prices start dropping and re-buy BTC as prices stabilize at a lower level.
|
||||
|
||||
## Simulation
|
||||
|
||||
The *Simulation* layer displays the actions of strategies throughout the tested period. Actions include the *take position event* and the management of *stop* and *take profit* in phases. By activating the Simulation layer you should be able to see something like this:
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67279788-040d5880-f4cc-11e9-9098-11496fac9c79.gif)
|
||||
|
||||
Notice Asset Balances in the bottom left corner of the screen. Asset A represents BTC while Asset B represents USDT.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67279789-040d5880-f4cc-11e9-9124-9076273e6dfd.gif)
|
||||
|
||||
> **NOTE:** For the time being, asset balances displayed on-screen correspond to the Simulation layer that was turned on last.
|
||||
|
||||
The dashed line represents the duration of the trade at the price of the _take position_ event. Notice how one asset is exchanged for the other asset at the take position event, and exchanged back as the trade closes.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67279791-040d5880-f4cc-11e9-9cac-db42c419ca0c.gif)
|
||||
|
||||
Notice the green horizontal lines indicating the _take profit_ value for each period (candle). _Take profit_ is managed in _phases_, marked with the corresponding icons.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67279792-040d5880-f4cc-11e9-8487-cf390d78da92.gif)
|
||||
|
||||
Notice the red horizontal lines indicating the _stop_ value for each period (candle). *Stop* is managed in _phases_ marked with the corresponding icons.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67279793-04a5ef00-f4cc-11e9-8ac1-32e98762bf5b.gif)
|
||||
|
||||
## Formulas and Conditions
|
||||
|
||||
The *Formulas and Conditions* layer helps identify which conditions are met at each candle. Notice how conditions are highlighted as the mouse pointer moves through different candles.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67279794-04a5ef00-f4cc-11e9-9c53-cf5694701b50.gif)
|
||||
|
||||
It also allows to track the value of each formula, for instance, those used to dynamically manage take profit in phases.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67279796-053e8580-f4cc-11e9-8688-4fea62c1f40b.gif)
|
||||
|
||||
## Strategies
|
||||
|
||||
The *Strategies* layer identifies trigger on and trigger off events, signaling the activation and deactivation of strategies.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67280186-dd035680-f4cc-11e9-82e8-e52706749f5a.gif)
|
||||
|
||||
## Trades
|
||||
|
||||
The *Trades* layer marks trades with a triangle whose hypotenuse connects the price at the _take position_ event with the _exit_ price. When the trade is profitable, the triangle is green; when the _exit_ happens at a loss, the triangle is red.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67280187-dd9bed00-f4cc-11e9-93be-74b497d8f7b5.gif)
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
title: Syntax Overview
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-sysntax-overview.html
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
Different bots running within the platform produce data products that others may consume. These products are available for you to use within your strategies.
|
||||
|
||||
Datasets are stored as a collection of sequential records and you may access any of the properties (fields) of each record.
|
||||
|
||||
To do that, you will use the following syntax: ```.productName``` + ```.propertyName```.
|
||||
|
||||
The above syntax returns the value of the property of the declared product at the latest closed candle. This is common throughout all available datasets.
|
||||
|
||||
## Specifying the Time Period
|
||||
|
||||
When building conditions and formulas, you may want to use analysis concerning different time periods. This is perfectly possible.
|
||||
|
||||
The variables explained further down this section, written as described for each indicator, are not valid unless they are preceeded by the declaration of the time period they refer to.
|
||||
|
||||
To do that, you need to preceed the above syntax with the following:
|
||||
|
||||
```chart.at``` + ```timeperiod```
|
||||
|
||||
Therefore, the complete syntax to build a valid statement is:
|
||||
|
||||
```chart.at``` + ```timeperiod``` + ```.productName``` + ```.propertyName```
|
||||
|
||||
For example:
|
||||
|
||||
```chart.at04hs.candle.close > chart.at04hs.candle.previous.close```
|
||||
|
||||
The above statement compares the current 4 hours candle to the previous 4 hours candle.
|
||||
|
||||
The complete list of time periods available is:
|
||||
|
||||
| Time Period | Syntax |
|
||||
| :---: | :---: |
|
||||
| 1 min | ```chart.at01min``` |
|
||||
| 2 min | ```chart.at02min``` |
|
||||
| 3 min | ```chart.at03min``` |
|
||||
| 4 min | ```chart.at04min``` |
|
||||
| 5 min | ```chart.at05min``` |
|
||||
| 10 min | ```chart.at10min``` |
|
||||
| 15 min | ```chart.at15min``` |
|
||||
| 20 min | ```chart.at20min``` |
|
||||
| 30 min | ```chart.at30min``` |
|
||||
| 40 min | ```chart.at40min``` |
|
||||
| 45 min | ```chart.at45min``` |
|
||||
| 1 h | ```chart.at01hs``` |
|
||||
| 2 hs | ```chart.at02hs``` |
|
||||
| 3 hs | ```chart.at03hs``` |
|
||||
| 4 hs | ```chart.at04hs``` |
|
||||
| 6 hs | ```chart.at06hs``` |
|
||||
| 8 hs | ```chart.at08hs``` |
|
||||
| 12 hs | ```chart.at12hs``` |
|
||||
| 24 hs | ```chart.at24hs``` |
|
||||
|
||||
> **NOTE:** For brevity's sake, when discussing indicators further down this document, the declaration of the time period may sometimes be ommited. However, do remember the statement is only valid with the proper declaration of the time period.
|
||||
|
||||
## Previous Property
|
||||
|
||||
The ```previous``` property is a property common to all products that allows you to retrieve the value of the candle that closed previous to the last one.
|
||||
|
||||
The property is used with the following syntax: ```chart.at``` + ```timeperiod``` + ```.productName``` + ```.previous``` + ```.propertyName```. You may use the property on any of the indicators in a similar way.
|
||||
|
||||
In addition, you may use the ```previous``` property more than once, to retrieve values further in the past: ```chart.at``` + ```timeperiod``` + ```.productName``` + ```.previous.previous... ...previous``` + ```.propertyName```
|
||||
|
||||
For example, ```chart.at1hs.candle.previous.previous.max``` returns the maximum value of two candles before the last closed candle at the 1-hour chart.
|
||||
|
||||
## Alternative to the Previous Property
|
||||
|
||||
There is a cool alternative to the *previous* property, that you can use to fetch the value of a property beyond the last closed candle.
|
||||
|
||||
The syntax is ```productName.[currentCandleIndex-n].propertyName``` where *currentCandleIndex* represents the last closed candle and *n* may be replaced by any integer number.
|
||||
|
||||
For example, ```chart.at1hs.candle.[currentCandleIndex-5].max``` retrieves the maximum value of the fifth candle previous to the last closed candle at the 1-hour chart.
|
||||
|
||||
> **NOTE:** There is a technical limitation by which you may retrieve the value of a property up to a maximum of 24 hours in the past, whatever number of periods that may represent, depending on the time period you may be working on. For instance, if you are working on the 1 hour time period, you may fetch up to 23 candles before the last one. If you are working on the 1 minute time period, you may retrieve 1439 candles.
|
||||
|
||||
## Comparison and Logical Operators
|
||||
|
||||
To define _conditions_ you will use _statements_ using the syntax described above. You will use the properties of indicators that will be introduced later on. The data behind those indicators describe what is happening with the market.
|
||||
|
||||
Remember, _conditions_ need to evaluate either _true_ or _false_.
|
||||
|
||||
To create such statements you will use comparison and logical operators:
|
||||
|
||||
| Operator | Description |
|
||||
| :---: | --- |
|
||||
| === | equal value and equal type |
|
||||
| != | not equal |
|
||||
| > | greater than |
|
||||
| < | less than |
|
||||
| >= | greater than or equal to |
|
||||
| <= | less than or equal to |
|
||||
| && | and |
|
||||
| ∣∣ | or |
|
||||
|
||||
**For example:**
|
||||
|
||||
**Situation 1**
|
||||
|
||||
* Condition A: ```chart.at01hs.candle.close > chart.at01hs.bollingerBand.MovingAverage``` (the latest candle at the 1 hour chart closed above the Bollinger Bands moving average).
|
||||
|
||||
* Condition B: ```chart.at01hs.candle.previous.max > chart.at01hs.bollingerBand.previous.MovingAverage``` (the maximum value of the candle before the last one, was higher than the Bollinger Bands moving average)
|
||||
|
||||
In the example above, conditions A and B are comparison statements that may evaluate either _true_ or _false_. In the case both would evaluate _true_ then Situation 1 would be true as well.
|
||||
|
||||
**Situation 2**
|
||||
|
||||
* Condition C: ```chart.at04hs.candle.max <= 10000 && chart.at04hs.candle.min >= 9000``` (the entire candle at the 4 hours chart fits within the price range between 9000 and 10000)
|
||||
|
||||
In the example above, _condition C_ would be _true_ if the whole 4-hour candle falls within the range between 9000 and 10000. If this is _true_, then _situation 2_ is true as well, as there is only one condition to check.
|
||||
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: System Requirements
|
||||
summary: "The Superalgos Suite is a robust, cross-platform, browser-based system. It's capacity to run indefinite numbers of processes means that your hardware will set the limits of what you may or may not do with it."
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-system-requirements.html
|
||||
---
|
||||
|
||||
The Superalgos Platform is a web app, therefore, it is cross-platform. The team is testing mostly on Windows systems, but there are users running the platform on Mac OS and Linux systems as well.
|
||||
|
||||
The app has very little requirements for active, hands-on use, that is, for creating strategies, running backtests, or interacting with the charts, for instance. We believe any cheap laptop should run the app without a problem.
|
||||
|
||||
Requirements increase significantly when processes that fetch data from exchanges, calculate indicators and run live trading sessions are active.
|
||||
|
||||
The minimum hardware setup recommended for a dedicated machine running all processes to trade live, is 3 GB of RAM and a dual-core processor at 2.4 GHz.
|
||||
|
||||
> **NOTE:** The above is a broad reference to the total RAM and processing power of the machine, not the specific requirements of the platform.
|
||||
|
||||
**Processing power is the key for comfortable operation.**
|
||||
|
||||
The following recommendations may make your life easier using this pre-release in beta stage:
|
||||
|
||||
* **We highly recommend you use Chrome to run the platform** so that you have a similar environment as developers in case you need help. We are not testing on any other browsers and it is a well-known fact that browsers do behave differently.
|
||||
|
||||
* **You will benefit from having a decent Console / Command Line application** for similar reasons: we hope you won't need it, but in case you do, it may save you lots of hassle and make a difference troubleshooting and getting help from the community. We recommend [Console Emulator Cmder](https://cmder.net/).
|
||||
|
||||
## Deploying a VPS to Trade Live
|
||||
|
||||
The minimum hardware setup for a virtual machine (VM) or a virtual private server (VPS) destined to trade live is 3 GB of RAM and a dual-core processor at 2.4 GHz. This is recommended to minimize deployment costs. Under this configuration, the platform becomes slow to react to user input. If such is the case, you should start the live trading session and minimize the browser for lower CPU and memory consumption.
|
||||
|
||||
You may want to read an article about [Trading Live from a Cheap Linux VM](https://medium.com/superalgos/trading-live-from-a-cheap-linux-vm-3edbe0c7ca42).
|
||||
|
||||
@@ -0,0 +1,157 @@
|
||||
---
|
||||
title: Telegram Announcements
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-telegram-announcements.html
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
The announcements feature allows users to set up notifications tied to specific events, and triggered once the events become active within a strategy.
|
||||
|
||||
You may use this feature to stay informed about the actions of your strategies while trading live, or to broadcast signals over a Telegram group while paper trading, for instance.
|
||||
|
||||
Supported events are:
|
||||
|
||||
* Trigger-on event
|
||||
* Trigger-off event
|
||||
* Take position event
|
||||
* Stop and take profit next-phase events
|
||||
|
||||
> **NOTE:** In addition, you can implement announcements at the level of stop and take profit *phases*, a particular case that shall be discussed later on.
|
||||
|
||||
The current implementation is based on broadcasting announcements via Telegram bots.
|
||||
|
||||
The platform uses Telegram's bots API to interact with a Telegram bot you will create. The bot will be added as a user in the Telegram group of your choice in which it will deliver the announcements as per the configuration you will set up in the platform.
|
||||
|
||||
Announcements may be triggered within any of the running modes available, including backtesting, paper trading, forward-testing, and live trading.
|
||||
|
||||
## Setting Up a Telegram Bot and Telegram Group
|
||||
|
||||
Telegram's documentation features the page [Bots: An introduction for developers](https://core.telegram.org/bots), where you may find all the details on how to use Telegram bots.
|
||||
|
||||
For your convenience, the following steps will guide you through the basic process:
|
||||
|
||||
**1.** Go to Telegram and find the user [@BotFather](https://telegram.me/botfather), type and send ```/newbot```. BotFather will ask you to pick a name for your bot. Once the name is set, it will respond with the token (a text string) to access the HTTP API:
|
||||
|
||||
|
||||
|
||||
You will need this token at a later time.
|
||||
|
||||
**2.** Go to or create the desired Telegram group in which your bot will broadcast announcements. Add both your bot and user [@myidbot](https://telegram.me/myidbot) to the group. Then type and send ```/getgroupid``` in the group. IDBot will answer with the group's ID. You will need this ID at a later time.
|
||||
|
||||
## Setting Up the Telegram Bot in the Platform
|
||||
|
||||
**1.** You will set up your bot in a backtesting session, so that you may easily test the announcements. Go to any of your backtesting sessions and add the *Social Bot* node using the menu.
|
||||
|
||||
**2.** On the Social Bots menu click add a *Telegram Bot*, open the menu and click *Edit Telegram Bot*. Now replace the placeholder text with the actual *botToken* and *chatId* you got earlier:
|
||||
|
||||
For example:
|
||||
|
||||
```json
|
||||
{
|
||||
"botToken": "927642627:2B1QkNX2620C2B1ZTp9JrQUV04YKtJrQ2t4",
|
||||
"chatId":-388158765
|
||||
}
|
||||
```
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/68231138-c09e0880-fffa-11e9-8ed2-b2fdcb76afe9.gif)
|
||||
|
||||
The platform now has everything it needs to communicate with your Telegram bot.
|
||||
|
||||
## Create Your Announcements
|
||||
|
||||
You will create an original announcement by clicking *Add Announcement* on the Telegram bot menu.
|
||||
|
||||
> **NOTE:** You may create as many announcements as you wish. Each announcement carries the ID of the Telegram Bot node in which it is created. This means you can have multiple Telegram Bots with any number of announcements each.
|
||||
|
||||
There are two different ways in which you can customize announcements:
|
||||
|
||||
* Plain text
|
||||
* Dynamic content
|
||||
|
||||
### Plain Text
|
||||
|
||||
To set a plain text announcement, click *Edit Announcement* on the announcement menu and customize the field *text*.
|
||||
|
||||
For example:
|
||||
|
||||
```json
|
||||
{
|
||||
"text": "Bull run rider has triggered!",
|
||||
"botType": "Telegram Bot",
|
||||
"botId": "1a3d3416-3691-36a1-a885-c1e99c66d57b"
|
||||
}
|
||||
```
|
||||
|
||||
Or...
|
||||
|
||||
```json
|
||||
{
|
||||
"text": "Bull run rider is taking a position!",
|
||||
"botType": "Telegram Bot",
|
||||
"botId": "1a3d3416-3691-36a1-a885-c1e99c66d57b"
|
||||
}
|
||||
```
|
||||
|
||||
Remember you may set up announcements for any of the events listed in the [Overview](#overview) section above.
|
||||
|
||||
### Dynamic Content
|
||||
|
||||
To broadcast more elaborate messages that may include dynamic values of any of the current indicators or internal variables, use the announcement menu to *Add Formula*.
|
||||
|
||||
The typical set up for a dynamic message consists of building a string by alternating "text between double quotes" with variables, separating them with plus signs (+).
|
||||
|
||||
For example, a typical announcement formula for the take position event may look like this:
|
||||
|
||||
```
|
||||
"Selling BTC at $" + candle.close.toFixed(0) + ", with stop at $" + stopLoss.toFixed(0) + " and TP target at $" + takeProfit.toFixed(0)
|
||||
```
|
||||
|
||||
```.toFixed(0)``` rounds the number to zero decimal places. The above formula would result in something like:
|
||||
|
||||
```
|
||||
Selling BTC at $9703, with stop at $9896 and TP target at $9115
|
||||
```
|
||||
> **NOTE:** If your formula is valid, the platform will ignore the plain text version you may have set up. If for any reason the formula results in an error, then the plain text version will be used.
|
||||
|
||||
#### Announcements on Stop and Take Profit Phases
|
||||
|
||||
We mentioned earlier that—beyond events—you may also implement announcements at the level of a stop or take profit phase.
|
||||
|
||||
In such cases, the announcement is triggered every time the value of the underlying variable changes. This is an important difference, as you will likely be using dynamic formulas for your stop and take profit phases, and the value may change at every candle.
|
||||
|
||||
This could result in too many announcements being generated in relatively short intervals.
|
||||
|
||||
You may use the ```valueVariation``` parameter to filter out announcements until a certain threshold is achieved. The value you enter will set the percentage of variation that needs to occur before a new announcement is broadcasted.
|
||||
|
||||
For instance, ```"valueVariation": 0.5``` means a new announcement will be broadcasted every time the value of the underlying variable changes by 0.5%.
|
||||
|
||||
```json
|
||||
{
|
||||
"text": "Write here what you want to announce.",
|
||||
"botType": "Telegram Bot",
|
||||
"botId": "1a3d3416-3691-4b1e-a885-a4ed9c66d57b",
|
||||
"valueVariantion": 0.5
|
||||
}
|
||||
```
|
||||
|
||||
## Placing and Testing Announcements
|
||||
|
||||
Every announcement you create needs to be attached to the event it is intended for. You will detach the announcement from the Telegram Bot node, drag it to the vicinity of the target event, and attach it to the event.
|
||||
|
||||
If you prefer, instead of dragging the announcement across the workspace which may be inconvenient, you may simply back it up and drop a copy right next to the target event.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/68232209-e1fff400-fffc-11e9-8dd6-5866cf9f2d0d.gif)
|
||||
|
||||
It's now time to test your set up. Run your backtesting session and you should start seeing the announcement in the corresponding Telegram group.
|
||||
|
||||
## Finishing the Setup
|
||||
|
||||
It is unlikely that you will want to use the announcements feature from within a backtesting session. A more likely scenario is you will want to use it with a paper-trading session (to generate signals) or from your live trading session, to monitor the activity of your strategy.
|
||||
|
||||
All you need to do to finish your set up is detach the Social Bot node from the backtesting session where it originated, and attach it to the session you wish to use. Make sure the corresponding tasks are stopped before detaching and attaching it.
|
||||
|
||||
That's it!
|
||||
|
||||
|
||||
@@ -0,0 +1,177 @@
|
||||
---
|
||||
title: Test
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-test.html
|
||||
---
|
||||
|
||||
<table class='hierarchyTable'>
|
||||
<thead>
|
||||
<tr>
|
||||
<th><img src='images/icons/crypto-ecosystem.png' alt='icon' /><br />Crypto Ecosystem</th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
<th></th>
|
||||
</tr>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><img src='images/icons/tree-connector-elbow.png' alt='icon' /></td>
|
||||
<td><a href='#crypto-exchanges' data-toggle='tooltip' data-original-title='The crypto exchanges node holds, as explicitly stated, exchanges definitions.'><img src='images/icons/crypto-exchanges.png' alt='icon' /><br />Crypto Exchanges</a></td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
<td><img src='images/icons/tree-connector-elbow.png' alt='icon' /></td>
|
||||
<td><a href='#crypto-exchange' data-toggle='tooltip' data-original-title='A crypto exchange node holds the definitions of assets and markets in a specific exchange, to be made available to the system.'><img src='images/icons/crypto-exchange.png' alt='icon' /><br />Crypto Exchange</a></td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td><img src='images/icons/tree-connector-fork.png' alt='icon' /></td>
|
||||
<td><a href='#exchange-assets' data-toggle='tooltip' data-original-title='The exchange assets node groups the definitions of assets to be made available to the system.'><img src='images/icons/exchange-assets.png' alt='icon' /><br />Exchange Assets</a></td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td><img src='images/icons/tree-connector-line.png' alt='icon' /></td>
|
||||
<td><img src='images/icons/tree-connector-elbow.png' alt='icon' /></td>
|
||||
<td><a href='#asset' data-toggle='tooltip' data-original-title='An asset in a market is a reference to one of the assets listed at the exchange as defined under the exchange assets node. The base asset is the one used to provide a quote—a price—for the quoted asset.'><img src='images/icons/asset.png' alt='icon' /><br />Asset</a></td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td><img src='images/icons/tree-connector-fork.png' alt='icon' /></td>
|
||||
<td><a href='#exchange-markets' data-toggle='tooltip' data-original-title='The exchange markets node groups the definitions of markets to be made available to the system.'><img src='images/icons/exchange-markets.png' alt='icon' /><br />Exchange Markets</a></td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td><img src='images/icons/tree-connector-line.png' alt='icon' /></td>
|
||||
<td><img src='images/icons/tree-connector-elbow.png' alt='icon' /></td>
|
||||
<td><a href='#market' data-toggle='tooltip' data-original-title='A market is the definition of a pair of assets (i.e.: BTC-USDT) listed as a market in the corresponding exchange.'><img src='images/icons/market.png' alt='icon' /><br />Market</a></td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td><img src='images/icons/tree-connector-line.png' alt='icon' /></td>
|
||||
<td> </td>
|
||||
<td><img src='images/icons/tree-connector-fork.png' alt='icon' /></td>
|
||||
<td><a href='#market-base-asset' data-toggle='tooltip' data-original-title='The market base asset is a reference to one of the assets listed at the exchange as defined under the exchange assets node. It is the asset in the pair used to provide a quote—a price—for the quoted asset.'><img src='images/icons/market-base-asset.png' alt='icon' /><br />Market Base Asset</a></td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td><img src='images/icons/tree-connector-line.png' alt='icon' /></td>
|
||||
<td> </td>
|
||||
<td><img src='images/icons/tree-connector-elbow.png' alt='icon' /></td>
|
||||
<td><a href='#market-quoted-asset' data-toggle='tooltip' data-original-title='The market quoted asset is a reference to one of the assets listed at the exchange as defined under the exchange assets node. It is the asset in the pair for which a quote is given, denominated in the base asset.'><img src='images/icons/market-quoted-asset.png' alt='icon' /><br />Market Quoted Asset</a></td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td><img src='images/icons/tree-connector-elbow.png' alt='icon' /></td>
|
||||
<td><a href='#exchange-accounts' data-toggle='tooltip' data-original-title='The exchange accounts node groups the different accounts the user may have with the corresponding exchange.'><img src='images/icons/exchange-accounts.png' alt='icon' /><br />Exchange Accounts</a></td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td><img src='images/icons/tree-connector-elbow.png' alt='icon' /></td>
|
||||
<td><a href='#user-account' data-toggle='tooltip' data-original-title='A user account represents a single account with the corresponding exchange, holding the definitions of user assets, including keys and balances.'><img src='images/icons/user-account.png' alt='icon' /><br />User Account</a></td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td><img src='images/icons/tree-connector-fork.png' alt='icon' /></td>
|
||||
<td><a href='#user-keys' data-toggle='tooltip' data-original-title='The user keys node groups the various exchange account keys the user may have under the corresponding account with the exchange.'><img src='images/icons/user-keys.png' alt='icon' /><br />User Keys</a></td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td><img src='images/icons/tree-connector-line.png' alt='icon' /></td>
|
||||
<td><img src='images/icons/tree-connector-elbow.png' alt='icon' /></td>
|
||||
<td><a href='#exchange-account-key' data-toggle='tooltip' data-original-title='The exchange account key holds the definition of the key name and secret provided by the corresponding exchange to access the user account via the exchange API.'><img src='images/icons/exchange-account-key.png' alt='icon' /><br />Exchange Account Key</a></td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td><img src='images/icons/tree-connector-elbow.png' alt='icon' /></td>
|
||||
<td><a href='#user-assets' data-toggle='tooltip' data-original-title='The user assets node groups the assets the user has at the exchange.'><img src='images/icons/user-assets.png' alt='icon' /><br />User Assets</a></td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td> </td>
|
||||
<td><img src='images/icons/tree-connector-elbow.png' alt='icon' /></td>
|
||||
<td><a href='#exchange-account-asset' data-toggle='tooltip' data-original-title='The exchange account asset represents a single asset the user has at the exchange.'><img src='images/icons/exchange-account-asset.png' alt='icon' /><br />Exchange Account Asset</a></td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
<table class='hierarchyTable'><thead><tr><th><a href='#charting-system' data-toggle='tooltip' data-original-title='{{site.data.charting_system.charting_system}}'><img src='images/icons/charting-system.png' /><br />Charting System</a></th><th></th><th></th><th></th><th></th><th></th><th></th><th></th><th></th></tr></thead><tbody>
|
||||
<tr><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#viewport' data-toggle='tooltip' data-original-title='{{site.data.charting_system.viewport}}'><img src='images/icons/viewport.png' /><br />Viewport</a></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#time-machine' data-toggle='tooltip' data-original-title='{{site.data.charting_system.time_machine}}'><img src='images/icons/time-machine.png' /><br />Time Machine</a></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#time-scale' data-toggle='tooltip' data-original-title='{{site.data.charting_system.time_scale}}'><img src='images/icons/time-scale.png' /><br />Time Scale</a></td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#rate-scale' data-toggle='tooltip' data-original-title='{{site.data.charting_system.rate_scale}}'><img src='images/icons/rate-scale.png' /><br />Rate Scale</a></td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#time-frame-scale' data-toggle='tooltip' data-original-title='{{site.data.charting_system.time_frame_scale}}'><img src='images/icons/time-frame-scale.png' /><br />Time Frame Scale</a></td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#timeline-chart' data-toggle='tooltip' data-original-title='{{site.data.charting_system.timeline_chart}}'><img src='images/icons/timeline-chart.png' /><br />Timeline Chart</a></td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#rate-scale' data-toggle='tooltip' data-original-title='{{site.data.charting_system.rate_scale}}'><img src='images/icons/rate-scale.png' /><br />Rate Scale</a></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td></td><td><img src='images/icons/tree-connector-fork.png' /></td><td><a href='#time-frame-scale' data-toggle='tooltip' data-original-title='{{site.data.charting_system.time_frame_scale}}'><img src='images/icons/time-frame-scale.png' /><br />Time Frame Scale</a></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#layers-manager' data-toggle='tooltip' data-original-title='{{site.data.charting_system.layers_manager}}'><img src='images/icons/layers-manager.png' /><br />Layers Manager</a></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td></td><td></td><td></td><td><img src='images/icons/tree-connector-elbow.png' /></td><td><a href='#layer' data-toggle='tooltip' data-original-title='{{site.data.charting_system.layer}}'><img src='images/icons/layer.png' /><br />Layer</a></td><td></td><td></td><td></td><td></td></tr></tbody></table>
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: Overview
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-testing-overview.html
|
||||
---
|
||||
|
||||
| Backtesting | Paper-Trading |
|
||||
| :---: | :---: |
|
||||
|  |  |
|
||||
|
||||
A simulation is a visual representation over the charts of any of the forms of strategy testing available within the platform:
|
||||
|
||||
* **Backtesting:** testing over historic data;
|
||||
|
||||
* **Paper-trading:** testing over a live data feed, without placing orders at the exchange (orders are simulated);
|
||||
|
||||
* **Forward testing:** testing over a live data feed, placing actual orders at the exchange for a fraction of the available balance.
|
||||
|
||||
We will cover *forward testing* when we discuss live trading, as it involves placing orders at the exchange. For the time being, we will focus on the first two steps of the strategy-testing process.
|
||||
|
||||
As explained in the previous chapter, the trading bot handles testing sessions and is controlled by a task and its corresponding task manager.
|
||||
|
||||
**To run a testing session, you will click *Run* on the corresponding task, and once the task is running, you will click *Run* on the session menu.**
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67272210-68c0b700-f4bc-11e9-8eb2-04a253451932.gif)
|
||||
|
||||
For your convenience, all our templates in the ```Quick-Start-Examples``` folder come with at least one backtesting and one paper-trading session set up. All you need to do is customize the *parameters* to your liking and, if you wish, add or remove layers to the *layer manager*, both offspring nodes of each testing session.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67272211-68c0b700-f4bc-11e9-82c4-570699faa673.gif)
|
||||
@@ -0,0 +1,107 @@
|
||||
---
|
||||
title: Trade Live With an Open-Source Strategy
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-trade-live-with-an-open-source-strategy.html
|
||||
---
|
||||
|
||||
Running a strategy as a fully automated bot to trade live is quite simple. Truth be told, your strategy running as a simulation is pretty much a trading bot already—only that orders don't go to the exchange.
|
||||
|
||||
If you are a crypto-holder, you are probably looking to trade live with an open-source strategy. If you are a trader, you are probably interested in seeing the platform in action before you spend time learning it to build your own strategies.
|
||||
|
||||
Either way, to start trading live, follow these steps:
|
||||
|
||||
## Go to the Live Sessions Task Manager
|
||||
|
||||
| Task Manager | Task | Trading Bot | Process | Live Trading |
|
||||
| :---: | :---: | :---: | :---: | :---: |
|
||||
| |  |  |  |  |
|
||||
|
||||
|
||||
Hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>L</kbd> (*L* for *Live trading*) to go the the *Live Sessions* task manager. Find the live trading session for the desired strategy and click  on the menu.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/70344145-4c54c000-1859-11ea-950a-f1e96e3c8512.gif)
|
||||
|
||||
## Configure Your Base Asset
|
||||
|
||||
| Parameters | Base Asset |
|
||||
| :---: | :---: |
|
||||
|  |  |
|
||||
|
||||
Click  on the *parameters* menu, locate the *base asset* parameter and select *Edit Base Asset*.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/70344147-4c54c000-1859-11ea-85b2-e0504bb0218d.gif)
|
||||
|
||||
Your base asset contains the following piece of code, which you may configure to your own needs:
|
||||
|
||||
For Bull Run Rider:
|
||||
|
||||
```
|
||||
{
|
||||
"name": "USDT",
|
||||
"initialBalance": 10,
|
||||
"minimumBalance": 1,
|
||||
"maximumBalance": 20000
|
||||
}
|
||||
```
|
||||
For Weak Hands Buster:
|
||||
|
||||
```
|
||||
{
|
||||
"name": "BTC",
|
||||
"initialBalance": 0.01,
|
||||
"minimumBalance": 0.0001,
|
||||
"maximumBalance": 100
|
||||
}
|
||||
```
|
||||
|
||||
| Variable | Description / Possible Values |
|
||||
| --- | --- |
|
||||
| name | USDT or BTC. The remaining fields in the configuration are denominated in this currency. |
|
||||
| initialBalance | The amount of capital you wish to allocate to the whole trading system. The strategy will trade with the full amount of the *initialBalance* on the first trade. Subsequent trades will be sized with the full available balance, meaning that your earnings will be traded together with the initial capital. |
|
||||
| minimumBalance | When your overall balance combined (USDT + BTC) reaches this value, all trading stops; think of this as a general safety switch. |
|
||||
| maximumBalance | A similar concept as the minimumBalance, but on the higher side of the _initialBalance_. |
|
||||
|
||||
## Enter Your Exchange API Key
|
||||
|
||||
| Parameters | API Key |
|
||||
| :---: | :---: |
|
||||
|  |  |
|
||||
|
||||
First thing is creating an *exchange account key* node using the *Add Key* option on the menu of the *parameters* of the live trading session.
|
||||
|
||||
Once you've got your API Key from the exchange (see instructions for [Poloniex](Poloniex-API-Keys)), you will enter the public key and secret in the *Exchange Account Key* node:
|
||||
|
||||
Select *Confirgure Key Value* on the menu and replace the value of *name* with your public key, and *secret* with the secret of your key.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/71255383-12da8500-232e-11ea-8a51-7daadd210efb.gif)
|
||||
|
||||
## Check Funds at the Exchange
|
||||
|
||||
Simply make sure that you have enough funds at the exchange. The platform will handle the error gracefully if there are no funds, but you will miss the trading opportunity.
|
||||
|
||||
## Run the Task and Session
|
||||
|
||||
Go back to the task controlling the Live Trading Session, select *Run* on the menu. Then go to the *Live Trading* session and do the same. You are now trading live!
|
||||
|
||||
> **WARNING:** The Superalgos Platform is at a very early stage of development. As such, errors may occur at any point, including errors that can cause you to lose money. Make sure you test with small amounts of money, the kind you can afford losing. Also, make sure you understand the [Execution Limitations](Execution-Limitations). You are responsible for taking all precautions before starting trading live, but even if you do errors may occur. Trade at your own risk.
|
||||
|
||||
> **DISCLAIMER:** THIS IS NOT FINANCIAL ADVICE. ALTHOUGH THE STRATEGIES DISTRIBUTED WITH THE SUPERALGOS DESKTOP APP MAY BE FULLY FUNCTIONAL, WE DO NOT MAKE ANY EXPRESS OR IMPLIED RECOMMENDATION AS OF HOW YOU SHOULD USE THEM. WE SHARE STRATEGIES FOR EDUCATIONAL PURPOSES ONLY. TRADE AT YOUR OWN RISK.
|
||||
|
||||
## Trading with Both Strategies at the Same Time
|
||||
|
||||
You may easily trade live with both the Weak-hands Buster (BTC) and Bull-run Rider (USDT) strategies.
|
||||
|
||||
Simply make sure that you:
|
||||
|
||||
**1.** Configure both live trading sessions as per the instructions on point 2 above.
|
||||
|
||||
**2.** Obtain two sets of API Keys from the exchange and use each set on either session. The exchange does not allow multiple connections with the same API keys.
|
||||
|
||||
**3.** Check both assets (USDT and BTC) are available to trade with at the exchange.
|
||||
|
||||
Once you are set up, run the tasks corresponding to the two live trading sessions and run both sessions one after the other one.
|
||||
|
||||
## Following Live Trading on the Charts
|
||||
|
||||
To follow the live trading sessions on the charts, please refer to the [Live trading history layer](Live-Trading-History-Layer) page of this User Manual. We encourage you to keep learning about the platform so that you may get the most out of it.
|
||||
File diff suppressed because it is too large.
Load diff
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: Overview
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-trading-system-overview.html
|
||||
---
|
||||
|
||||
| Definition | Trading System |
|
||||
| :---: | :---: |
|
||||
|  |  |
|
||||
|
||||
A *trading system* is a collection of strategies that conform to certain *parameters*.
|
||||
|
||||
The trading system organizes the workflow to build strategies following the framework implemented by the _Superalgos Trading Protocol_. If you are not familiar with the protocol, please read either of the following articles:
|
||||
|
||||
* [Superalgos Trading Protocol V0.1 - the Short Version, for Experienced Traders](https://medium.com/superalgos/superalgos-protocol-v0-1-the-short-version-for-experienced-traders-86c3fa43f1c0).
|
||||
|
||||
* [Superalgos Trading Protocol V0.1 - the Long Version, for Beginner Traders](https://medium.com/superalgos/superalgos-protocol-v0-1-the-long-version-for-beginner-traders-f293f1cc6c13).
|
||||
|
||||
> **NOTE**: The articles above are instrumental in understanding the framework that will guide you through the process of creating strategies. The framework is not explained in this guide, therefore, we recommend you go through the article before starting work on your own strategies.
|
||||
|
||||
## Parameters
|
||||
|
||||
Parameters are both a property of the trading system and of the testing and live trading sessions that engage with the trading system.
|
||||
|
||||
Precedence lies with the parameters defined at the level of the sessions. The platform implements a fallback mechanism by which, in case a certain parameter is not found at the level of the session, the information is retrieved from the trading system.
|
||||
|
||||
The one parameter that needs to be defined early on is the *base asset*, that is, the side of the market you wish to stand on when you are out of the trade, with no open positions. We will review the rest of the trading system parameters later on when discussing testing and live trading sessions.
|
||||
|
||||
| Parameters | Base Asset |
|
||||
| :---: | :---: |
|
||||
|  |  |
|
||||
|
||||
Your Base Asset formula contains the following piece of code, which you may configure to your own needs:
|
||||
|
||||
```
|
||||
{
|
||||
"name": "USDT",
|
||||
"initialBalance": 10,
|
||||
"minimumBalance": 1,
|
||||
"maximumBalance": 20000
|
||||
}
|
||||
```
|
||||
|
||||
| Variable | Description / Possible Values |
|
||||
| --- | --- |
|
||||
| name | USDT or BTC |
|
||||
| initialBalance | The amount of capital you wish to allocate to the whole trading system. |
|
||||
| minimumBalance | When your overall balance combined (balanceAssetA + balanceAssetB) reaches this value, all trading stops; think of this a general safety switch. |
|
||||
| maximumBalance | A similar concept as the minimumBalance, but on the higher side of the _initialBalance_. |
|
||||
|
||||
> **NOTE**: All strategies contained within a trading system share these parameters. In other words, all strategies within the same trading system have the same base asset and share the initial balance.
|
||||
|
||||
Only one trading system is allowed at a time per each definition. If you wish to have more than one trading system, then you will create a new definition to hold the new trading system. This means that if you wish to have strategies with different base assets, you will need to create them within different trading systems, which will live in different definitions.
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: Update Datasets
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-update-datasets.html
|
||||
---
|
||||
|
||||
To trade live, strategies need to be able to access up-to-date information to make trading decisions.
|
||||
|
||||
The bot that extracts raw trades data from the exchange and those which process the raw data to generate elaborate datasets, like indicators and other technical studies, need to be running at all times while trading live.
|
||||
|
||||
When you ran your first backtesting session, you first had to run a task that controls the trading bot and the specific process involved in calculating the backtests.
|
||||
|
||||
The bots that keep your datasets up to date are too controlled by a task manager and tasks, within the Network hierarchy.
|
||||
|
||||
| Superalgos Network | Network Node | Task Manager | Task | Sensor | Indicator |
|
||||
| :---: | :---: | :---: | :---: | :---: | :---: |
|
||||
|  |  | |  |  |  |
|
||||
|
||||
Open up the Designer section of the platform by dragging the horizontal bar upwards. You may also use <kbd>Alt</kbd> + <kbd>↑</kbd> on your keyboard. This shortcut closes the Charts and opens the Designer.
|
||||
|
||||
Hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>D</kbd> (*D* for *Datasets*) to go to the *Masters Datasets* task manager that controls the aforementioned bots. Open the menu and click *Run All Tasks*.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/70341428-304e2000-1853-11ea-8158-8c59b56995fb.gif)
|
||||
|
||||
You just started the *sensors* that extract live data from the exchange and the *indicators* that process raw trades data.
|
||||
|
||||
The data you downloaded spans from the date of the start of the market to the date of the release. Before you start trading live, the bots need to run for a while so as to catch up with the present time.
|
||||
|
||||
You will not see any immediate effect in your browser, but notice how your console application is buzzing with activity:
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67233532-b8af6780-f443-11e9-98e0-8efec4a305fe.gif)
|
||||
|
||||
> **NOTE:** To know when datasets are up to date, you may find Paula under the Masters Datasets task manager, click  on its menu and notice the date displayed under the *Daily* process. When this date reaches the present time, chances are all other datasets will be up to date as well. You may also check your console and study the logs to see if all bots are processing the current date-time.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/70341574-89b64f00-1853-11ea-8552-109bb90989ac.gif)
|
||||
|
||||
In our experience, it may take from 5 to 20 minutes per day's worth of Poloniex data to be processed. The time it will take for these processes to complete the job depends on several things:
|
||||
|
||||
* The date of the release tells you how many days you are behind with the dataset you just downloaded.
|
||||
|
||||
* The speed and processing power of your machine will make a difference too.
|
||||
|
||||
* The average number of trades per day at the exchange determines the volume of data the platform needs to retrieve and process.
|
||||
|
||||
* The number of trades the exchange returns per each request determines the size of the pipeline the exchanges allow API users to use.
|
||||
|
||||
These bots will keep running for as long as you keep the browser tab running the platform open.
|
||||
|
||||
> **NOTE:** Remember no to close the console before closing the browser and allowing enough time for all processes to finish the current execution. Failing to do so may corrupt your data.
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: Upgrading Your Existing Installation
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-upgrading-your-existing-instalation.html
|
||||
---
|
||||
|
||||
You should expect new releases to become available regularly. Appropriate notices will be placed on the [Official Superalgos Telegram Announcements Channel](https://t.me/superalgos), which will be forwarded to the several Community groups by an *admin*.
|
||||
|
||||
This is what you should do if you wish to upgrade to a new version:
|
||||
|
||||
## 1. Read the Announcement Carefully
|
||||
|
||||
Read and understand the announcement explaining the changes and how they may impact your workflow. Find out if the new version requires upgrading your workspace.
|
||||
|
||||
Decide which parts of your workspace you wish to backup in order to be able to restore them on the upgraded workspace if there is one (*e.g.: you may want to backup your strategies, trading system or definition, indicators you may have created, and so on*). If there is no need to upgrade the workspace, that means that the new version of the platform should work well with your existing workspace (provided that you are only one version behind).
|
||||
|
||||
## 2. Back Up Your Workspace
|
||||
|
||||
Always back up your existing workspace before switching versions. You may always go back to a working version in case something goes wrong with the new one, by installing the previous version of the platform and restoring your old workspace from a backup file.
|
||||
|
||||
## 3. Put the House in Order
|
||||
|
||||
Stop the platform by closing your browser. Allow a minute or two until all activity stops before closing the Console/Command Line running the programs.
|
||||
|
||||
Make sure you are not storing any personal files, such as your workspace backups and so on in your ```Superalgos Platform``` folders. Move them to a different location if you are.
|
||||
|
||||
You will keep the ```Data-Storage``` folder intact and delete all the remaining folders within the ```Superalgos Platform``` folder. You do not need to get rid of the historic market data every time you upgrade your platform. **Do not delete your ```Data-Storage``` folder**.
|
||||
|
||||
## 4. Download and Install the New Version
|
||||
|
||||
Download the latest patch or latest release from the location advertised on the Official Announcement Channel.
|
||||
|
||||
> **WARNING**: Always beware of what random people may post in open Telegram groups or forums. Patches and releases will always be made available at the [Releases page](https://github.com/Superalgos/Platform/releases) of this repository only.
|
||||
|
||||
Extract/unpack the contents of the ZIP file directly into the ```Superalgos Desktop App``` folder.
|
||||
|
||||
That's it! You are up and running with the new version. Start the platform the same way you always do unless new instructions become available in this User Manual.
|
||||
|
||||
## 5. Hard Refresh
|
||||
|
||||
Once the platform loads in your browser window and before you start working or import a new workspace, hit <kbd>Ctrl or ⌘</kbd> + <kbd>Shift</kbd> + <kbd>R</kbd> (in Chrome) to perform a *hard reload*. This ensures all scripts are properly updated in your browser's cache.
|
||||
|
||||
## 6. Final Tunning and Testing
|
||||
|
||||
Occasionally, the new version of the platform may introduce changes that may require you to update your existing strategies or some other parts of your workspace. If that is the case, the announcement of the new release should explain how to proceed.
|
||||
|
||||
This is the time to restore any of the work you may have backed up earlier, on the first step.
|
||||
|
||||
Before going deep back to work, it is always recommeended to test the new version a bit and make sure that your existing work performs as you would expect.
|
||||
|
||||
If you run into any issues, feel free to drop us a line in our [Community Telegram](https://t.me/superalgoscommunity).
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: Using Indicators Not Included in the Data Release
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-using-non-included-indicators.html
|
||||
---
|
||||
|
||||
Using indicators not included in the data release requires performing a couple of tasks that will set you up to use the said indicators efficiently.
|
||||
|
||||
Each indicator will produce a dataset spanning the whole market and will require running the corresponding bot instance to keep the dataset up-to-date all the time, or at least when you need it—for instance—to trade live.
|
||||
|
||||
This means that you may need to be mindful of which indicators you will set up to use.
|
||||
|
||||
If you have plenty of disk space and a machine with plenty of processing power and memory, you are free to set up all of the indicators at once. If that is not the case, then you will be better off setting up only the indicators that you intend to use.
|
||||
|
||||
> **NOTE:** The setup process described below is a temporary solution to the early stage limitations that characterize an beta stage product. We expect the experience to improve significantly in upcoming releases. That said, rest assured that—while the setup guide may seem long—it is actually quite easy to follow and takes only 3 minutes to execute.
|
||||
|
||||
**Let's say you wish to set yourself up to use the standard setting of the MACD indicator, that is, the (12, 26, 9) setting. This is what you need to do:**
|
||||
|
||||
## 1. Run the MACD Bot Instance to Produce the Datasets
|
||||
|
||||
Because this set of indicators have *data and status dependencies* with the bots in the *Masters Datasets*, you need to make sure the Master bots are running first. So, go ahead and *Run All Tasks* in the *Masters Datasets* task manager.
|
||||
|
||||
Now you can hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>I</kbd> (*I* for *Indicators*) to go to the *Sparta Datasets* task manager find the task controlling the MACD bot instance, and click *Run* on the menu.
|
||||
|
||||
As the image below shows, each bot that you run will show a notice under its *Daily* process of the date up to which data has been processed so far. To see process instances you first need to click  in the bot instance menu.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/70346176-f9313c00-185d-11ea-9cf2-18b036a711ba.gif)
|
||||
|
||||
## 2. Link the Trading Bot Data Dependency to the Corresponding Datasets
|
||||
|
||||
Now you need to establish a referense between *Jason*, the trading bot, and each of the datasets you intend to use, in our case, the *MACD122609* product.
|
||||
|
||||
This is what you need to do:
|
||||
|
||||
**a.** Locate Team Masters hitting <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>M</kbd> (*M* for *Masters*). Click  on the menu to open the definition.
|
||||
|
||||
**b.** Now hit <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>M</kbd> (*J* for *Jason*) to find the trading bot definition. This definition is like the *source code* of the bot, represented by a hierarchy of nodes. Click  on the menu to open the definition.
|
||||
|
||||
**c.** Look around for the *Multi-Period* process definition, and find one of its offspring nodes named Process Dependencies. Click  on the menu to open the definition.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/70349517-259c8680-1865-11ea-80e3-09e67627c6b9.gif)
|
||||
|
||||
**d.** Click on the *rotational symmetry* setting of the process dependencies node and add two new data dependencies. Releasing the rotational symmetry setting before creating the data dependencies results in the dependencies being created without the rotational symmetry property, as nodes inherit the properties of their parents.
|
||||
|
||||
|
||||
|
||||
**e.** Now name one of the data dependencies *MACD 122609 Market* and the other one *MACD 122609 Daily*.
|
||||
|
||||
|
||||
|
||||
**f.** Locate Team Sparta hitting <kbd>Ctrl or ⌘</kbd> + <kbd>Alt</kbd> + <kbd>S</kbd> (*S* for *Sparta*). Follow the line to the left to find the MACD indicator bot definition and click  on the menu to open the definition.
|
||||
|
||||
**g.** Locate the *MACD 122609* product definition and click  on the menu. You will see the *Multi-Period-Market* and *Multi-Period-Daily* dataset definitions.
|
||||
|
||||
|
||||
|
||||
**h.** All you need to do is establish a reference between each data dependency you created at the *Multi-Period* process definition in Jason and the corresponding dataset in the *MACD 122609* product definition of the MACD indicator bot.
|
||||
|
||||
So, go back to Jason, left-click on the *MACD 122609 Market* data dependency and hit <kbd>Ctrl or ⌘</kbd> + <kbd>→</kbd> to start panning to the right, dragging the data dependency. You will pan to the right because the Sparta team is spatially located to the right of the Masters team. Keeping the key combination pressed works like a charm and flys you across the workspace at lightning speed.
|
||||
|
||||
Once you are in the vicinity of the MACD indicator definition, stop, take a pause and pin the data dependency so that it doesn't fly back to its parent node. Now locate the *Multi-Period-Market* dataset, right-click on the data dependency you just drag and link it to the corresponding dataset.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/70351647-aeb5bc80-1869-11ea-94fe-0a8cea4e3987.gif)
|
||||
|
||||
That's it! Now, do the same with the second data dependency and link it to the remaining dataset and you are good to go!
|
||||
|
||||
If you wish to use other products of MACD, simply repeat this operation, and the same goes for setting yourself up with any other indicators.
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: What's Next?
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-what-is-next.html
|
||||
---
|
||||
|
||||
The Superalgos Platform is a comprehensive data processing and trading automation system that enables users to control every aspect of the *intelligence* required to be successful at trading.
|
||||
|
||||
We don't think of intelligence as the outcome of a good trading strategy. Instead, intelligence is the effective use of every resource available, including but not limited to:
|
||||
|
||||
* strategies;
|
||||
* raw market datasets (trades, orders, etc.);
|
||||
* elaborate datasets (indicators, studies, etc.);
|
||||
* infrastructure (trading bot, processes, workflows, etc.).
|
||||
|
||||
You've gone through the very basic operation of the platform that allows you to use existing strategies.
|
||||
|
||||
The rest of this User Manual covers the power use of the platform, which involves modifying existing strategies and building your own, going through a thorough testing process and trading live.
|
||||
|
||||
You will also learn to take control of what happens under the hood, so that you may decide *how* you are going to do your job.
|
||||
|
||||
For example, you will learn to:
|
||||
|
||||
* define which processes run in your machine and how;
|
||||
* determine what datasets you will work with;
|
||||
* modify and create your own datasets.
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: What to Expect
|
||||
summary: "The Superalgos Suite is in beta stage, still under development. Check the website for details on features and functionality."
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-what-to-expect.html
|
||||
---
|
||||
|
||||
Superalgos is pre-releasing an early beta-stage version of the Superalgos Platform in the hope that early adopters will help us shape the software and evolve it into a robust product. We try our best to make installation and operation easy, but at this point, the platform is directed at tech-savvy individuals with a knack for learning a few PC operator tricks while installing and using the platform.
|
||||
|
||||
If you don't consider yourself an early adopter and usually go to your 10-year-old for advice on using your PC, you may still give it a shot. Developers and users in the [Community](https://t.me/superalgoscommunity) will be happy to give you a hand and help you get up and running.
|
||||
|
||||
## About the Platform
|
||||
|
||||
What you will get is a client application that runs entirely on users' machines. This is to fulfill the design principle of a trustless deployment: you don't need to trust any third party with your strategies, exchange API keys, personal information, or funds.
|
||||
|
||||
If you haven't seen it yet, there is a thorough description of the platform including introduction videos [on the website](https://superalgos.org/tools-superalgos-platform.shtml).
|
||||
|
||||
## A Rather Big Download
|
||||
|
||||
Traders rely on datasets for backtesting. The platform retrieves raw trades data directly from exchanges and processes data to produce candles and a few indicators, which are stored in your local machine.
|
||||
|
||||
The volume of trades data generated at exchanges is massive. Exchanges APIs impose limits on the bandwidth of data you may retrieve from your machine per unit of time. To save you from spending days or weeks running processes to retrieve the data you will need for backtesting, we include historic market data in our releases.
|
||||
|
||||
This has a small non-monetary cost associated: the zip files you will download are a bit heavy and highly compressed. As a result, it may take 30 to 60 minutes for your machine to decompress the files. Also, a second small cost is that this adds a step in the process to fire up the platform the first time.
|
||||
|
||||
## Poloniex Only as a Temporary Limitation
|
||||
|
||||
Because the platform is still at an early stage of development, we limit the use of data and trading to a single exchange: Poloniex. Once the core infrastructure is sufficiently developed and stabilized, we plan to implement the [CCXT library](https://github.com/ccxt/ccxt/) to enable access to [a vast list of exchanges](https://github.com/ccxt/ccxt/wiki/Exchange-Markets). We expect this to happen in Q1 2021.
|
||||
|
||||
The choice of Poloniex as the first exchange was purely circumstantial: Poloniex was the number one exchange in the world when the Superalgos Project was born, back in the summer of 2017.
|
||||
|
||||
## Feedback
|
||||
|
||||
We value highly all feedback. We are listening and actively participating in the various Superalgos Telegram groups.
|
||||
|
||||
We keep a wish list for new features in the form of [issues in this repository](https://github.com/Superalgos/Platform/issues). If you are missing a key feature, feel free to open an issue using the ```improvement``` label.
|
||||
|
||||
However, bear in mind that the platform is at an early stage of development and that the current priority is stabilization and delivery of core functionality.
|
||||
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
title: Working with Strategies
|
||||
summary: ""
|
||||
sidebar: suite_sidebar
|
||||
permalink: suite-working-with-strategies.html
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
| Definition | Trading System | Strategy |
|
||||
| :---: | :---: | :---: |
|
||||
|  |  |  |
|
||||
|
||||
As the Superalgos Trading Protocol indicates, the definition of strategies is done in stages:
|
||||
|
||||
* <a href="suite-trading-system-hierarchy.html#trigger-stage" data-toggle="tooltip" data-original-title="{{site.data.trading_system.trigger_stage}}">Trigger Stage</a>
|
||||
* <a href="suite-trading-system-hierarchy.html#open-stage" data-toggle="tooltip" data-original-title="{{site.data.trading_system.open_stage}}">Open Stage</a>
|
||||
* <a href="suite-trading-system-hierarchy.html#manage-stage" data-toggle="tooltip" data-original-title="{{site.data.trading_system.manage_stage}}">Manage Stage</a>
|
||||
* <a href="suite-trading-system-hierarchy.html#close-stage" data-toggle="tooltip" data-original-title="{{site.data.trading_system.close_stage}}">Close Stage</a>
|
||||
|
||||
We will review each stage, one by one, but let's first discuss the common nodes among them.
|
||||
|
||||
Becoming familiar with the Superalgos Trading Protocol will significantly increase your understanding of how to build strategies, so we highly recommend reading either of the following articles:
|
||||
|
||||
* [Superalgos Trading Protocol V0.1 - the Short Version, for Experienced Traders](https://medium.com/superalgos/superalgos-protocol-v0-1-the-short-version-for-experienced-traders-86c3fa43f1c0).
|
||||
|
||||
* [Superalgos Trading Protocol V0.1 - the Long Version, for Beginner Traders](https://medium.com/superalgos/superalgos-protocol-v0-1-the-long-version-for-beginner-traders-f293f1cc6c13).
|
||||
|
||||
The Designer provides a graphic user interface (GUI) for traders to input the _rules_ and _formulas_ that determine the behavior of strategies. Traders need to define the rules to _trigger on_ and _trigger off_ each strategy, to _take a position_, to manage _take profit_ targets and _stops_.
|
||||
|
||||
## Situations and Conditions
|
||||
|
||||
| Situations | Conditions | Code |
|
||||
| :---: | :---: | :---: |
|
||||
|  |  |  |
|
||||
|
||||
The protocol calls these sets of rules _situations_, in the sense that you are trying to determine what is going on with the market and, if the 'situation' is right, certain _actions_ or _events_ should be triggered.
|
||||
|
||||
In other words, you define _situations_ in which you wish a certain _event_ to happen (i.e.: trigger on the strategy, take a position, etc.) and each situation is described as a set of _conditions_ that need to be met for the _event_ to be triggered.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/63052184-fe4d3280-bede-11e9-87b0-7fb67964450c.gif)
|
||||
|
||||
The type of _statements_ you will use to define _conditions_ need to evaluate to _true_ or _false_.
|
||||
|
||||
When ***all conditions*** within a _situation_ evaluate _true_, then the _situation_ evaluates _true_. This means that multiple _conditions_ within a situation are evaluated with the _AND_ operator (_e.g. condition 1 AND condition 2 AND condition 3 are either true or false; that is, if one condition is false, then the situation is false_).
|
||||
|
||||
On the other hand, when a certain event has multiple _situations_, then _situations_ are evaluated with the _OR_ operator (e.g. if either _situation 1_ OR _situation 2_ are true, then the event will be triggered.
|
||||
|
||||
This set up of _conditions_ and _situations_ allows taking the same kind of action (trigger a certain event) upon the occurrence of different desirable scenarios, each described by one _situation_.
|
||||
|
||||
Put in other words, events may be triggered in different circumstances, meaning that you are free to define different _situations_ upon which the event would be triggered. In such a case, when **any** of the _situations_ evaluate _true_, then the event shall be triggered.
|
||||
|
||||
> **NOTE:** The specific way in which conditions and formulas are written is covered further down this User Manual.
|
||||
|
||||
## Using an Existing Strategy
|
||||
|
||||
Thanks to the implementation of the Superalgos Trading Protocol, all strategies built within the Superalgos Platform are portable. This means that people may use strategies built by other people or groups of people.
|
||||
|
||||
You may import any node—formulas, conditions, situations, phases, stages, complete strategies, complete trading systems, and even complete workspaces—simply by dragging and dropping them on the workspace.
|
||||
|
||||
[](https://user-images.githubusercontent.com/13994516/67271115-34e49200-f4ba-11e9-9309-e9e7046384a0.gif)
|
||||
|
||||
## Working with Multiple Strategies
|
||||
|
||||
When you have more than one strategy under the same trading system, all strategies share the *parameters* defined at the trading system level. This means that all strategies will work with the same *base asset* and share the same *initialCapital*.
|
||||
|
||||
As a consequence, strategies within a trading system may never be triggered-on at the same time. Under such a setting, when a strategy is triggered on, it blocks the triggering of the rest of the strategies within the trading system until the strategy is triggered off.
|
||||
|
||||
If you wish to have multiple strategies that work independently from each other, then you need to place them on different trading systems. The platform supports only one trading system per definition. As a result, if you wish to have multiple independent strategies, then you need to have multiple definitions, each with one trading system. Learn how to do that in the [Working with multiple definitions](Working-with-Multiple-Definitions) section.
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
layout: null
|
||||
search: exclude
|
||||
---
|
||||
|
||||
{
|
||||
"entries":
|
||||
[
|
||||
{% for page in site.tooltips %}
|
||||
{
|
||||
"doc_id": "{{ page.doc_id }}",
|
||||
"body": "{{ page.content | strip_newlines | replace: '\', '\\\\' | replace: '"', '\\"' }}"
|
||||
} {% unless forloop.last %},{% endunless %}
|
||||
{% endfor %}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "Collaboration pages"
|
||||
tagName: collaboration
|
||||
search: exclude
|
||||
permalink: tag_collaboration.html
|
||||
sidebar: mydoc_sidebar
|
||||
folder: tags
|
||||
---
|
||||
{% include taglogic.html %}
|
||||
|
||||
{% include links.html %}
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "Content types pages"
|
||||
tagName: content_types
|
||||
search: exclude
|
||||
permalink: tag_content_types.html
|
||||
sidebar: mydoc_sidebar
|
||||
folder: tags
|
||||
---
|
||||
{% include taglogic.html %}
|
||||
|
||||
{% include links.html %}
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "Formatting pages"
|
||||
tagName: formatting
|
||||
search: exclude
|
||||
permalink: tag_formatting.html
|
||||
sidebar: mydoc_sidebar
|
||||
folder: tags
|
||||
---
|
||||
{% include taglogic.html %}
|
||||
|
||||
{% include links.html %}
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "Getting started pages"
|
||||
tagName: getting_started
|
||||
search: exclude
|
||||
permalink: tag_getting_started.html
|
||||
sidebar: mydoc_sidebar
|
||||
folder: tags
|
||||
---
|
||||
{% include taglogic.html %}
|
||||
|
||||
{% include links.html %}
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "Mobile Pages"
|
||||
search: exclude
|
||||
tagName: mobile
|
||||
permalink: tag_mobile.html
|
||||
sidebar: mydoc_sidebar
|
||||
folder: tags
|
||||
---
|
||||
{% include taglogic.html %}
|
||||
|
||||
{% include links.html %}
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "Navigation pages"
|
||||
tagName: navigation
|
||||
search: exclude
|
||||
permalink: tag_navigation.html
|
||||
sidebar: mydoc_sidebar
|
||||
folder: tags
|
||||
---
|
||||
{% include taglogic.html %}
|
||||
|
||||
{% include links.html %}
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "News"
|
||||
tagName: news
|
||||
search: exclude
|
||||
permalink: tag_news.html
|
||||
sidebar: mydoc_sidebar
|
||||
folder: tags
|
||||
---
|
||||
{% include taglogic.html %}
|
||||
|
||||
{% include links.html %}
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "Publishing pages"
|
||||
tagName: publishing
|
||||
search: exclude
|
||||
permalink: tag_publishing.html
|
||||
sidebar: mydoc_sidebar
|
||||
folder: tags
|
||||
---
|
||||
{% include taglogic.html %}
|
||||
|
||||
{% include links.html %}
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "Single sourcing pages"
|
||||
tagName: single_sourcing
|
||||
search: exclude
|
||||
permalink: tag_single_sourcing.html
|
||||
sidebar: mydoc_sidebar
|
||||
folder: tags
|
||||
---
|
||||
{% include taglogic.html %}
|
||||
|
||||
{% include links.html %}
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: "Special layout pages"
|
||||
tagName: special_layouts
|
||||
search: exclude
|
||||
permalink: tag_special_layouts.html
|
||||
sidebar: mydoc_sidebar
|
||||
folder: tags
|
||||
---
|
||||
|
||||
{% include taglogic.html %}
|
||||
|
||||
{% include links.html %}
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "Troubleshooting pages"
|
||||
tagName: troubleshooting
|
||||
search: exclude
|
||||
permalink: tag_troubleshooting.html
|
||||
sidebar: mydoc_sidebar
|
||||
folder: tags
|
||||
---
|
||||
{% include taglogic.html %}
|
||||
|
||||
{% include links.html %}
|
||||
Reference in new issue
Block a user