mirror of
https://github.com/d0zingcat/gocryptotrader.git
synced 2026-06-05 23:16:53 +00:00
backtester: Fix selling bug, add planned features list (#722)
* Fixes sell bug. Updates docs. Adds test * Doc fixes * reorder and lint * Lint again! * Minor improvement to ensure theoretical upsized orders don't exceed portfolio limits * Fixes test error * %vamoose! * Fixes defaulting to int
This commit is contained in:
Scott
GitHub
@@ -13,7 +13,7 @@ It is responsible for the following functionality
|
||||
|
||||
|
||||
A flow of the application is as follows:
|
||||
|
||||
|
||||
|
||||
|
||||
### Please click GoDocs chevron above to view current GoDoc information for this package
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
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
|
||||
|
||||
|
||||
|
||||
|
||||
### Please click GoDocs chevron above to view current GoDoc information for this package
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
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
|
||||
|
||||
|
||||
|
||||
|
||||
### Please click GoDocs chevron above to view current GoDoc information for this package
|
||||
|
||||
@@ -21,6 +21,20 @@ An event-driven backtesting tool to test and iterate trading strategies using hi
|
||||
- Helpful statistics to help determine whether a strategy was effective
|
||||
- Compliance manager to keep snapshots of every transaction and their changes at every interval
|
||||
|
||||
## Planned Features
|
||||
We welcome pull requests on any feature for the Backtester! We will be especially appreciative of any contribution towards the following planned features:
|
||||
|
||||
| Feature | Description |
|
||||
|---------|-------------|
|
||||
| Add quote-based portfolio funding feature | Funds are currently currency-pair based which is helpful for running the same strategy against many pairs simultaneously. This feature would allow for shared funding pool for an overarching strategy |
|
||||
| Add backtesting support for futures asset types | Spot trading is currently the only supported asset type. Futures trading greatly expands the Backtester's potential |
|
||||
| Example futures pairs trading strategy | Providing a basic example will allow for esteemed traders to build and customise their own |
|
||||
| Save Backtester results to database | This will allow for easier comparison of results over time |
|
||||
| Backtester result comparison report | Providing an executive summary of Backtester database results |
|
||||
| Currency correlation | Compare multiple exchange, asset, currencies for a candle interval against indicators to highlight correlated pairs for use in pairs trading |
|
||||
| Improve live trading functionality | Live trading is currently only a proof Of concept. Adding live support for running multiple currencies and running off orderbook data will allow for esteemed traders to use their backtested strategies |
|
||||
|
||||
|
||||
## How does it work?
|
||||
- The application will load a `.strat` config file as specified at runtime
|
||||
- The `.strat` config file will contain
|
||||
@@ -54,7 +68,7 @@ Creating strategies requires programming skills. [Here](/backtester/eventhandler
|
||||
- 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
|
||||
|
||||
|
||||
|
||||
|
||||
# Important notes
|
||||
|
||||
@@ -170,6 +170,11 @@ func main() {
|
||||
|
||||
// Github API missing contributors
|
||||
contributors = append(contributors, []Contributor{
|
||||
{
|
||||
Login: "tk42",
|
||||
URL: "https://github.com/tk42",
|
||||
Contributions: 2,
|
||||
},
|
||||
{
|
||||
Login: "daniel-cohen",
|
||||
URL: "https://github.com/daniel-cohen",
|
||||
@@ -251,6 +256,11 @@ func main() {
|
||||
URL: "https://github.com/CodeLingoBot",
|
||||
Contributions: 1,
|
||||
},
|
||||
{
|
||||
Login: "blombard",
|
||||
URL: "https://github.com/blombard",
|
||||
Contributions: 1,
|
||||
},
|
||||
}...)
|
||||
|
||||
if verbose {
|
||||
|
||||
@@ -41,7 +41,7 @@ For a breakdown of what a job consists of and what each parameter does, please r
|
||||
+ Modify the following example command to your needs: `.\gctcli.exe datahistory upsertjob --nickname=binance-spot-bnb-btc-1h-candles --exchange=binance --asset=spot --pair=BNB-BTC --interval=3600 --start_date="2020-06-02 12:00:00" --end_date="2020-12-02 12:00:00" --request_size_limit=10 --data_type=0 --max_retry_attempts=3 --batch_size=3`
|
||||
|
||||
### Candle intervals and trade fetching
|
||||
+ A candle interval is required for a job, even when fetching trade data. This is to appropriately break down requests into time interval chunks. However, it is restricted to only a small range of times. This is to prevent fetching issues as fetching trades over a period of days or weeks will take a significant amount of time. When setting a job to fetch trades, the allowable range is less than 4 hours and greater than 10 minutes. So an interval of 1 hour will then fetch an hour's worth of trade data.
|
||||
+ A candle interval is required for a job, even when fetching trade data. This is to appropriately break down requests into time interval chunks. However, it is restricted to only a small range of times. This is to prevent fetching issues as fetching trades over a period of days or weeks will take a significant amount of time. When setting a job to fetch trades, the allowable range is less than 4 hours and greater than 10 minutes.
|
||||
|
||||
### Application run time parameters
|
||||
|
||||
|
||||
Reference in New Issue
Block a user