Feature: GoCryptoTrader Backtester (#622)

* Backtester: event handler completed, basic back tester support is working

* Backtester: support for ticker data added, general code clean up, start of risk & size manageR

* Backtester: WIP

* Me: I am going to write tests and comment as I go this time, also me: doesn't write any tests or comments as i go

* Backtester: work on orderbook system to track orders, increased test coverage

* Backtester: further test coverage, output json, start of js chart output

* Backtester: test coverage, output strat name

* Backtester: WIP

* WIP backtest charts

* WIP on template

* Backtester: further test coverage added

* Backtester: WIP

* backtester: attempting easier to read template for backtesting output

* comments, and tests

* Backtester: end of day WIP started work on risk management for handling leveraged positions

* Backtester: WIP

* Backtester: started heavy documentation phase for handover

* Backtester: started heavy documentation phase for handover

* Backtester: further comments, also work on making chart solution modular to allow for usage outside backtester (e.g OHCLV data)

* Backtester: CHART LIBRARY

* Backtester: move backtester over to new chart library

* Backtester: removed old chart templates, template updates

* Chart: add advancedintervaldata, convert from stats -> chart

* Chart: gctscript hookup to generate chart from OHLCV data

* Chart: reworked template to load from generated data if no template path is set

* chart: template wip

* correclty generate backtester readme, readme generation for charts, chart data generation

* Removed old read file methods

* Removed chart library from backtest as its now standalone

* Remove reference to unfinish TA code. Removes value calculation from order signal. It belongs with portfolio signal

* regen

* Re-jiggles everything around to not have import cycle issues and makes it look like a normal application

* End of day commit creates a new function to setup a backtester from a settings struct. Doesn't work though lol

* Builds up more backtest work to allow to be run from the command line

* Regen RPC

* End of day mind mine field of RSI calculation5

* Finishes basic main.go application

* Minor updates while theorising

* Rearranging things like the size and data types. Adds portfolio setup like a normal human. Allows positions to be decimal based since this is for CRYPTOCURRENCIES :o

* Moves code around to related positions. Adds compatibility to ordermanager to handle order submission. Fails to do things

* End of day commit. Adding config based loading for indiviual strats. Attempting to allow for multiple cps per strategy as well as loading fees

* End of day commit. Expanding config definition and loading implementation. Attempting to setup backtester wide multi currency support in a strategy.

* Moves risk, attempts to revert multi currency, but also supports more in depth multi currency for later...... in the portfolio

* End of day commit for realsies. Updates the strat and sets the invalid backtester

* No more panics. Finishes config loading. Renames buyandhold to dollarcostaverage

* Extends strategy to include a reason why its performing an action. Adds 420blazeit.strat. Expands statistics output. Moves folders around some more. Reduces amount of processing when "DO NOTHING" is the direction

* Commit before home time. Looks to expand the order manager to cater to the backtester. Fleshes out risk manager to think about leverage and holdings in other currencies

* Some basic expanding of strategy definitions. Changes weird package naming.

* Expands size and risk validations. Expands config settings for the validation. Starts looking at loading from live data source

* Merge branch 'master' into backscratcher

* Work towards having backtester load data

* Adds support and tests for all data source loading except for LIVE

* Some basic additions looking to append to data streams instead of load all at once, for the purpose of live data analysis

* End of day commit where I broke functions

* Adds live backtesting

* Adds FANCY MATHS to correctly size orders before  slippage. Rearranges minmaxing in config and strats

* Prints out initial settings. Creates a lame slippage calculator. Ensures that order price/amounts respect OHLCV data. Adds customisable config variables that can influence a strategy

* Fixes minor issues with rendering. Fixes portfolio buying and selling now

* ALL OVER THE PLACE END OF DAY COMMIT! In order to expand stats, thing must be tracked appropriately, which they arent. Here we add the addition of a compliance.go to track orders specifically. This will allow for the holdings manager to keep track of base stats such as how much we hold versus whats in use along with profits Compliance holds snapshots of every tick and what orders were there across exchanges. Also added a random slippage calculator which will allow a user to set their own slippage rates

* Another fun end of day commit where nothing works. In order to have accurate stats, you need accurate positions, to have accurate positions you need to break things down to individual levels and store them. This is part of that process of ensuring that we can have multiple settings and everything processed appropriately.

* Finalises multi currency config and support at most levels with exception to data loading.
Simplifies some struct property definitions by removing redundancy
Allows tracking of entire portfolio snapshots after each interval to track the entire process
Lowercases use of exchange names

* Sets the different prices to track across time. Attempts to sort out compliance snapshots

* end of day commit. Moving compliance to the portfolio to manager and track all transactions at each interval.

* Moves compliance calculation to portfolio.go. Adds a nice little decorator on the compliance manager orders to keep track of slippage, cost basis, volume adjusted price and close price. Moves "positions" to "hodlings" to be more accurate. Ensures exchange value calculations are accurate. Begins looking at Statistics and hodlings

* Moves statistics to eventhandlers. Removes ticker work as not needed. Redefines hodler properties

* hodlings are actually part of the portfolio

* Renamed 420blazeit.strat file. Renamed hodlings to holdings. Moved Datahandler to data_types.go. Expanded holdings calculations, doesn't work, but we're getting somewhere. Renamed bad var names in backtest.go. Added new order side types to highlight lack of action reasons

* Adds tests for holdings to ensure that holding snapshot calculation is accurate for the length of a strategy. Removes portfolio.Funds because its now handled via the holdings snapshots. Adds helper functions to Holding snapshots to retrieve relevant holdings. Updates sizing calculation to properly handle sell events. Expands holdings definitions to allow for comparison. Expands risk calculations to include holding snapshots so as to analyse all positions simultaneously

* Changing the statistics results to consider all datas, with the ultimate goal to replace the current statistics package with this multi currency output

* Made "Why" more generic. Expands statistics output. Removes time tying to stats map. Moves order event to correct location. Removes some debug lines.

* Adds some raw funky drawdown statistics 🎉

* End of day commit. experimentation leaves little code changes

* An attempt at expanding statistics. Need to have ones dedicated to exchange, asset, pair. Early work for having global map to track all the asset things to minimise all the maps throughout the application

* 🎉 ADDS MULTI CURRENCY SUPPORT TO FOR THE BACKTESTER 🎉 Can either execute strategies by assessing multiple currencies individually, or as a group and make strategic decisions on what currency to signal in. Adds new strat files to demonstrate

* End of day shenanigans. Moving codes around, making more fun stats. Expanding DCA strat to check if DCA is better than the market longer term

* Adds sharpe ratio and total stats for final output if more than one currency is considered

* Adds sortino ratio and test for validation

* Adds information ratio

* Adds calmar ratio

* Adds CAGR

* Slims down the statistics file to only include my work. Updates everything to use interfaces rather than direct code references to make it easier to swap out codes. Begins looking at serialising statistics for reports

* More neatening. Removal of old FAKE tests. Can now output a report in JSON

* End of day commit. Creation of reporting. Uses tradingview charting library and some basic bootstrap CDN to render content nicely. Will be updating everything to have a special kline item to annotate chart results

* Minor formatting changes before all the reviews

* End of day commit. Expands reporting to have an enhanced candle. These candles contain metadata on whether an order has been placed and to mark charts appropriately. This will be expanded to have all the stats and make it pretty

* Extra code I forgot to commit!

* Fixes an issue where data cannot render above 1,100 candles by stopping it from rendering more than that..

* End of day commit. There is no inclusivity with candle requests and I cant figure it out right now.

* Fixes issue with missing data by adding events when data isnt present and classifying it. Adds new way for klines to verify data with a bit more clarity

* Completes report generation

* Improves cagr. removes butts. Replaces old kline function with new supercalc

* Adds readme templates and files across whole backtester. Renames 420rsi to more appropriate name. Moves interfaces to common

* Some extra documentation

* New header

* Adds some nice coverage to backtest.go. Updats readmes to use new backtester header template

* End of day crappy test commit

* Adds report coverage... Somewhat. Adds template path and output path to allow custom properties and easier testing. Fixes interface duplication

* Adds some lame tests.

* Fixes test

* Adds coverage to the exchange event handler

* Minor test changes

* Fixes slippage calculations based on buying and selling. Adds more tests to compliance and holdings

* Rejiggles risk assessment to properly consider leverage if it were ever to be implemented fully. Removes bot dependency and adds coverage to the risk package

* Expands coverage to sizing

* Rejiggles code to add coverage for the portfolio package and its compatriots.

* Adds additional testing to the backtester along with some data gathering tests

* Tried and failed attempt to expand testing for the database.

* Adds testing for kline, data, statistics

* into the 70%s of coverage! Adds tests for base, DCA, statistics

* Adds test coverage of strategies

* Adds test coerage to statistics. updates template generation to not require CurrencyStatistics to have EAP. Removes EAP from currencystatistics

* Adds coverage to currencystatistics.go BUT ITS NOT COMPLETE

* 86% coverage wow. Fixes 2 tests

* Fixes data races due to engine dependency craziness. Changes order manager to not have a global dependency

* Completes currencystatistics test coverage

* Some linting fixes

* Adds new documentation to the bakctester config. Updates how risk leverage/ratios work with a single map.

* Minor documentation changes. Its difficult to describe how it all works

* Redefines strats and strat tests. Adds some really light documentation

* Updates some basic documentation.

* Fixes lazy bugs

* Fixes bug in fill event processing. Fixes bug in statistics crashing. Fixes report generation. Fixes multi-currency processing to still process non-errored signals

* More documentation.

* Fixes ALL LINTING ISSUES

* Cuts off unnecessary limbs/interface functions. linting. Adding comments to all functions. Adding ability to use whalebomb to calculate slippage for live orders. Adds testing for it too. Simplifies adding events to statistics.

* Removes a weird overlap of holding features that made no sense and the writer of those functions should be ASHAMED. Adds additional documentation

* Fixes issue with data being outside ranges. Adds some extra validation to areas where people can mess around. Makes generating configs easier with consistent dates. Adds more documentation. Cleans up okex/okcoin implementation to some functions since people aren't understanding that they share a based okgroup and that anything that is the same between two functions only needs to be written once...................... Also fixes some bad gct script code

* Updated image and slight change to readme

* Removes unused code. Fixes up verbose and removes old comment

* Fixes issues with data validation for other data sources. Fixes bad reference in template

* Fixes missing data problem for last candle considered missing. Fixes issue where fill order crashes when sizing error occurs. Adds documentation

* Fixes issue with drawdown calculations. Fixes live data usage

* Adds some comments for good measure

* Default strat fix

* Fixes surprise linting issues

* gofmt

* New linting issue with every commit

* Fixes testing. Adds new config setting to set a custom gocryptotrader config path. Updates config tests to use dryrun. Results now include the nickname in the file for easier identification

* Fixes live testing bitstamp. Fixes some template issues. Adds comments.

* Updates max drawdown calculation to go peak vs trough. Fixes minor return issue. Removes unnecessary Data implementations. Removes weird verbose false. Fixes holdings calculations for boughtvalue. Removes Swingholder and just uses Swing. Fixes time calculation issue in kline

* End of day commit that breaks things. Fixes issue with documentation generation only going one space deep. Adds exchange name to warnings of missing candle data. Renames missing candle data function. Adds some testing to kline functions. Adds new ability to size modified orders to portfolio allowance. Addresses defer close and other small nits. Fixes slow loop

* End of day commit. There are too many mini changes to list. DateType to int. Default switch case. Returning earlier. Nil returns instead of ok. High low price in data, now used in max drop down. Missing data shown in the report.

* End of day commit moving things from stats to maths.

* Move the rest to math package and add testing

* Ammends slippage calculations for live. Adds sizing funds to order event. Improves CAGR calculation

* Mini fix commit for test

* End of day mini change for documentation

* Fixes in documentation and expanded error messages. Pretties up the report

* minor adjustments to sharpe ratio and other ratio calculations

* Fixes test by taking it out back. linting

* Fixes tests

* Fixes some tests, addresses some poor nits

* More test and lint fixes

* Fixes binance translation issue

* Further craziness into reducing the concurrent test issues

* lint

* Mini fix

* Geometric average added and tested. Adjusts application to support it. End of day experiementation with negative geometric mean. Fixes typo in currencystatistics package name

* Fixes geometric calculation. Adds sweet CMD logo

* fixes geometric mean 😆 can now disable logo output if you hate everything good in life

* lint

* Should fix test in appveyor by not being nil

* Fixes chance of getting no trades error. Maybe making nil events in the test will stop this poorly formed appveyor error

* Forgotten Y tail

* Check-ch-check-check-check-ch-check it out, minimising stutter is what its all about... Also provides more verbose error messages

* de-ooopsies the whoopsie

* Attempts to further address race issues when using global logs during start stop process

* Includes a copy of the logger itself when logging so that no log.Debug action can create a data race upon being changed globally

* Reduces bot usage further

* Removes sharpie from b-acktester

* comments, renames and bears, oh my!

* Fixes git merge issues/tests. Splits average calculation into their own functions. Clarifies math function and sell position comments. Removes taker fee from final report. Adds warning when maker and taker aren't appropriately set. Fixes config testing issue where the config was saved when running exchange_template tests. Adds new test to ensure the testconfig isn't changed unnecessarily

* More why to reason

* Remove test due to hash discrepancy.

* Updates maths to use errors. Updates tests to support it.

* Fixes error handling for some packages. Uses position value instead of position size. Fixes leverage ratio work. Removes extra binance windows

* Removes references to "multi currency" to shiny new verbiage "simultaneous processing"

* Fixes issue with extra data be appended and then declared missing

* Removes redundant code via code removal

* Does a larger transition to using error types. Addresses math related nits

* eat a mint while you lint

* Completes err definition sweep

* replaces over 80 instances of the same typo!

* Renames more properties with Maximum ratios. Adds examples to config readme. Updates config maker takers. Adds cool kline error

* Adds 'InclusiveEndDate' config property to API and Database datas. Adds testing for it. Updates readme for it

* splint

* Minor naming fix. Minor drawdown fix. Attempts to lower the bot usage when heaps of candles are requested.

* Large data set processing improvements

* Speeds up backtesting processing. Ensures rate limits are set

Processing of most events is done in a linear fashion. So functions that
relied on checking an events time for example, will now check the latest
before processing every interval. The functions will still work normally
in the event that someone wishes to use them out of order, but for
general backtesting, it greatly speeds up all processing.

Further, rather than comparing times all the time, I've introduced
offsets for comparisons of ints for events and with candle data tests

* Fixes build issue

* Adds committed funds stat. Adds config goal

Committed funds are calculated as the total amount of money currently in position
It allows for a strategist to get the maximum returns for the smallest funds

The goal function is to allow a strategist to set a goal description

* Fixes data race

* Adds unfinished config builder application

* End of day broken commit

I focussed on too many things at once and there are many things left to resolve

* Fixees panics

* Finishes config builder

* Fixes order manager start/stop. Improves config manager

* Fixes writefile reference

* Adds some extra readme

* Makes a more user friendly config builder. Fixes initial nil. Adds more order size reasons

* lint

* Adds warnings for when data is missing and ratios will be skewed

* bodMISSED bodmas

* Does not consider initial entry in performance calculations

Adds strategy description field
Adds cost basis to chart
Fixes time rendering on default configs

* Fixes bug in ratio calculations

* saveConfig := !(!false != !true) == true

* lint

* Fixes start end single day drawdowns. Expands cmd drawdown explanation

* Comment on rounding, updated report rounding

* Addresses readme link issues

* Actually fixes readme references

* Should truly solve readme links....

* Includes filename for report log

* Fixes panics, reduces csv trade candle size, no more science

* Removes more science

* test123

* Adds extra config validation

* Fixes the date validation

* Shows smaller fees

* Changes perfectly cromulent error message to start >= end

Co-authored-by: Andrew Jackson <andrew@disvelop.net>
This commit is contained in:
Scott
2021-03-22 09:26:17 +11:00
committed by GitHub
parent b30d79b52d
commit 46f71952f9
238 changed files with 57157 additions and 2366 deletions

View File

@@ -0,0 +1,22 @@
{{define "backtester backtest" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The backtest package is the most important package of the GoCryptoTrader backtester. It is the engine which combines all elements.
It is responsible for the following functionality
- Loading settings from a provided config file
- Retrieving data
- Loading the data into assessable chunks
- Analysing the data via the `handleEvent` function
- Looping through all data
- Outputting results into a report
A flow of the application is as follows:
![workflow](https://user-images.githubusercontent.com/9261323/104982257-61d97900-5a5e-11eb-930e-3b431d6e6bab.png)
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,10 @@
{{define "backtester common" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
Common contains some basic data types which are used throughout.
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,19 @@
{{define "backtester config configbuilder" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
### What does the config builder do?
The config builder runs you through the process of creating a strategy config (`.strat`) file. Configs can also be generated via test code under `config_test.go`.
Once the config is created, when running the backtester, you can reference it via `go run . -configPath=(path-to-strat-file)`
### How do I run it?
`go run .`
### Anything else?
The config builder will ask you all the necessary questions required to create a config file. If there is anything confusing, feel free to ask a question in our Slack group or open an issue!
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,18 @@
{{define "backtester config examples" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
Current Config Examples:
| Config | Description |
| --- | ------ |
| dollar-cost-average.strat | A simple dollar cost average strategy which makes a purchase on every candle. |
| dollar-cost-average-live.strat | Using the same dollar cost average strategy, but runs the analysis against live candles |
| dollar-cost-average-multi-currency-assessment.strat | This strategy will assess multiple currencies in the one `OnSignals` function, however, it also just simply makes a purchase on every candle |
| dollar-cost-average-multiple-currencies.strat | This runs the same strategy against multiple currencies independently |
| rsi.strat | Runs a strategy using rsi figures to make buy or sell orders based on market figures |
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,133 @@
{{define "backtester config" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
### What does the config package do?
The config package contains a set of structs which allow for the customisation of the GoCryptoTrader Backtester when running.
The GoCryptoTrader Backtester runs from reading config files (`.strat` files by default under `/examples`).
### What does Simultaneous Processing mean?
GoCryptoTrader Backtester config files may contain multiple `ExchangeSettings` which defined exchange, asset and currency pairs to iterate through a period of time.
If there are multiple entries to `ExchangeSettings` and SimultaneousProcessing is disabled, then each individual exchange, asset and currency pair candle event is evaluated individually and does not know about other exchange, asset and currency pair data events. It is a way to test a singular strategy against multiple assets simultaneously. But it isn't defined as Simultaneous Processing
Simultaneous Signal Processing is a setting which allows multiple `ExchangeSettings` data events for a candle event to be considered simultaneously. This means that you can check if the price of BTC-USDT is 5% greater on Binance than it is on Kraken and choose to make signal a BUY event for Kraken and not Binance.
It allows for complex strategical decisions to be made when you consider the scope of the entire market at a given time, rather than in a vacuum when SimultaneousSignalProcessing is disabled.
### How do I customise the GoCryptoTrader Backtester?
See below for a set of tables and fields, expected values and what they can do
#### Config
| Key | Description |
| --- | ------|
| Nickname | A nickname for the specific config. When running multiple variants of the same strategy, use the nickname to help differentiate between runs |
| Goal | A description of what you would hope the outcome to be. When verifying output, you can review and confirm whether the strategy met that goal |
| CurrencySettings | Currency settings is an array of settings for each individual currency you wish to run the strategy against. |
| StrategySettings | Select which strategy to run, what custom settings to load and whether the strategy can assess multiple currencies at once to make more in-depth decisions |
| PortfolioSettings | Contains a list of global rules for the portfolio manager. CurrencySettings contain their own rules on things like how big a position is allowable, the portfolio manager rules are the same, but override any individual currency's settings |
| StatisticSettings | Contains settings that impact statistics calculation. Such as the risk-free rate for the sharpe ratio |
| GoCryptoTraderConfigPath | The filepath for the location of GoCryptoTrader's config path. The Backtester utilises settings from GoCryptoTrader. If unset, will utilise the default filepath via `config.DefaultFilePath`, implemented [here](/config/config.go#L1460) |
#### Currency Settings
| Key | Description | Example |
| --- | ------- | ----- |
| ExchangeName | The exchange to load. See [here](https://github.com/thrasher-corp/gocryptotrader/blob/master/README.md) for a list of supported exchanges | `Binance` |
| Asset | The asset type. Typically, this will be `spot`, however, see [this package](https://github.com/thrasher-corp/gocryptotrader/blob/master/exchanges/asset/asset.go) for the various asset types GoCryptoTrader supports| `spot` |
| Base | The base of a currency | `BTC` |
| Quote | The quote of a currency | `USDT` |
| InitialFunds | The funds that the GoCryptoTraderBacktester has for the specific currency | `10000` |
| Leverage | This struct defines the leverage rules that this specific currency setting must abide by | `1` |
| BuySide | This struct defines the buying side rules this specific currency setting must abide by such as maximum purchase amount | - |
| SellSide | This struct defines the selling side rules this specific currency setting must abide by such as maximum selling amount | - |
| MinimumSlippagePercent | Is the lower bounds in a random number generated that make purchases more expensive, or sell events less valuable. If this value is 90, then the most a price can be affected is 10% | `90` |
| MaximumSlippagePercent | Is the upper bounds in a random number generated that make purchases more expensive, or sell events less valuable. If this value is 99, then the least a price can be affected is 1%. Set both upper and lower to 100 to have no randomness applied to purchase events | `100` |
| MakerFee | The fee to use when sizing and purchasing currency | `0.001` |
| TakerFee | Unused fee for when an order is placed in the orderbook, rather than taken from the orderbook | `0.002` |
| MaximumHoldingsRatio | When multiple currency settings are used, you may set a maximum holdings ratio to prevent having too large a stake in a single currency | `0.5` |
#### Strategy Settings
| Key | Description | Example |
| --- | ------- | --- |
| Name | The strategy to use. | `rsi` |
| UsesSimultaneousProcessing | This denotes whether multiple currencies are processed simultaneously with the strategy function `OnSimultaneousSignals`. Eg If you have multiple CurrencySettings and only wish to purchase BTC-USDT when XRP-DOGE is 1337, this setting is useful as you can analyse both signal events to output a purchase call for BTC. | `true` |
| CustomSettings | This is a map where you can enter custom settings for a strategy. The RSI strategy allows for customisation of the upper, lower and length variables to allow you to change them from 70, 30 and 14 respectively to 69, 36, 12 | `"custom-settings": { "rsi-high": 70, "rsi-low": 30, "rsi-period": 14 } ` |
#### PortfolioSettings
| Key | Description |
| --- | ------- |
| Leverage | This struct defines the leverage rules that this specific currency setting must abide by |
| BuySide | This struct defines the buying side rules this specific currency setting must abide by such as maximum purchase amount |
| SellSide | This struct defines the selling side rules this specific currency setting must abide by such as maximum selling amount |
#### StatisticsSettings
| Key | Description | Example |
| --- | ----------- | ------- |
| RiskFreeRate | The risk free rate used in the calculation of sharpe and sortino ratios | `0.03` |
#### APIData
| Key | Description | Example |
| --- | ----------- | ------- |
| DataType | Choose whether `candle` or `trade` data is used. If trades are used, they will be converted to candles | `trade` |
| Interval | The candle interval in `time.Duration` format eg set as`15000000000` for a value of `time.Second * 15` | `15000000000` |
| StartDate | The start date to retrieve data | `2021-01-23T11:00:00+11:00` |
| EndDate | The end date to retrieve data | `2021-01-24T11:00:00+11:00` |
| InclusiveEndDate | When enabled, the end date's candle is included in the results. ie `2021-01-24T11:00:00+11:00` with a one hour candle, the final candle will be `2021-01-24T11:00:00+11:00` to `2021-01-24T12:00:00+11:00` | `false` |
#### CSVData
| Key | Description | Example |
| --- | ----------- | ------- |
| DataType | Choose whether `candle` or `trade` data is used. If trades are used, they will be converted to candles | `candle` |
| Interval | The candle interval in `time.Duration` format eg set as`15000000000` for a value of `time.Second * 15` | `15000000000` |
| FullPath | The file to load | `/data/exchangelist.csv` |
#### DatabaseData
| Key | Description | Example |
| --- | ----------- | ------- |
| DataType | Choose whether `candle` or `trade` data is used. If trades are used, they will be converted to candles | `trade` |
| Interval | The candle interval in `time.Duration` format eg set as`15000000000` for a value of `time.Second * 15` | `15000000000` |
| StartDate | The start date to retrieve data | `2021-01-23T11:00:00+11:00` |
| EndDate | The end date to retrieve data | `2021-01-24T11:00:00+11:00` |
| ConfigOverride | Override GoCryptoTrader's config database data with custom settings | `true` |
| InclusiveEndDate | When enabled, the end date's candle is included in the results. ie `2021-01-24T11:00:00+11:00` with a one hour candle, the final candle will be `2021-01-24T11:00:00+11:00` to `2021-01-24T12:00:00+11:00` | `false` |
#### LiveData
| Key | Description | Example |
| --- | ----------- | ------- |
| DataType | Choose whether `candle` or `trade` data is used. If trades are used, they will be converted to candles | `candle` |
| Interval | The candle interval in `time.Duration` format eg set as`15000000000` for a value of `time.Second * 15` | `15000000000` |
| APIKeyOverride | Will set the GoCryptoTrader exchange to use the following API Key | `1234` |
| APISecretOverride | Will set the GoCryptoTrader exchange to use the following API Secret | `5678` |
| APIClientIDOverride | Will set the GoCryptoTrader exchange to use the following API Client ID | `9012` |
| API2FAOverride | Will set the GoCryptoTrader exchange to use the following 2FA seed | `hello-moto` |
| RealOrders | Whether to place real orders. You really should never consider using this. Ever ever. | `true` |
##### Leverage Settings
| Key | Description | Example |
| --- | ----------- | ------- |
| CanUseLeverage | Allows the use of leverage | `false` |
| MaximumOrdersWithLeverageRatio | If the ratio of leveraged orders for a currency exceeds this, the order cannot be placed | `0.5` |
| MaximumLeverageRate | Orders cannot be placed with leverage over this amount | `100` |
##### Buy/Sell Settings
| Key | Description | Example |
| --- | ----------- | ------- |
| MinimumSize | If the order's quantity is below this, the order cannot be placed | `0.1` |
| MaximumSize | If the order's quantity is over this amount, it cannot be placed and will be reduced to the maximum amount | `10` |
| MaximumTotal | If the order's price * amount exceeds this number, the order cannot be placed and will be reduced to this figure | `1337` |
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,13 @@
{{define "backtester data kline api" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
This package is responsible for the loading of kline data via the API. It can retrieve candle data or trade data which is converted into candle data.
This package uses existing GoCryptoTrader exchange implementations.
See individual exchange implementations [here](/exchanges) and the interface used [here](/exchanges/interfaces.go)
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,35 @@
{{define "backtester data kline csv" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
This package is responsible for the loading of kline data via a CSV file. It can retrieve candle data or trade data which is converted into candle data.
### CSV Format
#### Candle based CSV
| Field | Example |
| ----- | -------- |
| Timestamp | 1546300800 |
| Volume | 3 |
| Open | 1335 |
| High | 1338 |
| Low | 1336 |
| Close | 1337 |
Additionally, you can view an example under `./testdata/binance_BTCUSDT_24h_2019_01_01_2020_01_01.csv`
#### Trade based CSV
| Field | Example |
| ----- | -------- |
| Timestamp | 1546300800 |
| Price | 1337 |
| Amount | 420.69 |
Additionally, you can view an example under `./testdata/binance_BTCUSDT_24h-trades_2020_11_16.csv`
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,19 @@
{{define "backtester data kline database" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
This package is responsible for the loading of kline data via a user's existing GoCryptoTrader database. It can load existing data from the `candles` and `trades` tables.
For more information on the GoCryptoTrader database, read [this readme](/database/README.md).
Ensure that your database has data and has been seeded with exchanges. For more information on this, please see [this readme](/cmd/dbseed/README.md).
### Database credentials
#### Defaults
The default database will be loaded from your GoCryptoTrader config. See [this](/database) for database configuration and implementation.
#### Overriding the GoCryptoTrader config
Database configuration details can be overridden in the `.strat` config file to allow other sources to be used and not rely on existing GoCryptoTrader configuration. See [this readme](/backtester/config/README.md) for details on config customisation
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,13 @@
{{define "backtester data kline live" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
This package will retrieve data for the backtester via continuous requests to live endpoints
## Important notice
Live trading is not fully implemented and you should never consider setting `RealOrders` to `true` in a config. *Past performance is no guarantee of future results*
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,15 @@
{{define "backtester data kline" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
When loading data for the kline, it can come from two sources: candles or trades. In the config they are represented as `common.CandleStr` or `common.TradeStr` respectively.
Candle data represents the opening, closing, highest, lowest prices of a given timespan (interval) along with the volume (amount traded) during that same period. You can read more about candles [here](https://www.investopedia.com/terms/c/candlestick.asp). This data is utilised throughout the GoCryptoTrader Backtester in order to make informed strategic decisions.
Trade data represents the raw trading data on an exchange. Every buy or sell action for the given currency. When trading data is used for the GoCryptoTrader Backtester, it is converted into candle data at the interval you specify. This allows for custom candle intervals not provided by an exchange's API and thus has a greater amount of flexibility in backtesting strategies.
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,16 @@
{{define "backtester data" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The data package defines and implements a base version of the `Streamer` interface which is part of the `Handler` interface. These interfaces allow for the translation of data into individual intervals to be accessed and assessed as part of the `backtest` package.
This is a base implementation, the more proper implementation that is used throughout the backtester is under `./kline`
This can also be used to implement other means to load data for the backtester to process, however kline is currently the only supported method.
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,12 @@
{{define "backtester eventhandlers eventholder" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The event holder is a simple interface implementation which allows the backtester to iterate over the event queue.
The event holder is based on the `EventHolder` interface and is implemented by `Holder`.
It is used by `backtest.Backtester` and it accepts appending any struct which implements the `common.EventHandler` interface, eg `order.Order`
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,24 @@
{{define "backtester eventhandlers exchange" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The exchange eventhandler is responsible for calling the `engine` package's `ordermanager` to place either a fake, or real order on the exchange via API.
The following steps are taken for the `ExecuteOrder` function:
- Calculate slippage. If the order is a sell order, it will reduce the price by a random percentage between the two values. If it is a buy order, it will raise the price by a random percentage between the two values
- If `RealOrders` is set to `false`:
- It will estimate the slippage based on what is in the config file under `min-slippage-percent` and `max-slippage-percent`.
- It will be sized within the constraints of the current candles OHLCV values
- It will generate the exchange fee based on what is stored in the config for the exchange asset currency pair
- If `RealOrders` is set to `true`, it will use the latest orderbook data to calculate slippage by simulating the order
- Place the order with the engine order manager
- If `RealOrders` is set to `false` it will submit the order with no calls to the exchange's API, use no API credentials and it will always pass
- If `RealOrders` is set to `true` it will submit the order via the exchange's API and if successful, will be stored in the order manager
- If an order is successfully placed, a snapshot of all existing orders in the run will be captured and store for statistical purposes
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,20 @@
{{define "backtester eventhandlers exchange slippage" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
Slippage refers to the difference between the expected price of a trade and the price at which the trade is executed. Slippage is used here to simulate what would occur if trading was live as no perfect conditions exist for placing orders.
Slippage is calculated in two ways in the GoCryptoTrader Backtester
### If `RealOrders` is `true`
- The orderbook is frequently requested during live cycle candle retrieval
- When the order is being calculated in the `ExecuteOrder` eventhandler, it will use the orderbook to simulate placing the order and adjust the order price
### If `RealOrders` is `false`
- The `min-slippage-percent` and `max-slippage-percent` values for the specific exchange, asset and currency pair will be used as bounds to simulate an orderbook using a random number
- If it is a buy order, it will raise the price by a random percentage between the two values
- If the order is a sell order, it will reduce the price by a random percentage between the two values
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,11 @@
{{define "backtester eventhandlers portfolio compliance" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The compliance manager is used to store all events at each time interval. When debugging the backtester or wanting to audit backtesting results, you can inspect every single action that has occurred during the backtesting run
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,12 @@
{{define "backtester eventhandlers portfolio holdings" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
Holdings are used to calculate the holdings at any given time for a given exchange, asset, currency pair. If an order is placed, funds are removed from funding and placed under assets.
Every data event will update and calculate holdings value based on the new price. This will allow for statistics to be easily calculated at the end of a backtesting run
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,34 @@
{{define "backtester eventhandlers portfolio" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The portfolio is one of the most critical packages in the GoCryptoTrader Backtester. It is responsible for making sure that all orders, simulated or otherwise are within all defined risk and sizing rules defined in the config.
The portfolio receives three kinds of events to be processed: `OnSignal`, `OnFill` and `Update`
The following steps are taken for the `OnSignal` function:
- Retrieve previous iteration's holdings data
- If a buy order signal is received, ensure there are enough funds
- If a sell order signal is received, ensure there are any holdings to sell
- If any other direction, return
- The portfolio manager will then size the order according to the exchange asset currency pair's settings along with the portfolio manager's own sizing rules
- In the event that the order is to large, the sizing package will reduce the order until it fits that limit, inclusive of fees.
- When an order is sized under the limits, an order event cannot be raised an no order will be submitted by the exchange
- The portfolio manager's sizing rules override any CurrencySettings' rules if the sizing is outside the portfolio manager's
- The portfolio manager will then assess the risk of the order, it will compare existing holdings and ensures that if an order is placed, it will not go beyond risk rules as defined in the config
- If the risk is too high, the order signal will be changed to `CouldNotBuy`, `CouldNotSell` or `DoNothing`
- If the order is deemed appropriate, the order event will be returned and appended to the event queue for the exchange event handler to run and place the order
The following steps are taken for the `OnFill` function:
- Previous holdings are retrieved and amended with new order information.
- The stats for the exchange asset currency pair will be updated to reflect the order and pricing
- The order will be added to the compliance manager for analysis in future events or the statistics package
The following steps are taken for the `Update` function:
- The `Update` function is called when orders are not placed, this allows for the portfolio manager to still keep track of pricing and holding statistics, while not needing to process any orders
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,14 @@
{{define "backtester eventhandlers portfolio risk" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The risk manager is responsible for ensuring that no order can be made if it is deemed too risky.
Risk is currently defined by ensuring that orders cannot have too much leverage for the individual order, overall with all orders in the portfolio as well as whether there are too many orders for an individual currency
See config package [readme](/backtester/config/README.md) to view the risk related fields to customise
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,14 @@
{{define "backtester eventhandlers portfolio size" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The sizing package ensures that all potential orders raised are within both the CurrencySettings limits as well as the portfolio manager's limits.
- In the event that the order is to large, the sizing package will reduce the order until it fits that limit, inclusive of fees.
- When an order is sized under the limits, an order event cannot be raised an no order will be submitted by the exchange
- The portfolio manager's sizing rules override any CurrencySettings' rules if the sizing is outside the portfolio manager's
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,13 @@
{{define "backtester eventhandlers" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} overview
Event handlers are responsible for taking in an event, analysing its contents and outputting another event to be handled. An individual candle is turned into a data event which handled via the strategy event handler. The strategy handler outputs a signal event, which the portfolio eventhandler will size and risk analyse before raising an order event. The event is then sent to the portfolio manager to determine whether there is appropriate funding, adequate risk and proper order sizing before raising an order event. The order event is taken to the exchange handler which will place the order and create a fill event.
Below is an overview of how event handlers are used
![workflow](https://user-images.githubusercontent.com/9261323/104982257-61d97900-5a5e-11eb-930e-3b431d6e6bab.png)
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,39 @@
{{define "backtester eventhandlers statistics currencystatistics" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
Currency Statistics is an important package to verify the effectiveness of your strategies.
It can calculate the following:
- Calmar ratio
- Information ratio
- Sharpe ratio
- Sortino ratio
- CAGR
- Drawdowns, both the biggest and longest
- Whether the strategy outperformed the market
- If the strategy made a profit
## Ratios
| Ratio | Description | A good range |
| ----- | ----------- | ------------ |
| Calmar ratio | It is a function of the fund's average compounded annual rate of return versus its maximum drawdown. The higher the Calmar ratio, the better it performed on a risk-adjusted basis during the given time frame, which is mostly commonly set at 36 months. | 3.0 to 5.0 |
| Information ratio| It is a measurement of portfolio returns beyond the returns of a benchmark, usually an index, compared to the volatility of those returns. The ratio is often used as a measure of a portfolio manager's level of skill and ability to generate excess returns relative to a benchmark | 0.40-0.60. Any positive number means that it has beaten the benchmark |
| Sharpe ratio | The Sharpe Ratio is a financial metric often used by investors when assessing the performance of investment management products and professionals. It consists of taking the excess return of the portfolio, relative to the risk-free rate, and dividing it by the standard deviation of the portfolio's excess returns | Any Sharpe ratio greater than 1.0 is good. Higher than 2.0 is very good. 3.0 or higher is excellent. Under 1.0 is sub-optimal |
| Sortino ratio | The Sortino ratio measures the risk-adjusted return of an investment asset, portfolio, or strategy. It is a modification of the Sharpe ratio but penalizes only those returns falling below a user-specified target or required rate of return, while the Sharpe ratio penalizes both upside and downside volatility equally. | The higher the better, but > 2 is considered good. |
| Compound annual growth rate | Compound annual growth rate is the rate of return that would be required for an investment to grow from its beginning balance to its ending balance, assuming the profits were reinvested at the end of each year of the investments lifespan | Any positive number |
## Arithmetic or versus geometric?
Both! We calculate ratios where an average is required using both types. The reasoning for using either is debated by finance and mathematicians. [This](https://www.investopedia.com/ask/answers/06/geometricmean.asp) is a good breakdown of both, but here is an extra simple table
| Average type | A reason to use it |
| ------------ | ------------------ |
| Arithmetic | The arithmetic mean is the average of a sum of numbers, which reflects the central tendency of the position of the numbers |
| Geometric | The geometric mean differs from the arithmetic average, or arithmetic mean, in how it is calculated because it takes into account the compounding that occurs from period to period. Because of this, investors usually consider the geometric mean a more accurate measure of returns than the arithmetic mean. |
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,13 @@
{{define "backtester eventhandlers statistics" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The statistics package is used for storing all relevant data over the course of a GoCryptoTrader Backtesting run. All types of events are tracked by exchange, asset and currency pair.
When multiple currencies are included in your strategy, the statistics package will be able to calculate which exchange asset currency pair has performed the best, along with the biggest drop downs in the market.
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,11 @@
{{define "backtester eventhandlers strategies base" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The strategy base file has basic implementations of the `strategies.Handler` interface. Add any functions that can be used across all strategies here.
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,13 @@
{{define "backtester eventhandlers strategies dollarcostaverage" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The dollar cost average is a strategy which is designed to purchase on _every_ data candle. Unless data is missing, all output signals will be to buy.
This strategy supports simultaneous signal processing, aka `config.StrategySettings.SimultaneousSignalProcessing` set to true will use the function `OnSignals(d []data.Handler, p portfolio.Handler) ([]signal.Event, error)`. This function, like the basic `OnSignal` function, will signal to buy on every iteration.
This strategy does not support customisation
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,27 @@
{{define "backtester eventhandlers strategies" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
Strategies are programmed instruction sets which act upon pricing data. After data has been loaded into the GoCryptoTrader, each tick is passed through your loaded strategy and is analysed in either the `OnSignal` function or the `OnSignals` function.
### Creating strategies
The level customisation allowed in a strategy is extensive. They are required to be written in Golang.
The strategy must adhere to the interface `strategies.Handler` by implementing the function signature `OnSignal(d data.Handler, _ portfolio.Handler) (signal.Event, error)`. The `data.Handler` allows you to access the current pricing information as well as all previous intervals. You can use this to feed any Technical Analysis package to create strategies based on market movements such as RSI (see `./strategies/rsi/rsi.go`). Strategies can also access the portfolio manager on signal(s) which allows analysis of existing holdings value, current orders and positions of other currencies in order to make complex decisions.
When outputting the `signal.Event`, you are not dictating the price of an order, but rather signalling to the portfolio manager what ideally should occur. These options are to buy, sell or do nothing. Additional signals are to flag missing data, handled via checking `d.HasDataAtTime(d.Latest().GetTime()` to prevent any issues from occurring down the line.
Additionally, you can utilise the `AppendWhy()` function to help understand what went into make a signalling decision when reviewing the results.
### What does Simultaneous Signal Processing mean?
GoCryptoTrader Backtester config files may contain multiple `ExchangeSettings` which defined exchange, asset and currency pairs to iterate through a period of time.
If there are multiple entries to `ExchangeSettings` and SimultaneousProcessing is disabled, then each individual exchange, asset and currency pair candle event is evaluated individually and does not know about other exchange, asset and currency pair data events. It is a way to test a singular strategy against multiple assets simultaneously. But it isn't defined as Simultaneous Processing
Simultaneous Signal Processing is a setting which allows multiple `ExchangeSettings` data events for a candle event to be considered simultaneously. This means that you can check if the price of BTC-USDT is 5% greater on Binance than it is on Kraken and choose to make signal a BUY event for Kraken and not Binance.
It allows for complex strategical decisions to be made when you consider the scope of the entire market at a given time, rather than in a vacuum when SimultaneousSignalProcessing is disabled.
### Loading strategies
Each strategy has a unique name and is to be added to the function `getStrategies()` in order to be recognised.
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,18 @@
{{define "backtester eventhandlers strategies rsi" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The RSI strategy utilises [the gct-ta RSI package](https://github.com/thrasher-corp/gct-ta) to analyse market signals and output buy or sell signals based on the RSI output.
This strategy does not support `SimultaneousSignalProcessing` aka [use-simultaneous-signal-processing](/backtester/config/README.md).
This strategy does support strategy customisation in the following ways:
| Field | Description | Example |
| --- | ------- | --- |
|rsi-high| The upper bounds of RSI that when met, will trigger a Sell signal | 70 |
|rsi-low| The lower bounds of RSI that when met, will trigger a Buy signal | 30 |
|rsi-period| The consecutive candle periods used in order to generate a value. All values less than this number cannot output a buy or sell signal | 14 |
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,11 @@
{{define "backtester eventtypes event" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The event event type is an important base for all other events. It allows for consistent information to be used across all events in order to track and make decisions. Any information that is shared between events should be added to this struct
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,23 @@
{{define "backtester eventtypes fill" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The Fill Event type contains details the outcome from attempting to make an order. Any slippage or pricing adjustment or fees are part of the fill event. If an order is placed, it is available to access on the event as well as in the compliance manager
The Fill Event Type is based on `common.EventHandler` and `common.Directioner` while also having the following custom functions
```
SetAmount(float64)
GetAmount() float64
GetClosePrice() float64
GetVolumeAdjustedPrice() float64
GetSlippageRate() float64
GetPurchasePrice() float64
GetExchangeFee() float64
SetExchangeFee(float64)
GetOrder() *order.Detail
```
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,10 @@
{{define "backtester eventtypes kline" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The Kline event type is used to store the candle data of an individual data event. It can be utilised to understand market conditions at a point in time and make decisions from there
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,23 @@
{{define "backtester eventtypes order" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The Order Event Type is an event type raised after the portfolio manager has passed all its checks and wishes to make an order
It is sent to the Exchange to process and if successful, will raise a Fill Event.
The Order Event Type is based on `common.EventHandler` and `common.Directioner` while also having the following custom functions
```
SetAmount(float64)
GetAmount() float64
IsOrder() bool
GetStatus() order.Status
SetID(id string)
GetID() string
GetLimit() float64
IsLeveraged() bool
```
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,13 @@
{{define "backtester eventtypes" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} overview
Event types are created after retrieving candle data. An individual candle is turned into a data event which is sent to the strategy for analysis. The event is then sent to the portfolio manager to determine whether there is appropriate funding, adequate risk and proper order sizing before raising an order event. The order event is taken to the exchange handler which will place the order and create a fill event. The fill event is used to update the portfolios individual holdings for analysis and decision making.
Below is an overview of how events are used
![workflow](https://user-images.githubusercontent.com/9261323/104982257-61d97900-5a5e-11eb-930e-3b431d6e6bab.png)
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,11 @@
{{define "backtester eventtypes signal" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The signal event is created as a result of a data event being analysed via a strategy. Typically, there are three types of signal that should be expected `buy`, `sell` and `donothing`. An example of this is demonstrated in the RSI strategy. However, other signals can be raised such as `MissingData`.
The signal event will contain data such as price, the direction as well as the reasoning for the signal decision with the `GetWhy()` function
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,72 @@
{{define "backtester" -}}
{{template "backtester-header" .}}
# GoCryptoTrader Backtester
An event-driven backtesting tool to test and iterate trading strategies using historical or custom data.
## Features
- Works with all GoCryptoTrader exchanges that support trade/candle retrieval. See [candle readme](/docs/OHLCV.md) and [trade readme](/exchanges/trade/README.md) for supported exchanges
- CSV data import
- Database data import
- Proof of concept live data running
- Can run strategies against multiple cryptocurrencies
- Can run strategies that can assess multiple currencies simultaneously to make complex decisions
- Dollar cost strategy implementation
- RSI strategy implementation
- Rules customisation via config `.strat` files
- Strategy customisation without requiring recompilation. For example, customising RSI high, low and length values via config `.strat` files.
- Report generation
- Portfolio manager to help size orders based on config rules, risk and candle volume
- Order manager to place orders with customisable slippage estimator
- Helpful statistics to help determine whether a strategy was effective
- Compliance manager to keep snapshots of every transaction and their changes at every interval
## How does it work?
- The application will load a `.strat` config file as specified at runtime
- The `.strat` config file will contain
- Start & end dates
- The strategy to run
- The candle interval
- Where the data is to be sourced ([API](/backtester/data/kline/api/README.md), [CSV](/backtester/data/kline/csv/README.md), [database](/backtester/data/kline/database/README.md), [live](/backtester/data/kline/live/README.md))
- Whether to use trade or candle data ([readme](/backtester/data/kline/README.md))
- A nickname for the strategy (to help differentiate between runs/configs using the same strategy)
- The currency/currencies to use
- The exchange(s) to run against
- See [readme](/backtester/config/README.md) for a breakdown of all config features
- The GoCryptoTrader Backtester will retrieve the data specified in the config ([readme](/backtester/backtest/README.md))
- The data is converted into candles and each candle is streamed as a data event.
- The data event is analysed by the strategy which will output a purchasing signal such as `BUY`, `SELL` or `DONOTHING` ([readme](/backtester/eventtypes/signal/README.md))
- The purchase signal is then processed by the portfolio manager ([readme](/backtester/eventhandlers/portfolio/README.md)) which will size the order ([readme](/backtester/eventhandlers/portfolio/size/README.md)) and assess risk ([readme](/backtester/eventhandlers/portfolio/risk/README.md)) before sending it to the exchange
- The exchange order event handler will size to the candle data and run a slippage estimator ([readme](/backtester/eventhandlers/exchange/slippage/README.md)) and place the order ([readme](/backtester/eventhandlers/exchange/README.md))
- Upon an order being placed, the order is snapshot for analysis in both the statistics package ([readme](/backtester/eventhandlers/statistics/README.md)) and the report package ([readme](/backtester/report/README.md))
# Cool story, how do I use it?
To run the application using the provided dollar cost average strategy, simply run `go run .` from `gocryptotrader/backtester`. An output of the results will be put in the `results` folder.
# How do I create my own config?
There is a config generating helper application under `/backtester/config/configbuilder` to help you create a `.strat` file. Read more about it [here](/backtester/config/configbuilder/README.md). There are also a number of tests under `/config/config_test.go` which generate configs into the `examples` folder, which if you have code knowledge, can write your own configs programmatically.
# How do I create my own strategy?
Creating strategies requires programming skills. [Here](/backtester/eventhandlers/strategies/README.md) is a readme on the subject. After reading the readmes, please review the strategies [here](/backtester/eventhandlers/strategies/) to gain an understanding on how to write your own.
# How does it work technically?
- The readmes linked in the "How does it work" covers the main parts of the application.
- If you are still unsure, please raise an issue, ask a question in our Slack or open a pull request
- Here is an overview
![workflow](https://user-images.githubusercontent.com/9261323/104982257-61d97900-5a5e-11eb-930e-3b431d6e6bab.png)
# Important notes
- This application is not considered production ready and you may experience issues
- If you encounter any issues, you can raise them in our Slack channel or via Github issues
- **Past performance is no guarantee of future results**
- While an experimental feature, it is **not** recommended to **ever** use live trading and real orders
- **Past performance is no guarantee of future results**
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -0,0 +1,21 @@
{{define "backtester report" -}}
{{template "backtester-header" .}}
## {{.CapitalName}} package overview
The report package helps generates the output under the `results` folder.
As the application is run, many statistics such as purchase events are tracked. These events are utilised and enhanced in the report package in order to render an HTML report for easy comparison and historical strategy effectiveness.
The report utilises the following sweet technologies:
- go templating ([tpl.gohtml](tpl.gohtml))
- [mdbootstrap](https://mdbootstrap.com/)
- [lightweightcharts](https://github.com/tradingview/lightweight-charts/) by [TradingView](https://www.tradingview.com/)
Output example:
![example](https://user-images.githubusercontent.com/9261323/105283038-c124be00-5c03-11eb-88af-d67e727a8c16.png)
### Please click GoDocs chevron above to view current GoDoc information for this package
{{template "contributions"}}
{{template "donations" .}}
{{end}}

View File

@@ -236,6 +236,16 @@ func main() {
URL: "https://github.com/merkeld",
Contributions: 1,
},
{
Login: "CodeLingoTeam",
URL: "https://github.com/CodeLingoTeam",
Contributions: 1,
},
{
Login: "Daanikus",
URL: "https://github.com/Daanikus",
Contributions: 1,
},
}...)
if verbose {
@@ -423,7 +433,8 @@ func GetPackageName(name string, capital bool) string {
newStrings := strings.Split(name, " ")
var i int
if len(newStrings) > 1 {
i = 1
// retrieve the latest spacing to define the most childish package name
i = len(newStrings) - 1
}
if capital {
return strings.Title(newStrings[i])

View File

@@ -78,6 +78,7 @@ However, we welcome pull requests for any exchange which does not match this cri
+ OHLCV/Candle retrieval support. See [OHLCV](/docs/OHLCV.md).
+ Scripting support. See [gctscript](/gctscript/README.md).
+ Recent and historic trade processing. See [trades](/exchanges/trade/README.md).
+ Backtesting application. An event-driven backtesting tool to test and iterate trading strategies using historical or custom data. See [backtester](/backtester/README.md).
+ WebGUI (discontinued).
## Planned Features

View File

@@ -0,0 +1,15 @@
{{define "backtester-header" -}}
# GoCryptoTrader Backtester: {{.CapitalName}} package
<img src="/backtester/common/backtester.png?raw=true" width="350px" height="350px" hspace="70">
{{template "status" .NameURL}}
This {{.Name}} package is part of the GoCryptoTrader codebase.
## This is still in active development
You can track ideas, planned features and what's in progress on this Trello board: [https://trello.com/b/ZAhMhpOy/gocryptotrader](https://trello.com/b/ZAhMhpOy/gocryptotrader).
Join our slack to discuss all things related to GoCryptoTrader! [GoCryptoTrader Slack](https://join.slack.com/t/gocryptotrader/shared_invite/enQtNTQ5NDAxMjA2Mjc5LTc5ZDE1ZTNiOGM3ZGMyMmY1NTAxYWZhODE0MWM5N2JlZDk1NDU0YTViYzk4NTk3OTRiMDQzNGQ1YTc4YmRlMTk)
{{end}}