lychiyu/bbgo_origin
1
0
Fork 0
mirror of https://github.com/c9s/bbgo.git synced 2024-11-24 15:55:14 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

doc: add more details on series.md. add link from indicator.md

Browse Source
This commit is contained in:
zenix 2022-05-09 10:55:32 +09:00
parent f13571749d
commit fcc0f18463
2 changed files with 18 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/development/indicator.md
View File

@ -98,3 +98,7 @@ The `KLineWindowUpdater` interface is currently defined in `pkg/indicator/ewma.g
Once the implementation is done, run `go generate` to generate the callback functions of the indicator.
You should be able to implement your strategy and use the new indicator in the same way as `AD`.
#### Generalize
In order to provide indicator users a lower learning curve, we've designed the `types.Series` interface. We recommend indicator developers to also implement the `types.Series` interface to provide richer functionality on the computed result. To have deeper understanding how `types.Series` works, please refer to [doc/development/series.md](./series.md)

16
doc/development/series.md
View File

@ -5,7 +5,7 @@ In bbgo, we've added several interfaces to standardize the indicator protocol.
The new interfaces will allow strategy developers switching similar indicators without checking the code.
Signal contributors or indicator developers were also able to be benefit from the existing interface functions, such as `Add`, `Mul`, `Minus`, and `Div`, without rebuilding the wheels.
The series interface in bbgo borrows the concept of `series` type in pinescript that allow us to query data in time-based reverse order (data that created later will be the former object in series). Right now, based on the return type, we have two interfaces been defined in `pkg/types/indicator.go`:
The series interface in bbgo borrows the concept of `series` type in pinescript that allow us to query data in time-based reverse order (data that created later will be the former object in series). Right now, based on the return type, we have two interfaces been defined in [pkg/types/indicator.go](../../pkg/types/indicator.go):
```go
type Series interface {
@ -25,7 +25,19 @@ type BoolSeries interface {
}
```
Series were used almost everywhere in indicators to return the calculated numeric results, while the use of BoolSeries is quite limited. At this moment, we only use BoolSeries to check if some condition is fullfilled at some timepoint. For example, in `CrossOver` and `CrossUnder` functions if `Last()` returns true, then there might be a cross event happend on the curves at the moment.
Series were used almost everywhere in indicators to return the calculated numeric results, but the use of BoolSeries is quite limited. At this moment, we only use BoolSeries to check if some condition is fullfilled at some timepoint. For example, in `CrossOver` and `CrossUnder` functions if `Last()` returns true, then there might be a cross event happend on the curves at the moment.
#### Expected Implementation
The calculation could either be done during invoke time (lazy init, for example), or pre-calculated everytime when event happens(ex: kline close). If it's done during invoke time and the computation is CPU intensive, better to cache the result somewhere inside the struct. Also remember to always implement the Series interface on indicator's struct pointer, so that access to the indicator would always point to the same memory space.
#### Compile Time Check
We recommend developers to add the following line inside the indicator source:
```go
var _ types.Series = &INDICATOR_TYPENAME{}
// Change INDICATOR_TYPENAME to the struct name that implements types.Series
```
and if any of the method in the interface not been implemented, this would generate compile time error messages.