Could use https://github.com/JuliaMath/DecFP.jl
but it states 50x slowdown...would need a PoC with some benchmarks to see how much a backtest would be affected

ccxt/ccxt#15852

There is https://github.com/JuliaCN/Py2Jl which could be used to bootstrap the julia base classes from python base classes.

Looking at the regex at https://github.com/ccxt/ccxt/blob/master/build/transpile.js seems like most of the translations are doable, translating the isinstance and is None ones from python, and the common ones from PHP, because julia lacks dotcall syntax

Basically all functions with arguments any combination of Strategy AssetInstance Order Trade etc... have "loose" signatures. Meaning for example that you could call them with arguments where the strategy refers to an exchange, and an asset refers to another...
They would have to be rewritten for example like:

function position!(
    s::IsolatedStrategy{Sim}, ai::MarginInstance, t::PositionTrade{P};
) where {P<:PositionSide}

to

function position!(
    s::Strategy{X,N,E,Isolated,C}, ai::AssetInstance{A,E,Isolated}, t::Trade{O,A,E,P};
) where {X,N,E<:ExchangeID,C,A<:AbstractAsset,O,P<:PositionSide}

OctoBot (ccxt based): https://github.com/Drakkar-Software/OctoBot-Tentacles/tree/master/Trading/Exchange
Humming bot connectors (non ccxt based): https://github.com/hummingbot/hummingbot/tree/master/hummingbot/connector/exchange

I am more inclined on using octo-bot ones since ccxt based, and ccxt added websockets recently anyway

v1

v1 is tagged
The test suite is mostly passing, although there are still 1 or 2 flapping tests.
The pre built images are on the docker registry

v1 will only receive bug fixes and new adhoc functions for better exchange support.

v2

v2 is not currently being worked on, this is a list of things that need to happen for a v2 release and other things that would be nice to have:

required

• Ccxt gets transpilation support for julia. The main goal of v2 would be to make python optional and not an hard dependency, so all the python ccxt handling would need to be removed
• Complete wrapping of the interal exchange api into a dedicated ExchangeApi module. Currently it is mostly split into the Exchanges and LiveMode modules. It is fine to model it over the ccxt api but this needs to happen to make ccxt swappable.
• Dependencies trimming: excluding plotting and optimization which are inevitably dependency heavy we could avoid pulling other packages like DataStructures and instead vendor the used container types. Also telegram support should be made optional.
• Reduce number of modules: some modules could be merged, like Lang,Misc,TimeTicks Data,Processing SimMode,Executors PaperMode,LiveMode
• With python made optional, it is worthwhile to perform an analysis for type instabilities using JET.jl

optional

• With the exchange api wrapped we can (and should) add the hummingbot gateway as addition exchange support
• Better test suite. Ccxt lacks a self hostable exchange api server for testing purposes which makes it neccessary to test against live exchange testnets this is annoying because of api keys, rate limits, and testnets going down every once in a while, all things causing tests to flap. Also julia mocking seems somewhat buggy, and although we mock some responses in a few tests, mocking can't be used everywhere because we also need to test async behaviour.
• Overhaul of AssetInstance trades history from a vector of trades to a dataframe, for reasoning see here
• simplify timeframes package to always and only use Millisecond as time unit
• reconstructing the orders/trades history from the exchange with leverage and margin. (Currently exchanges don't have apis for position history)
• rename: (abstract)asset -> (abstract)instrument, assetinstance -> market

Some strategies work based on past profitability, so they require a way to calc the profits of previous trades. Because ping pong does not make assumptions about execution of trades (buys and sells are not necessarily interleaved) a module for ensuring that the strategy executes only 1 trade at a time is required. And the method to track profitability should be implemented in such module

Remove the PairData type, and instead rely on DataFrames metadata for info.

Replace the current progressbar with Term.jl

• Watchers
• Sim/Paper/Live mode
• Cli
• Engine
• Executors
• Instances
• Collections
• OrderTypes
• Simulations
• Stats
• Strategies
• Plotting
• Exchanges
• Fetch

Hello,

According doc

https://github.com/panifie/PingPong.jl/blame/3ef7dd4cf48a9ff956ec53d3b4cf732fd8e18675/docs/src/index.md#L86

But

julia> const bn = scr.BinanceData
ERROR: UndefVarError: `scr` not defined

Any idea how to fix this?

how to use the package, how to get information, like profit, sharp ratio, and other stuffs in backtrader in python

backtest

• There are many repeated function calls like openat,closeat,etc... that could be memoized
• Consider either removing getproperty for asset instances and strategies or replace all dot accessors within SimMode with some getfield wrapper function. Because the getproperty accessor is slower than getfield if it is customized
• an alternative implementation for orders/trades would use arrays instead of structs to be more allocation friendly

watchers

• StructArrays or TypedTables could be used when fetching (streaming) ohlcv data feeds
• OHLCV watcher implementations parse the whole python dicts into named tuples (CcxtTrade, CcxtTicker), in cases where full parsing is not required, the python data should be parsed more lazily

other

• Scour the codebase for lazy use of @view/s on assignments, that should be replaced with copyto! (starting from Data)
• search/replace Period with FixedPeriod to see if union splitting improves performance
• Full specialization: many functions signatures are defined over generic types (non fully parametrized), benchmarks are needed to assert if full specialization is worth the extra compilation time / bin size

Hello,

Currently following documentation but

julia> using PingPong

julia> @environment!

julia> s = st.strategy(:Example)
Name: Example (Sim)
Config: No Margin, 10.0(USDT)(Base Size), 100.0(USDT)(Initial Cash)
Universe: 3 instances, 1 exchanges
Trades: 0 ~ 0(longs) ~ 0(shorts) ~ 0(liquidations)
Holdings: 0
Pending buys: 0
Pending sells: 0
USDT: 100.0 (on phemex) (Cash)
USDT: 100.0 (Total)

julia> pairs = im.raw.(s.universe.data.asset)
3-element Vector{SubString{String}}:
 "BTC/USDT"
 "ETH/USDT"
 "SOL/USDT"

julia> using Scrapers: Scrapers as scr

julia> const bn = scr.BinanceData
Scrapers.BinanceData

julia> bn.binancedownload(pairs)
ERROR: ArgumentError: No symbols found matching SubString{String}["BTC/USDT", "ETH/USDT", "SOL/USDT"]
Stacktrace:
 [1] binancedownload(syms::Vector{…}; zi::Data.ZarrInstance{…}, quote_currency::String, reset::Bool, kwargs::@Kwargs{})
   @ Scrapers.BinanceData /pingpong/Scrapers/src/binance.jl:239
 [2] binancedownload(syms::Vector{SubString{String}})
   @ Scrapers.BinanceData /pingpong/Scrapers/src/binance.jl:233
 [3] top-level scope
   @ REPL[7]:1
Some type information was truncated. Use `show(err)` to see complete types.

Although not really recommended, embedding python strategies is a very easy task.

Isolated margin

• Funding rate estimation (currently we just use higher trading fees)
• Updating margin of open positions
• Updating leverage of open positions (and also with pending orders)

Margin

• borrow/repay

Execution

• Take profit and stop loss attached to orders

The backtest could be made more interactive by either:

• (terminal) use a progress bar (which we already have used for other things like scrapers)
• (graphical) update a makie chart in realtime as the backtest progresses

• The split of buy/sell orders into long/short, which doubles every downstream type into long/short. This is necessary to support hedged position management, but I don't think I will ever implement it since I use isolated, so I might have just chosen to not support it and simplify the types
• The sign handling for long/short amounts. Initially It was all positive numbers, but then I thought turning the sign negative for shorts would reduce the amount of errors, maybe it did (?) but now a short sell gains "negative cash" and a short buy reduces negative cash to zero 😕
• The fully "expanded" orders and trades structures, that could be made more array friendly. This is covered here
• The exchange api creeping into many packages, now ccxt is kind of an hard dep
• Pythonisms creeping into the exchange api. If ever ccxt gets julia support, the switch to native julia will not be so trivial
• this issue being a glass half empty kind of issue

Make dockerfile with prebuilt packages, consider static compilation

The main goal of this would be to allow to backtesting runs on a GPU, and in particular allow to run backtests using online jupyter instances that offer GPU computing like colab or kaggle.
Since we mostly target online notebooks, and they are all nvidia, we would be using CUDA.jl

Making the backtest GPU compatible mostly means building structure adaptors for these types:

• Strategy
• Exchange
• AssetInstance
• DataFrame
• Context

The Exchange type is a wrapper for a ccxt exchange, it is already discouraged to call python from a strategy, and the backtest itself never calls any python code, so this is not an issue per se, however it should be made abudantly clear in the documentation that a GPUStrategy cannot use python code.

This is however not enough:
To achieve parallelizability we have to run 1 backtest per GPU core, which means that the strategy has to be implemented as a kernel, in particular the main ping! function and whatever the function calls, needs to be a kernel. Of course we should provide example implementations and warn about the complexities of gpu programming.

• cryptocompare
• alphavantage
• coincodex

A test should be done to compare loading times between a repository version where everything is imported from one main modules and compare it to the current multi project version

Split up dependencies for:

• plotting
• indicators/explorations

Symbols are currently parsed through some regex. We could instead query ccxt.market["info"]
Ccxt also provides the feeCurrency but is not necessarily useful for backtesting as much as for live trading

Write a pluto notebook to showcase features

currently all arrays are stored in a flat structure in the ZarrInstance main group, whereas they should be saved according to their path in a subgroup

Currently we only consider the executor under the pingpong model. That is that the strategy has to deal with its own data feeds.

If the pingpong model also accounted for data updates, a pong! call within the strategy could branch into a Watcher instance in live mode and a prefetched dataframe in sim mode.

However since a strategy has always carte blanche, the benefits of managing data for the strategy are very small (we can't manage every piece of data, so managing only a few doesn't improve the status quo).

Moreover the main ping! function works with a timestamp as primary input, so there is never any ambiguity on the time context of execution and whatever data the strategy uses, should already be time context aware because of this.

Hello,

Trality, a Python crypto trading bot will stop. See https://www.trality.com/blog/trality-winding-down-product
I'm considering moving to Julia and an open source trading environment.
Converting some Trality examples to PingPong.jl could help to attract new users.
Here are some examples https://gist.github.com/c0indev3l/855381f07865dfca079e8252e736ae35
and documentation https://docs.trality.com/

Kind regards

• make the Watcher an abstract subtype of the Rocket actor
• refactor watcher implementations as concrete subtypes of the Watcher abstract type

• Spread: always enabled
• Slippage: for large trades
• Market impact: for very large trades

Using watchers, when fetching candles, we call fetchOHLCV et similar, but in case candles are emulated we shouldn't call it, and instead process from trades directly since we already do it in other cases. So we have to ensure exc.has["fetchOHCLV"] is not emulated.