drew2323 / v2trading Goto Github PK

TradesViz případně nějaká alternativa ??

1. základ - Manuální import - Upravit CSV export do odpovídající struktury
   tradesviz_custom_format.csv

2. pokročilé - automatický import z platformy do tradesViz

Může jít o db lock? Projít kód a zajistit, aby se chyba zobrazila, vypsals do logu atp.

Multitenancy and user support

mvp 1) login přes google, user table v db, session id v api, možná nastavení vlastních accountů

další fáze potom

• komplet multitenancy v datech, user rights atp.

Pro základní validace bude run API vracet odpoved a ta bude zobrazena uzivateli na FE.

obecne vymyslet exception handling, abych byl notifikovan a bylo videt okamzite v logu a na frontendu

trade_offline_stramer.py - line126 - napr. nedostupny calendar atp.

obecne offline_streamer nema zadny exception handling

Umožnit na GUI smazat celý batch najednou.

nezapomenout na smazání batchových reportů

Na paper a live vypnout strategii na konci dne, nejspis na nejake direktive. Nejak to vymyslet - bud po EOD forced exitu nebo po uplynuti konce marketu.

vymyslet realizaci batch entity bez zasadniho redesignu gui, nabizi se batch entita jako zaklad náhledová jednotka, který by pod sebou měla všechny dny a na sobě základní informace, od, do, stratiny a vysledkove reporty

Atributy:
id
od - do
settings
mode (paper/live/bt)

• weekdays
  results
• profit, rel_profit, odkaz na report file

na úrovni dni bych šel až kdybych potřeboval

Související:

• runner jako bezici entita, ale batch je jeste nad tim a zatim neni nikde zobrazena
• zatim tlacitko Stop a Stopall vypne runner a zaroven posle signal do batch manageru - promyslet zesystemovatet

Podpořit generování PDF pro označené dny (stáhne si trady a vytvoří PDF). Button na archrunners.

Podpořit i pro batche, možná automaticky vytvořit i pro batch po dokončení batch. Ale kam uložit?

Co je částěčně hotovo:
vytvořená funkce v reporting/metricstools.py a vystavena na REST API.

Zatím je to jen na jeden RUNNER_ID a bráno z metrics, předělat, že bude brát z presc_trades a vstupem bude 1 .. N runnerů, pro které si nejdřív dotáhne prescribed_trades a všechno to na nich spočte.

@app.put("/archived_runners/{runner_id}/generatepdf", dependencies=[Depends(api_key_auth)], responses={200: {"content": {"application/pdf": {}}}})
def _generat_pdf(runner_id: UUID):
#jako vstup umouznit i seznam runneru - vytvori to pote report ze vsech techto
#pripadne mit jako vstup batch a udelat to pro batch ()
res, vals = mt.create_trading_report_pdf(id=runner_id)

Další idea je mít tento combined_graph rychle dostupny na náhled. Graf může být dostupný buď v edit modálu pod metrikami a nebo jako samostatný preview modal a nebo přímo v chartu také.

PDF může být na button a v detailu.

Displaying progress bar during backtest on the runner level, so user can see the progress of current day being backtested.

Idea here:
https://chat.openai.com/c/29524aaa-b202-41f7-b88f-285dca958119

Obecně lepší zpětná vazba o probíhajícím backtestu na frontend.

indicators will be converted to np.array if true

Pro trade cache pouzit compression -

https://stackoverflow.com/questions/57983431/whats-the-most-space-efficient-way-to-compress-serialized-python-data

Tickprice a tickvalue - defaultně vypnout, naloaduje se až se zapnutím

UC: Nyní u časové bary se uzavírají až příchodem dalšího tradu. Ten ale může být v extrémních případech např. o několik barů předem (např. 5 sekund u 1s barechú a confirm předchozího baru se pošle až tehdy.

Cílem je potvrdit uzavření baru nejenom příchodem dalšího baru, ale i uplynulým časem. Aby strategie mohla zareagovat.
Nejspíš řešeno i pulzním generátorem.

Řešení:

• agregátor si drží čas uzavření baru (např. mám sekundový bary začínající 163000, mám uloženo, že uzavírka je 163001 (a tomu odpovídající můj systémový čas).

• pak mám pulzní generátor, který jen tak volá agregátor a pokud systémový čas přesáhl uzavírku a je otevřený bar, tak triggeruje confirm baru.

• podpořit jak BT tak LIVE cases

• dořešit co se stane pokud přijde opožděný trade do již potvrzeného baru (nejspíš zahhodit a něco o tom napsat)

add support for histogram of numpy

counts, bin_edges = np.histogram(data, bins=4) print(counts, bin_edges) edge_from = bin_edges[3] edge_to = bin_edges[4] print(edge_from) print(edge_to) ctvrty_bin = [datum for datum in data if edge_from <= datum <= edge_to] print(np.mean(ctvrty_bin))

Případně i save last position for given arch runner.

stejně jako SL line, tak mít i goal price, tzn. dávat do ext_data nebo brát vlastně z trades

Scheduler pro automatické spuštění v určitém čase s parametry:

Strategie

• strategy ID
• mode (PAPER/LIVE)
• account
• logs on/OFF
• note: poznámka
  Mód spouštění
• weekdays (které dny v týdnu)
  Status: active - plánovač je aktivní, paused - plánovač pozastaven

Další požadavky:

• Záznam v plánovači jde upravovat.
• Start a stop v rámci dne bude defaultně na začátku a konci trhu.
• Každý záznam ve scheduleru bude mít batch_id, pod kterým bude daná strategi spouštěná (tzn. automaticky se spuštěné runy zgrupovuji pod tento batch a do budoucna půjde reportovat nad batchí)
• Scheduler zapisuje někam do logu (musí jít dohledat, když se scheduler neúspěšně pokusil spusti/vypnout). Případně text na Telegram.
• do budoucna podpořit i fronta pro spouštění (#62)

Otevřené otázky:

• jak často spouštět scheduler? Pokud jen začátek a konec trhu, jak spustíme strategie, které spadnout a budem je chtít spustit znovu (aby byly svázané v rámci scheduleru)

Realizace:

Na začátku buď JSON v config sekci nebo jednoduchá tabulka v gui + cron scheduler.

1. zjistí strategie a které mají běžet (zatím pouze ID a market open)
2. zjistí zda je market den - volání calendar, pokud ano pak vytvořeí runRequest a zavolá spuštění strategie

Podpořit:

• spouštění pouze v určitých weekdays -stejně jako u BT #43
• vypnutí strategie na konci dne
• respektovat skutečný konec trhu, (včetně dnů končí market v 13)

Cílem je mít u strategie uložené testovací sady, na kterých je testovaná a základní výsledky. S případným na detail batche (filtr na table).

Zanalyzovat.

Alpaca get Calendar is very often unavailable, the backtests depends on it heavily, make your own.

Cachovani pro Loader. Pokud je predan catcher objekt, data z aggregatoru jdou nejdriv do cachovaci queue, uloží se a pak teprve odchazeji.

Při opětovném runu stejného dne se stejnými parametruy(v hlavičce), si offline loader sáhne do cache a pošle tuto queue namísto agregatoru,

u kazdeho tradu zobrazit goalprice line - hodnota cílového profitu

zvážit obecný mechanismus zobrazován dat v ext_data např. ext_data.lines kde by byly přpipravene dodatečné grafy pro frontend.

bugfix: Vypnutí na zaklade profitu nesmi zrusit batch, ale na tlacitko ano. Zatim pouzivali stejnou Eventu. Proto zakomentovano. Opravit (nejspis nova dalsi eventa jen pro vypinani z profitu)

Weekdays as checkboxes on gui on Run Strategy modal to run only on specific weekdays.

Komponenta, která by mohla být pomalými indikátory v pravidelných intervalech dotazována na určité metriky, zejména měnící se v reálném čase nebo předpocitane. Nejspíš bude vyžadovat backtest variantu, tzn. Přistupování přes interface. V budoucnu i součást predpocitace.

Jako quick win varianta je možná jednoduchá komponenta, která bude předvolává alpacu způsobem použitelným na live i bt. Např dotažení barů za období (např. Poslední 2 hodiny od state.time) a vrácení kalkulována hodnoty.

Umožnit dělat statistické výpočty nad připravenými daty (volume bary + indikatory). Ideálně dotazováním normálním jazykem s využitím AI.

Vymyslet workflow přípravy a ukládání dat (např. připravím si měsíční daty s renko bary těchto parametrů a s těmito indikátory). To se někam uloží (db, pickle, parquett). A poté se můžu doptávat na otázky typu. "Jaké je procento, kdy to otevře v gapu více než X%" "Jak se průměrně mění přírůstek volume v průběhu dne?" "Jaká je průměrný pohyb indikátoru bla bla."

Ideálně připravit do nějakého datasetu nebo popsat tabulky. A pak vyuzít chatbot na vytvoření SQL příkazu na tuto strukturu na základě dotazu v reálném jazyce. Tento SQL se pak spustí a výsledek zobrazí uživateli.

Dostupné přes GUI.

Vstup označený runner nebo batch.

Struktura pro následný rychlý vývoj akcí (pomůže chatgpt bot), který bude vědět co jsou vstupy jaké formy to má dát.

V roletce budou různé analýzy, vybere se druh analýza a ta se spustí a v outputu se zobrazí, buď tabulka nebo graf.

Příklad např. Cutoff hodnota a podobně.

Použít split buttons bootstrap 5 - pro více akcí na jednom buttonu (udělat pro analýzu plugin, přidáváme akce skrz Json configurability)
https://getbootstrap.com/docs/5.2/components/dropdowns/

Tady je návrh https://chat.openai.com/share/2dcf6a3f-254f-4ef4-87a4-82bc7115b713

viz 16.11. BAC market open

Do grafu by možná chtelo přidat rozdělení profitu po hodinách a dnech i ještě separátně pro longy a shorty, abychom to viděli na první dobrou.

Obecně prostě větší náhled dle směru.

Možná zvážit ještě ten framework na pluginy analýz.

Pomohlo nakonfigurovat swap.

Aplikace nedělá dobře garbage collection, po skončení batche zůstane maximální pamět (např. 1.5G) a dalším batchem se zaplním. Musí se nějak flushovat - vymyslet, projít kod.

Detaily zde https://chat.openai.com/c/d7310082-7445-44f5-b788-cc59000975d4

Nyní, když při BT např. dojde cash tak to crashne a strategie se zasekne.

File
"/home/david/v2trading/v2realbot/strategyblocks/newtrade/prescribedtrades.py",
line 49, in execute_prescribed_trades
raise Exception(f"error in required operation LONG {res}")
Exception: error in required operation LONG -1

Nějak to zesystematizovat, buď to vracet do telegramu nebo vypnout strategii a hlavne aby byla viditelna chybová hláška

Umožnit indikátoru vracet více lajn.

Vymyslet jak to pojmout, jak na backendu tak na frontendu. Jak to bude uložené v indikátoru a jak s tím ostatní budou pracovat. Celé workflow a důsledky domyslet.

zatím potřebuji hlavně pro:

• featury popisujici shape ohlc viz https://chat.openai.com/c/c1a22550-643b-4037-bace-3e810dbce087
• Fourier např. 1 tři frekvence a první tři amplitudy.
• Bollinger Bands, Macd

QuickWin

ve stratvars master indicator
[indicator.multipleoutput]
type ="custom"
subtype="bollinger"
returns = ["upper_band", "lower_band"]

Plugin pak misto val vraci dict, tzn.
return 0, {"upper_band": 12, "lower_band":15}
return 0, [12,15] #v pripade listu poradi hodnot odpovida poradi v "returns"

následný kod v custom_hub.py je upraven:

• preprop návratové hodnoty
  • pokud je návrat list, pak se zipne s returns - vytvori se dict s klici dle returns a hodntoy vals
  • pokud je dict pak se bere dict
  • pokud je int nebo float vytvori se dict s jednim clenem{ind_name: val}
• uložení do daných indikátorů (včetně do minulosti) a podpora MA (pokud je pozadovano vytvori se pro vsechny)

Inicializace:

• Uprava inicializace a to tak, že pro indicatory s outs inicializujeme klíče podle outs

PreviewIndicators (services api)

• adaptovat úpravu i sem (inicializaci a ukládání)

Preview indicators FRONTEND

• indikátory z outs "upper_band", "lower_band" budou mít null configuraci - to je chtěné
• bude zde indikátor multipleoutput jako tlačítko to je taky chtěné, ale svoji lajnu bude mít prázdnou

1. Samosatné backtestové dny (bez batche) se na kliknutí otevřou/zavřou všechny. Omezit vždy jen na konkrétní. Možná udělat skupinu s nějakým generovaným id. noBatch1, noBatch2 atp.

2. Vyřešit filtrování na konkrétní strategii (Tlačítko Filter Backtest) a obecně problém vyhledávání v server side. Nyní nejde v tabulce hledat a to ani v již naloadovanýchg datech, ale dělá se vždycky nový load a je třeba to podpořit na serveru. Zvážit.

Bod 2 se týká obecnějšího problému aneb sorting a searching teď nefunguje a volá se server, kde není implementováno. Promyslet další přístup příp. workaroundy.

Podpora dynamické úpravy rozlišení na základě pohybu ceny.

Toto rozlišení může být

• statické (číslo - jako dosud)
• dynamické (nejspíš název pluginu nebo třídy), která se s daným nastavením přenese do aggregatoru a v pravidlených intervalech evaluuje stav a upravuje

Nutná podpora i v backtestu. Load tradu v nějakém pseudo realtime modu, aby se dala backtestovat i uprava dynamického rozlišení.

Třída může upravit rozlišení na základě čehokoliv ve state. Tzn. dailyBars, cbars, trades atp. Je spouštěna v určitých intervalech.

Zanalyzovat, jde o docela velkou změnu.

To get better insight to the strategy out is important to see the market conditions during the run.

Selected attributes from runner_detail (bars, indicators) can be fetches by reporting tool to combine with high level data(from headset) and visualize different aspects.

návrh zde https://chat.openai.com/c/5dab51fe-fbce-4a86-9422-eab647f7ba8a

Přesunout do sloupců, aby se dali dělat statistiky.

Stávající struktura:
runner_detail (runner_id, data)

data=
id
name
bars
indicators
ext_data
statinds
trades
Nyní je vše v JSON.

Upravit a vymyslet, aby se snadno daly dělat statistiky, exporty atp.

Dopady: API, GUI, DB

Customizovat basic report

• customizovane reporty kdyz je vstup batch a nebo den. Zejmena zzorbazení prubehu v case
• pridat zakladni metriky RRR atp. - martin

zadávání datumů na GUI bylo vždycky v NY času. (blbne to při změně času) - 14:30 - 21:00 vs 15:30 - 22:00

Directives to enable runnig the strategy on certain days of the week

Možná nejlépe v Run Manageru, ale vymyslet, aby se to dalo i backtestovat. Tzn. pro začátek asi nejlepší direktiva.

Currently only running stratin is cancelled not whole batch

změna základní vstupní pozice podle dosavadního(tento den) vývoje křivky profitu

Volume Bary:

• 3.11. 15:23:07 - BAC - je HIGH baru 28.52, ale neni v tick baru (možná je to kulomet?) - možná to dát pryč i z baru?

• doladit, aby seděl prubezny tick volume histogram s bar volume histogramem

• odtrasovat kratkou oblast trade by trade v debug modu