Zipline Backtesting Engine

Salut, sunt Alex de la DEV STORIES DOT EU. Zipline Backtesting Engine, episodul 1 din 7. Majoritatea algoritmilor de tranzacționare arată genial pe hârtie, dar pierd instantaneu bani pe piețele live. Suspectul principal este look-ahead bias. Codul tău se uită accidental la prețul de închidere de mâine pentru a face tranzacția de astăzi. Event-Driven Backtesting Engine-ul din Zipline 3.0 previne complet acest lucru. Într-un backtester vectorizat standard, încarci un dataframe masiv de prețuri istorice și aplici operațiuni pandas pe întreaga cronologie simultan. Acest lucru este rapid, dar este profund defectuos pentru simularea realității. Poți scrie cu ușurință o logică care declanșează un ordin de cumpărare astăzi pe baza unei medii mobile care include accidental date din săptămâna viitoare. Zipline elimină această capacitate forțându-te să intri într-un stream strict event-driven. Simulează o bursă financiară reală. Când rulezi un backtest, engine-ul acționează ca un cronometru strict. Acesta parcurge istoricul, tick cu tick sau minut cu minut. La fiecare pas, declanșează un event. Codul tău primește doar datele disponibile la acea microsecundă precisă. Inspectezi starea actuală, plasezi comenzile și apoi aștepți ca engine-ul să avanseze ceasul. Nu poți privi înainte, deoarece datele viitoare nu au fost încă streamed către engine. Această arhitectură garantează că backtest-ul tău reflectă constrângerile reale ale tranzacționării live. Cu toate acestea, procesarea unei cronologii financiare event cu event în Python pur creează un bottleneck masiv. S-ar putea să procesezi ani de zile de date de prețuri la nivel de minut pentru mii de acțiuni individuale. Pentru a face acest event loop viabil din punct de vedere computațional, Zipline face offload masiv de muncă către C-extensions. Core engine-ul se bazează pe rutine precompilate pentru a procesa numerele suficient de repede pentru a fi utile. Această dependență de C-extensions introduce un punct major de fricțiune. Configurarea unui mediu cantitativ robust de la zero este notoriu de dificilă. Zipline nu este un tool Python standalone. Necesită o integrare profundă cu bibliotecile științifice la nivel de sistem. De exemplu, folosește TA-Lib, o bibliotecă standard pentru generarea de indicatori tehnici de piață. De asemenea, se bazează pe pachete care necesită LAPACK și BLAS pentru calcule grele de algebră liniară. Acestea sunt codebases C și Fortran complexe, legacy. Dacă încerci să construiești acest mediu folosind o simplă comandă pip install, aproape sigur te vei lovi de un zid de erori de compilare. Pip extrage codul sursă pentru aceste dependențe și încearcă să le compileze local. Acest lucru necesită ca sistemul tău de operare să aibă deja un compilator C configurat corect, un compilator Fortran și fișierele system header corecte. Majoritatea sistemelor de operare de bază nu au asta out of the box. Acesta este motivul pentru care documentația Zipline recomandă în mod explicit utilizarea conda în loc de pip. Conda nu este doar un Python package manager. Este un environment și system-level binary manager. Când creezi un conda environment și instalezi Zipline prin canalul conda-forge, nu compilezi nimic din sursă. Conda descarcă binaries precompilate pentru sistemul tău de operare specific. Gestionează C-extensions, TA-Lib și LAPACK fără probleme. Dependency tree-ul este rezolvat automat pentru tine, rezultând un mediu stabil, gata pentru dezvoltarea algoritmică. Iată ideea cheie. Event loop-ul strict care face ca Zipline să fie matematic onest este exact ceea ce îl obligă să se bazeze pe C-dependencies compilate, grele, pentru a rula at scale. Înțelegând această arhitectură, înțelegi de ce instalarea este complexă și de ce conda este singura modalitate rezonabilă de a-ți construi mediul. Dacă vrei să ajuți la continuarea emisiunii, ne poți sprijini căutând DevStoriesEU pe Patreon. Asta e tot pentru acest episod. Îți mulțumesc că ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Zipline Backtesting Engine, episodul 2 din 7. Configurezi un contor simplu în logica ta de trading folosind o variabilă globală Python, iar la jumătatea backtest-ului, se resetează sau dă o eroare. În backtesting-ul event-driven, variabilele globale standard sunt o capcană. Ca să supraviețuiești miilor de evenimente de piață simulate, ai nevoie de o metodă sigură prin care să ții evidența state-ului, și exact aici intră în joc Zipline Algorithm Lifecycle și State Management. Orice algoritm Zipline necesită cel puțin două funcții de bază: initialize și handle data. Zipline este un sistem event-driven. Parcurge cronologic datele istorice, declanșând un eveniment pentru fiecare time slice. Funcția initialize rulează exact o singură dată când începe backtest-ul tău. Primește un singur argument numit context. Gândește-te la context ca la memoria persistentă a algoritmului tău. Sub capotă este un simplu dicționar Python, dar acționează ca un namespace dedicat. În loc să declari variabile globale standard, îți atașezi state-ul direct de context. Dacă vrei să urmărești un anumit asset, cum ar fi acțiunile Apple, îl cauți în initialize și îl atribui la context dot asset. Asta te asigură că referința supraviețuiește din prima zi a backtest-ului până în ultima. Urmează funcția handle data. Asta este apelată de fiecare dată când apare un nou eveniment de piață, cum ar fi un nou trading bar zilnic. Primește două argumente: context și data. Știi deja ce e context. Acolo citești state-ul pe care l-ai configurat mai devreme sau actualizezi variabilele curente. Al doilea argument, data, reprezintă mediul curent al pieței. Este lentila ta către simulare în acel moment exact. Folosești data ca să verifici dacă un asset este tranzacționabil în prezent, ca să-i obții prețul curent sau ca să ceri o fereastră istorică de prețuri. Gândește-te la o strategie standard de dual moving average crossover. În funcția initialize, îți definești asset-ul țintă și îl atașezi la context. În interiorul handle data, ceri obiectului data prețurile pe ultimele treizeci de zile pentru a calcula un short moving average, și pe ultimele trei sute de zile pentru un long moving average. Compari cele două medii. Dacă media short trece peste media long, este un semnal de cumpărare. Execuți asta apelând funcția order, pasând context dot asset și un număr țintă de acțiuni. Trading-ul este doar jumătate din treabă. Trebuie, de asemenea, să urmărești cum performează indicatorii tăi în timp. Zipline oferă o funcție built-in numită record. La finalul blocului tău handle data, apelezi record și îi pasezi acel short moving average, long moving average și prețul curent. Zipline colectează aceste valori înregistrate la fiecare pas și le atașează la dataframe-ul final de performanță, returnat la sfârșitul backtest-ului. Când codul tău este gata, ai două modalități de a-l rula. Prima este prin command line interface. Pasezi scriptul tău Python către comanda Zipline run, specificând datele de start și de end, capitalul inițial și un fișier de output pentru rezultatele de performanță. Asta este ideal pentru pipeline-uri automate sau execuție remote. A doua metodă este interactivă. Dacă folosești Jupyter Notebooks, poți folosi magic command-ul built-in zipline. Tastând percent percent zipline în partea de sus a unei celule de notebook, definești și execuți algoritmul inline, pasând datele și capitalul ca argumente pentru magic command. Rezultatele sunt injectate direct într-un dataframe local, gata pentru analiză imediată. Iată ideea cheie. Zipline te obligă să îți împarți algoritmul în două obiecte distincte: context pentru state-ul intern pe care îl controlezi, și data pentru mediul extern al pieței. Respectă această graniță, iar state management-ul tău va rămâne perfect sincronizat pe parcursul a mii de trade-uri. Asta este tot pentru acest episod. Ne auzim data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Zipline Backtesting Engine, episodul 3 din 7. Logica ta de trading poate fi complet impecabilă, dar dacă încarci fișiere CSV masive în memorie de fiecare dată când rulezi o simulare, viteza ta de iterație se va bloca. Bottleneck-ul este rareori algoritmul tău. Este data pipeline-ul tău. Zipline rezolvă această problemă folosind Market Data Bundles și Custom Ingestion. Un data bundle este o colecție de prețuri ale activelor și metadata care a fost precompilată într-un format de storage extrem de optimizat. În loc să facă parse pe fișiere text raw în timpul unui run, Zipline citește dintr-un storage binar comprimat și dintr-o bază de date locală rapidă. Această separare a procesării datelor de execuția strategiei face ca backtest-urile să fie excepțional de rapide. Declanșezi această compilare din command line folosind comanda zipline ingest, urmată de numele bundle-ului. Zipline vine cu un bundle default numit Quandl, care trage date istorice zilnice standard despre acțiuni de pe internet și le scrie direct pe discul tău local. Majoritatea mediilor profesionale se bazează pe date proprietare. Pentru a folosi propriile date, trebuie să construiești un custom bundle. Crearea unui custom bundle necesită scrierea unei funcții de ingest. Această funcție acționează ca un translator dedicat între sursa ta de date raw și formatul intern de storage al Zipline. Iată ideea principală. Funcția de ingest nu returnează un dataset customizat. În schimb, Zipline pasează mai multe obiecte de tip writer în funcția ta, iar codul tău trimite date raw în acele writer-e. Semnătura funcției de ingest necesită parametri specifici pentru a gestiona această rutare. Primește o configurație de environment, calendarul de trading, sesiunile de start și de end, și obiectele writer. Cele două obiecte critice cu care vei interacționa sunt asset database writer și daily bar writer. Asset database writer-ul gestionează metadata ta. Îi pasezi un tabel structurat care conține simbolurile tale, datele lor de start și de end, și numele de exchange. Writer-ul compilează asta într-o bază de date locală, astfel încât engine-ul să știe exact ce active există în orice sesiune de trading dată. Daily bar writer-ul procesează price action-ul efectiv. Îi oferi un iterator care dă yield la blocuri de date de preț. Fiecare bloc conține un identificator intern de activ asociat cu un tabel cu datele sale de open, high, low, close și volume. Writer-ul preia aceste blocuri și le comprimă pe disc. Zipline oferă un mecanism built-in pentru gestionarea de flat files standard folosind CSV directory bundle, numit în mod obișnuit csvdir. Îți setezi datele proprietare salvând fișiere CSV individuale într-un singur folder, denumind fiecare fișier după simbolul său de ticker. Apoi înregistrezi acest director într-un script de configurare Zipline specific numit extension file. Înregistrarea pur și simplu leagă numele tău de custom bundle de funcția de ingest din spate, astfel încât tool-ul de command line să știe că există. Când rulezi zipline ingest cu noul tău nume custom, sistemul direcționează funcția de ingest către folderul tău. Face un loop prin fișierele CSV, extrage metadata, alimentează asset database writer-ul și pompează rândurile de prețuri istorice în daily bar writer. Procesul lent și costisitor de text parsing are loc exact o singură dată. După ingest, datele tale proprietare sunt stocate permanent în formatul optimizat, accesibile instantaneu pentru mii de iterații de backtest de mare viteză. Adevărata putere a custom ingestion-ului este că decuplează strict pregătirea datelor de execuția strategiei tale, asigurându-se că logica lentă de parsing nu îți poluează niciodată environment-ul de testare. Asta e tot pentru episodul ăsta. Ne auzim data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Zipline Backtesting Engine, episodul 4 din 7. Split-urile de active și dividendele îți pot invalida instantaneu istoricul de prețuri. Dacă o acțiune trece printr-un split de doi la unu, o buclă de backtesting naivă va crede că prețul tocmai s-a prăbușit cu cincizeci la sută. Poți evita asta folosind Algorithm API și interacțiunile cu BarData, care gestionează automat ajustările point-in-time. În Zipline, nucleul logicii algoritmului tău interacționează cu un obiect numit de obicei data, care este o instanță de BarData. Acesta este pasat în event handlers, cum ar fi data handler-ul tău principal sau funcțiile tale scheduled. Treaba lui principală este să servească date de preț și volum exact așa cum arătau în acel moment specific din simulare, prevenind complet look-ahead bias-ul. Când apelezi data dot current, îi pasezi un asset și un field, cum ar fi price sau volume. Îți dă cea mai recentă valoare disponibilă la acel minut sau acea zi exactă din simulare. Când ai nevoie de un lookback window pentru a calcula un moving average sau volatilitatea istorică, apelezi data dot history. Îi dai asset-ul, field-ul, numărul de bars și frecvența, cum ar fi o zi sau un minut. Iată ideea cheie. Atât current, cât și history ajustează automat datele returnate pentru corporate actions, dar numai până la timpul curent al simulării. Moving average-urile tale nu vor devia masiv la o dată ex-dividend, deoarece prețurile istorice sunt ajustate pentru a se alinia perfect cu cadrul de preț curent. Obții un time series matematic continuu, fără să fii nevoit să gestionezi tu multiplicatorii de corporate actions. Înainte să acționezi pe baza acelor date de preț, trebuie să verifici dacă asset-ul este de fapt tranzacționabil în acel moment exact. Pasarea asset-ului tău către data dot can trade verifică dacă exchange-ul este deschis pentru acel asset și dacă este listat activ. Dacă o acțiune a fost delistată ieri sau nu a avut încă IPO-ul, asta returnează false. Mai departe, ai data dot is stale. Dacă un asset este foarte ilichid și nu s-a tranzacționat în timpul bar-ului curent, Zipline va face forward-fill cu ultimul preț cunoscut pentru a preveni erorile de missing data. Totuși, dacă rulezi o strategie de mean-reversion pe prețuri forward-filled, tranzacționezi pe date fantomă. Data dot is stale returnează true dacă prețul pe care îl vezi este preluat dintr-o perioadă anterioară, în loc să fie o tranzacție proaspătă. Verificarea atât a tradability-ului, cât și a staleness-ului înainte de a plasa un ordin previne o clasă masivă de erori de simulare. Asta acoperă inputurile, trecem la execution timing. By default, Zipline îți apelează data handler-ul principal la fiecare bar de simulare. Dacă rulezi o strategie la nivel de minut, executarea unei logici complexe de rebalance la fiecare șaizeci de secunde îți va încetini backtest-ul enorm și va declanșa costuri de tranzacție nerealiste. Soluția este metoda schedule function. O folosești în faza de inițializare a algoritmului pentru a înregistra o funcție custom specifică care să ruleze după un program precis. Ia trei argumente principale. În primul rând, funcția pe care vrei să o rulezi. În al doilea rând, un date rule. În al treilea rând, un time rule. Să presupunem că vrei să rulezi un rebalance de portofoliu cu exact treizeci de minute înainte de închiderea pieței. Pasezi funcția ta de rebalance ca prim argument. Pentru date rule, folosești metoda helper date rules dot every day. Pentru time rule, folosești time rules dot market close, pasând treizeci de minute ca argument de offset. Acum, în loc să se declanșeze de sute de ori pe zi, logica ta de rebalance rulează exact o singură dată, fix când sesiunea de tranzacționare se apropie de sfârșit. Separarea dintre obiectul BarData pentru acces sigur la date și scheduling API pentru execution timing garantează că logica de bază a algoritmului tău rulează doar atunci când ar trebui, folosind prețuri care au existat efectiv în acel moment exact. Aș vrea să îmi iau un moment să îți mulțumesc pentru că asculți — ne ajută foarte mult. Să ai o zi super!

Salut, sunt Alex de la DEV STORIES DOT EU. Zipline Backtesting Engine, episodul 5 din 7. Algoritmul tău detectează un semnal de ieșire perfect și emite un ordin de vânzare masiv. Problema e că este sâmbătă. Dacă backtesting engine-ul tău nu știe că bursa este închisă, acel ordin fie se execută într-o piață fantomă, fie îți dă crash la întreaga simulare. Custom Trading Calendars mapează realitatea orelor piețelor globale pentru a preveni exact acest scenariu. Un trading calendar în Zipline este sursa absolută de adevăr pentru sesiunile de piață. Acesta dictează când pot fi ingerate datele și când pot fi procesate ordinele. By default, Zipline presupune un program standard pentru acțiunile din Statele Unite. Dacă vrei să tranzacționezi acțiuni internaționale, futures sau active alternative, trebuie să definești regulile specifice ale acelor burse. Faci asta creând o clasă custom care moștenește din clasa de bază Trading Calendar din Zipline. Trebuie doar să configurezi câteva properties specifice pentru a stabili limitele zilei de tranzacționare. În primul rând, setezi open time. Asta dictează ora și minutul exact la care piața începe să accepte ordine. În al doilea rând, setezi close time, marcând ultimul minut al sesiunii de tranzacționare. În al treilea rând, definești regular holidays. Asta este o colecție de date specifice în care bursa este complet închisă, cum ar fi sărbătorile naționale. Zipline nu face toate aceste calcule calendaristice de la zero. Utilizează intens librăria pandas, mai exact clasele pandas Holiday Calendar și Custom Business Day. Când furnizezi lista ta de regular holidays, populezi practic un obiect pandas Holiday Calendar. Zipline combină această logică pandas cu open și close times definite de tine pentru a genera un index masiv, precalculat, al fiecărui minut de tranzacționare valid pe întreaga durată a backtest-ului. Acest calcul upfront este crucial. Înseamnă că algoritmul tău nu evaluează calcule matematice complexe cu date calendaristice în timpul fiecărui tick al simulării. Pur și simplu face un query pe un array extrem de optimizat. Asta e partea care contează. Nu toate piețele dorm. Dacă simulezi tranzacții cu criptomonede, presupunerile standard despre weekenduri îți vor strica alinierea datelor. Trebuie să construiești un calendar continuu, 24/7. Hai să vedem cum construim unul, pe care îl vom numi TFS Exchange Calendar. Îți definești noua clasă și moștenești din clasa de bază standard. Pentru open time, specifici miezul nopții. Pentru close time, specifici 11:59 PM, oferindu-ți un ciclu zilnic complet. Deoarece bursele de criptomonede nu respectă sărbătorile tradiționale, setezi property-ul regular holidays să returneze o listă goală. Pasul final este ajustarea programului săptămânal. Trading calendars tradiționale folosesc un obiect pandas Custom Business Day configurat strict de luni până vineri. Pentru calendarul tău TFS, dai override la acest property weekmask pentru a include explicit sâmbăta și duminica. Odată ce clasa este gata, o înregistrezi în environment-ul Zipline folosind un string identifier custom. Din acel moment, atât data ingestion bundles, cât și algoritmii tăi de tranzacționare vor recunoaște programul continuu. Ordinele vor fi procesate secvențial fără a sări peste weekenduri, iar datele la nivel de minut se vor mapa perfect pe timestamps din lumea reală. Dacă regulile calendarului tău sunt configurate greșit, datele tale de preț se vor alinia greșit, iar performance metrics ale tale vor fi complet fictive. Limitele de timp dictează fiecare acțiune într-un event-driven engine, iar trading calendars sunt exact modul prin care impui aceste limite. Asta e tot pentru acest episod. Mersi că ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Zipline Backtesting Engine, episodul 6 din 7. Calcularea unor metrici complexe de risc la fiecare tick îți poate încetini backtest-ul enorm. Vrei ca simulările tale să fie rapide, dar trebuie și să știi exact cum se comportă strategia ta în condiții de stres. De fapt, poți dezactiva tracking-ul default în timpul procesului de debugging sau poți scrie custom trackere extrem de optimizate. Acest episod acoperă Risk Performance Metrics și Custom Evaluation. Zipline își grupează calculele built-in de risc și performanță într-o structură numită Metric Set. Setul default generează automat statistici standard, cum ar fi beta, Sharpe ratio și total returns. Când simularea se termină, Zipline împachetează toate aceste calcule în DataFrame-ul de performanță. Fiecare metrică la care faci tracking devine o coloană, iar fiecare rând reprezintă un time step din simularea ta. Dacă nu ai nevoie de toate aceste metrici default, poți pasa un Metric Set simplificat la pornirea engine-ului, economisind un timp semnificativ de procesare. Când metricile default nu îți acoperă modelul specific de risc, definești o custom metric. Faci asta creând o subclass pentru obiectul metric de bază din Zipline. Să scrii o custom metric înseamnă să faci hooking direct în ceasul intern al simulării. Controlezi exact când se execută logica ta prin implementarea a trei lifecycle methods specifice: start of simulation, end of session și end of bar. Start of simulation este locul unde inițializezi variabilele și setezi starea inițială. End of session rulează o singură dată la închiderea zilei de tranzacționare. End of bar se execută după fiecare update de preț, ceea ce este critic pentru strategiile la nivel de minut. De fiecare dată când se declanșează unul dintre aceste hook-uri bazate pe timp, Zipline îi pasează două argumente obligatorii: ledger și packet. Ledger-ul ține starea matematică, live, a simulării tale. Conține valoarea curentă a portofoliului tău, balanțele de cash și toate pozițiile deschise. Tratezi ledger-ul ca pe niște date read-only. Packet-ul, pe de altă parte, este un dictionary gol care reprezintă data payload-ul pentru acel time step specific. Tu scrii în packet. Orice key-value pair pe care o atribui dictionary-ului packet devine instant o coloană în DataFrame-ul tău final de performanță. Hai să vedem cum facem tracking pentru maximum intraday drawdown folosind hook-ul end of bar. Mai întâi, îți definești clasa custom metric. În metoda start of simulation, creezi două variabile: una pentru a face tracking la cea mai mare valoare a portofoliului văzută până acum, și alta pentru maximum drawdown-ul curent. Ambele pornesc de la zero. Iată ideea cheie. Pentru că scăderile intraday sunt invizibile dacă verifici doar prețurile zilnice de închidere, trebuie să îți execuți logica în interiorul metodei end of bar. În interiorul acestei metode, citești valoarea curentă a portofoliului din argumentul ledger. Dacă valoarea curentă este mai mare decât cea mai mare valoare înregistrată de tine, faci update la high water mark. Dacă este mai mică, calculezi scăderea procentuală. Dacă acea scădere depășește maximum drawdown-ul înregistrat, faci update la variabila maximum drawdown. În final, iei variabila maximum drawdown și o atribui unei chei din argumentul packet. Scriind în packet la fiecare end of bar, DataFrame-ul tău final de performanță va conține o înregistrare granulară, minut cu minut, a celei mai grave scăderi intraday experimentate. Custom metrics sunt, la bază, doar niște observeri care citesc ledger-ul simulării și scriu în output packet, oferindu-ți control total asupra a ceea ce se măsoară și când. Asta e tot pentru acest episod. Mersi că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Zipline Backtesting Engine, episodul 7 din 7. Petreci luni întregi perfecționând un algoritm într-un simulator, dar piața reală nu acceptă ordine de tranzacționare simulate. Zipline a fost conceput în principal pentru backtesting, dar arhitectura sa modulară înseamnă că poți ocoli complet simularea internă și poți ruta direct către un motor de execuție real. Extinderea arhitecturii Zipline face posibilă această tranziție. Din start, Zipline funcționează ca o buclă închisă. Îi furnizezi date istorice despre prețuri, calculează semnale și îți potrivește ordinele intern cu comportamentul anterior al pieței. Sistemul îți izolează intenționat algoritmul de rețelele externe. Dar un sistem de tranzacționare modern trebuie în cele din urmă să comunice cu lumea exterioară. Ai nevoie de o modalitate de a înlocui componentele interne de simulare cu module personalizate care gestionează date live și capital real. Zipline gestionează această cerință printr-un mecanism de extensie construit în jurul unui fișier de inițializare specific numit extension dot py. Acest fișier acționează ca un registru local pentru mediul tău. Când framework-ul Zipline pornește, caută imediat aici overrides definite de utilizator. Folosești acest fișier pentru a înregistra noi data bundles, modele de comisioane personalizate și motoare de execuție alternative. Cea mai importantă componentă pe care trebuie să o schimbi pentru tranzacționarea live este Blotter-ul. Blotter-ul acționează ca sistem intern de gestionare a ordinelor. Urmărește ordinele deschise, le anulează atunci când primește instrucțiuni și procesează trade fills. Blotter-ul de simulare implicit pretinde că execută tranzacții pe baza volumului istoric și a algoritmilor de slippage. Pentru a tranzacționa live, trebuie să ocolești complet acest lucru. Realizezi acest lucru scriind o clasă Blotter personalizată. În loc să simuleze execuția, metodele clasei tale efectuează apeluri de rețea către un API de broker real. Când algoritmul solicită o tranzacție, blotter-ul tău personalizat formatează acea solicitare într-un ordin live și o transmite către bursă. Iată ideea principală. Nu modifici nicio linie din codul sursă original Zipline pentru a implementa acest lucru. Îți definești clasa personalizată de blotter în propriul spațiu de lucru. Apoi, deschizi extension dot py. Imporți funcția de înregistrare a blotter-ului din modulul de utilități Zipline. Îi transmiți acestei funcții un string unic pentru brokerul tău, împreună cu clasa ta personalizată de blotter. Asta înregistrează motorul tău de execuție la nivel global. În cele din urmă, când execuți scriptul de tranzacționare din linia de comandă sau dintr-un notebook, pur și simplu furnizezi numele de tip string al blotter-ului personalizat ca parametru de lansare. Framework-ul schimbă automat mecanismele interne. Exact același algoritm care a rulat în simulare tranzacționează acum capital real. Suportul acestui nivel de modularitate necesită o fundație core extrem de stabilă. Zipline se bazează în mare măsură pe dataframes numerice rapide și stocare în baze de date relaționale pentru a muta informații între algoritm și blotter. Odată cu lansarea Zipline 3.0, arhitectura de bază a primit o actualizare structurală semnificativă pentru a moderniza această fundație. Întreaga platformă a fost migrată pentru a suporta Pandas 2.0 și SQLAlchemy 2.0. Actualizarea la Pandas 2.0 aduce o gestionare a memoriei substanțial mai bună și timpi de execuție mai rapizi pentru array-urile masive de time series pe care Zipline le procesează la fiecare tick. SQLAlchemy 2.0 modernizează complet modul în care motorul interacționează cu bazele de date SQL subiacente. Acesta impune path-uri de execuție a query-urilor mai stricte și mai explicite atunci când sistemul gestionează metadatele activelor și stochează rezultatele tranzacțiilor. Aceste îmbunătățiri fundamentale asigură că, indiferent dacă rulezi un backtest istoric masiv sau rutezi ordine live printr-o extensie personalizată de broker, motorul funcționează pe baza standardului modern al infrastructurii de date Python. Prin separarea logicii de tranzacționare de mecanica de execuție, arhitectura garantează că algoritmul tău rămâne complet intact, în timp ce stratul de execuție subiacent se adaptează la realitate. Te încurajez insistent să explorezi documentația oficială și să încerci să îți scrii propriile extensii practic. Dacă ai idei despre ce ar trebui să acoperim în continuare, vizitează DEV STORIES DOT EU pentru a sugera subiecte pentru seria noastră viitoare. Îți mulțumesc că ai petrecut câteva minute cu mine. Până data viitoare, toate bune.