Nyepetake backtesting kanggo bot dagang crypto freqtrade.
Freqtrade Apa bot dagang crypto ing python. Aku biyen muter-muter karo garpu, ndandani sawetara kewan omo lan sawetara prilaku sing aku ora seneng. Ndhaptar kewan omo ing kene bakal mboseni, mula aku bakal ngomong babagan perkara sing dakanggep menarik.
FQT ora adhedhasar acara, adhedhasar loop. Apa tegese iki? Kita bisa ngomong babagan eksekutor (operasi langsung) utawa backtester. Ing kasus iki, loro-lorone adhedhasar loop.
Loops umume prasaja lan luwih gampang kanggo alesan karo, dibandhingake acara. Acara OTOH bisa nggawe model donya nyata luwih apik. Loops uga luwih gampang kanggo paralel dibandhingake acara, lan nindakake umume luwih cepet.
Backtesting adhedhasar loop bisa ditindakake bebarengan karo eksekutor urip. Iki tegese evaluasi mundur dadi bagean saka strategi dagang sampeyan. Nglakokake sistem backtesting adhedhasar acara urip katon kaya kekacoan kanggo kula. Iki amarga acara mbutuhake pemanggih wektu, nanging sajrone dagang langsung sampeyan mung duwe saiki, mula apa sing bakal sampeyan simulasi lan kepiye carane?
... bali menyang FQT, ing mode urip, proses pesenan ing daur ulang. Saben X detik takon ijol-ijolan kanggo nganyari. Iku nglacak:
daftar pasangan sing ngemot kabeh rega pungkasan kabeh aset (kanggo ijol-ijolan sing ndhukung)
data OHLCV anyar
status open order
Eksekusi langsung adhedhasar loop duwe masalah sing jelas. Iku sinkron. Yen sampeyan proses kanggo akeh pasangan eksekusi bakal kurang responsif, lan iterate kurang asring, lagging konco unfolding saka tumindak rega. Dadi, sanajan aku luwih seneng puteran kanggo backtesting, aku luwih seneng acara kanggo eksekusi langsung.
Kakurangan? Yen sampeyan nggunakake acara kanggo siji bab lan daur ulang kanggo liyane, iku luwih gampang kanggo model utawa paramèter saka strategi kanggo diverge lan ora cocog karo kasunyatan.
Argumentasi pertahananku nglawan iki yaiku terus-terusan ngevaluasi diri (backtesting) lan eksekusi langsung ngilangi masalah iki amarga bakal pungkasanipun nyelarasake.
FQT duwe akeh parameter konfigurasi lan akeh wektu bedane antarane bot lan strategi bakal dadi abu-abu amarga strategi kasebut ora bisa ngontrol carane pesenan ditindakake dening bot. Bot nangani "roi" yaiku kothak watesan rega bathi lan "stoploss trailing" sing padha, nanging ana kekurangane. Strategi kasebut mung nyedhiyakake parameter lan bot nindakake liyane. Aku ora penggemar iki.
Callbacks kanggo sinyal tuku lan adol. Dagang bakal kedadeyan adhedhasar sinyal sing dibalekake dening callback sing bakal ngitung sinyal ing kerangka data. Masalah karo iki sinyal sing statis; sampeyan mung bisa mbosenke ngetung dataframe 1 baris, lan feed sing kanggo bot, nanging ora bakal backtestable. Iki apik yen sampeyan ora ngormati backtesting sing akeh, kanggo saben dhewe.
Apa aku diowahi ing FQT kanggo nyoba kanggo nindakake kanggo likning sandi.
Filter dhaptar pasangan liyane . Kanthi nyuda jumlah pasangan sing bakal diproses ing saben pengulangan, sampeyan bakal nyuda beban kanthi biaya sawetara reaktivitas. Sampeyan isih bakal ngolah kabeh aset sing ana perdagangan mbukak, lan sawetara sing anyar. Dadi aku mbangun
A saringan shuffling mung milih pasangan kanthi acak.
Filter round robin kanggo ngulangake pasangan kanthi sithik.
A dhaftar statis, kanggo mbukak saka panyimpenan
Format data: Aku nambahake dhukungan kanggo hdf, parket lan zarr . Saka iki aku nemokake aku nggunakake zarr, thanks kanggo de / komprèsi data sing dibangun kanthi cepet. Luwih gampang tinimbang parket lan luwih ergonomis.
Ana Bunch saka njiwet liyane, kaya evaluasi sinyal podo aku pungkasanipun gutted metu nalika aku luwih fokus ing mbangun sinyal cepet, lan njiwet kanggo ngrancang lan config opsi, nanging padha ora ngremenaken.
Aku nyoba akeh versi backtesting kanggo nyepetake. Iku kabeh, ora kabeh, worth iku. Logika komputasi antarane operasi tuku lan jual nggunakake array numpy. Iku kaya muter tetris karo otak. Maksudku ngendi pamblokiran digawe saka materi werna abu-abu Panjenengan, lan sampeyan nyoba kanggo sijine bebarengan. Kene kita dhaptar
Tes backtest . Ing siji iki kita bakal nyoba kanggo ambruk dagang nggunakake mung array numpy. Juggling antarane aliran bener saka eksekusi tuku / adol, sinyal, stoploss, trailing stoploss, pitungan kothak roi, petungan roi bobot wektu. Kabeh karo array numpy, iku cukup kekacoan.
adhedhasar VBT Versi iki nyoba kanggo nggunakake vektorbtperpustakaan python adhedhasar numba kanggo nglakokaké backtest. Kaget, ora luwih cepet tinimbang versi numpy. Iku amarga kudu akeh konversi jinis menyang jinis kompatibel VBT, supaya kacepetan apa wae sing dipikolehi saka eksekusi ilang ing kana.
Looping liwat kisaran Iki minangka upaya pisanan nggunakake numba dhewe. Amarga numba bisa nelpon fungsi numpy native, Aku dicocogake framework backtest adhedhasar numpy kanggo bisa ing numba. Keuntungan kasebut sithik banget. Biaya sijine kabeh menyang array numpy ana bottleneck. Keuntungan sing diraih sawise iku minimal amarga sawise konversi numpy, eksekusi numpy wis cepet.
Looping liwat lilin Iki lan kanthi bener dadi sing pungkasan. Iku implementasine sing paling apik. Iku amarga pengulangan "prasaja" liwat lilin, kabeh dileksanakake ing fungsi numba jitted. Konsep iki prasaja, nanging ngleksanakake kabeh roi, lan logika stoploss nalika dealing with numba bug ora becik. Iku makarya cukup uga ing pungkasan, nanging sawise gunung incompatibilities numba aku kudu menek.
We ditambahaké uga sawetara fitur tambahan kanggo backtest, kaya panyebaran lan likuiditas pitungan, lan wektu kasebut sadurunge bobot roi.
Apa aku pengin backtester cepet? Amarga aku pengin mbukak akeh mau supaya aku bisa nemokake sing paling apik saka config parameter paling apik ... mesthi, disregarding sembarang konsep over-fitting, over-parametrization, lack-of-fokus, etc ... Ayo dhaptar apa sing dakgarap:
Ngirim proyek menyang buruh liyane (proses) cepet sabisa. Perbaikan pisanan yaiku ngganti cara kerja dikirim. Saka kirim N jobs lan ngenteni kabeh mau rampung, Aku ngganti proses kanggo feed proyek anyar sanalika sadurunge wis rampung. Ana masalah karo pendekatan iki Nanging. Optimization kaping pirang-pirang urutan. Sampeyan ora bisa ngerti endi titik saka spasi parameter kanggo mirsani, tanpa wis rampung ngitung sadurunge. Iki bener paling ora kanggo optimasi bayesian. Iki tegese yen kita nyoba nyoba anyar terus-terusan, kita ora bakal nambah telusuran sing akeh ing antarane optimasi, nanging telusuran bakal luwih mantep.
Kita bisa nggunakake optimizer liyane ora adhedhasar optimasi bayesian, kaya iki . Utawa mbukak N optimizers independen, supaya saben proses / optimizer bakal takon kanggo proyek anyar nggunakake sajarah dhewe, utawa opsional sajarah nuduhake karo kabeh liyane (sanajan iki bakal nggawe kabeh optimizers converge sawise sawetara wektu, kang bisa dadi becik properti, utawa ora, gumantung ing kasus).
Nuduhake pengamatan ing antarane kabeh proses kasebut minangka bencana total. Pickling lan unpikling dhaftar gedhe saka floats banget alon. Nalika telusuran terus maju, jumlah pengamatan mundhak, lan kabeh proses dadi luwih alon lan luwih alon nganti titik serialisasi mbutuhake wektu luwih akeh tinimbang evaluasi pengamatan. Iku alon-alon nggunakake proses manajer, file kosong, utawa sing dipetakan mem. Sing paling apik bang kanggo dhuwit pendekatan mulane dadi kanggo mbukak optimizers kapisah lan tau nuduhake pengamatan ing antarane wong-wong mau, supaya kabeh ing memori.
Nglacak status optimasi. Mbayangno nglakokake optimasi sajrone pirang-pirang jam, banjur ana sing nabrak lan sampeyan bakal ilang kabeh. Mesthi wae kita pengin ngindhari, mula kita nambahake logika nyimpen periodik . Iki minangka pembalap utama kanggo nambah dhukungan panyimpenan zarr, ngirit negara kanthi zarr sing luwih apik.
Visualisasi optimasi sing ditindakake. FQT wis duwe visualisasi sing apik kanggo optimasi mlaku. Aku apik marang iku. Aku kudu nggawe obyek kanggo makili saben pengamatan. Banjur aku bisa mbukak pangolahan kirim tambahan kaya normalisasi lan nyaring
Kanggo Validasi silang kita kudu pamisah data, lan aplikasi backtesting ing sawetara beda. Thanks kanggo usaha kita ing nelusuri negara optimasi, kita bisa nggunakake output saka validasi silang minangka winih kanggo proses optimasi liyane olahan ... kanggo overfit ... mesthi.
Logika optimasi tambahan. Kanggo entuk max churn kita uga kudu nyathet sawetara masalah:
Kadhangkala konfigurasi parameter bisa uga gagal, lan pangoptimal bisa macet, mula kita kudu nglacak pengamatan sing gagal, lan pungkasane miwiti maneh, utawa kabeh pangoptimal.
Amarga kita nindakake macem-macem pangoptimal, kita kudu nglacak pangoptimal sing ngasilake pengamatan.
Thanks kanggo backtester cepet, lan optimizer paralel, kita nindakake akeh pengamatan, FQT bakal nyithak saben pengamatan nalika rampung. Kita kudu batch pengamatan sadurunge print mau, supaya kita bakal print a"tableful" saka wong-wong mau tinimbang mung siji pengamatan ing wektu, wiwit operasi IO larang.
Eksplorasi/eksploitasiimbangan. Sawetara mlaku bisa macet menyang minimal, utawa konvergen dadi alon, mula kita nambahake kemampuan kanggo ngowahi ruang telusuran ing pesawat . Iki bakal mbantu normalake kacepetan panelusuran.
Bar kemajuan sing luwih apik. Pangoptimal sing mlaku ing pirang-pirang proses mbutuhake sinkronisasi kanggo nganyari garis kemajuan saka pirang-pirang buruh. Lan ana perpustakaan mung kanggo iku , sing ngidini kita uga nambah informasi luwih lengkap menyang negara mlaku optimasi.
Amarga kita padha mlaku sawetara optimizer, kita uga nambah support kanggo menehi fungsi mundhut beda kanggo optimizers beda, kang bakal ngidini kita kanggo ndeleng kang fungsi mundhut nindakake paling.
Kanggo mbukak optimizations, kita ngleksanakake a skrip cli kanggo mbukak optimasi karo paramèter konfigurasi beda, nerusake saka negara sadurungé, utawa mung nuduhake lan nyaring nyoba disimpen.
Kita padha mlaku optimizers sawijining karo fungsi mundhut beda, banjur, kok ora mbukak optimizers beda ing fungsi mundhut beda ? Pikiran diunekake. Dadi, kita ngetrapake abstraksi kanggo optimizers supaya kita bisa (karo dicokot saka plumbing) gaib swap cara optimasi. Iki uga mbutuhake modifikasi optimasi antarmuka supaya "hyperopt" bisa ngerti optimizer. Banjur kita dileksanakake maneh scikit-ngoptimalake minangka conto abstraksi optimizer kita. Nalika uga plug in kapak, emukit lan sherpa.
We cranked FQT backtesting kanggo 11 . Nanging kita ora tau nggunakake ing produksi :).
Rada sawise mati rasasaka backtester, callbacks tambahan ditambahake menyang strategi sing nyuwil pamisahan antarane backtesting lan evaluasi strategi, kang tegese supaya bab cepet, sampeyan kudu uga nulis strategi ing numba! Nanging aku kesel karo campuran goyang python / numpy / numba gotchas lan amarga aku ora seneng eksekusi langsung saka FQT, Aku dropped kabeh iku tho, kanggo greener (utawa aku bakal ngomong pinker! ) pangonan.
Oalah...optimasi iku crack.
