Jump to content
Co nového? Mé kurzy
Komunita:
Diskuze Sledované příspěvky Žebříčky

J.A.tester


Alec

Doporučené příspěvky

Aleš,

Ten export z autotestu by byl o.k. Ta poslední věta je jen torzo. Moc myšlenek, málo psaní :-) Bylo to myšleno tak, že by se při testu na datovém souboru zapisoval třeba při vstupu short čas na close vstupní svíčky, kdy nám OS dá signál, vstupní limitní cena, která by byla třeba na úrovni open nebo hi vstupní svíčky ( tedy cena se levou, proti předpokládanému pohybu) a čas na exekuci limitního příkazu (třeba 3 min). Tj. kdyby šel trh třeba prudce short, nebyl by vstup exekuovaný, a program by zahlásil Limit order loss, nebo tak něco. Tj. šlo by nějak pracovat s informací, nakolik nám limitní vstup umožní např. použití menšího SL, nebo kolik obchodů nám díky tomu uteče. Snad už to má hlavu a patu :-) M

Link to comment
Sdílet pomocí služby

  • Odpovědí 449
  • Vytvořeno
  • Poslední

Nejaktivnější diskutující

Nejaktivnější diskutující

Publikované obrázky

e_michal,

aha, už mi to je asi jasné. Jde tedy o takovou jemnější simulaci průběhu/vstupu obchodu v případě použití Limitních příkazů.

Dalo by se v tomto ohledu s tím ještě trochu pracovat, ale celé to stojí na datech.
1. data by musela být opravdu velmi kvalitní, bez nějakých výpadků (jak pak řešit situace kdy je v případě místa vstupu v datech třeba nějaký vyšší TF dat)
2. má to i svá technická omezení (které jsou již do určité míry znatelné i nyní). Pokud by jste pracoval s tickovými daty, tak v rámci jedné vteřiny můžete mít i poměrně dost řádků a může to obnášet i pohyb několika ticků. Problém je v tom, že není již technicky možné identifikovat v rámci jedné vteřiny o kterou úsečku by se mohlo jednat.

Proto v současné době nepočítám, že bych něco takového realizoval (i když jsem se již dříve touto myšlenkou zabýval). Musel by nastat posun ohledně zdroje kvalitních dat, pro všechny uživatele stejně a s opravdu kvalitními daty je často problém s historií.

Myslím si, že simulovat nějak uspokojivě vyplnění Limitních příkazů nebude nikdy asi moc reálné.


Aleš

Link to comment
Sdílet pomocí služby

Aleš,

Díky za odpověď. Rád bych se ještě zeptal na ta data. Váš program používají tradeři s různým zdrojem dat, tak máte možnost srovnávat. Šlo by nějak porovnat tyto zdroje co do kvality ? Já většinou používám data přímo od Sierra Chart ( .scid) . V Data trade servis setting mám nastaveno v Intraday data storage unit : 1 tick. Když se v JA testru v Editoru dat podívám na jejich strukturu přijde mi, že jsou to opravdu ticková data. Jsou tyto data kvalitní, resp. jak jsou na tom s kvalitou např. ve srovnání s daty co jsou zdarma pro Ninja trader (Download replay data)? A jak jsou na tom ostatní datové zdroje např. Zenfire, CQG, TT, iQ ? Je to asi komplikovaná otázka, pokud nedefinujeme termín "kvalitní data", ale rád bych znal Váš názor, zejména tedy na data od Sierry , TT a CQG. Michal

Link to comment
Sdílet pomocí služby

e_michal,

těžká a dosti komplexní otázka :-)

Především asi záleží asi jaký je účel a jaké jsou nároky. Vypsané zdroje neumím ohodnotit. Co jsem měl možnost sledovat data od Zenfire, tak to dle mého názoru jsou velice kvalitní data.

Posouzení dat (respektive spíš datového souboru) by se dalo rozdělit do dvou částí:
1. kvalita generovaného datového souboru jako celku
2. kvalita online ukládaných dat

add 1.) můžete mít kvalitní data + kvalitní online záznam do vašeho počítače, ale software který se souborem pracuje je může za určitých situací částečně znehodnotit, např. nějakým backfilem. Na druhou stranu patrně nemáte 24/7 puštěný software s online ukládáním dat, takže budete nějaké dočtení dat potřebovat, a opět tady je důležité jak to je dobře vyřešeno a jaká data jsou dočítána. V pricinicpu půjde o souvislost dat tak, aby tam nevznikly nějaké mezery či se tam nelišil TF (např. část dne to budou ticková data a mezitím bude třeba nějaký vyšší TF, 30sec, 1min. apod.).

Takže jde o celkové řešení. Software + zdroj dat.

U dočítání dat (což může být ta problematická část) jde o to kde je eventuální omezení, jestli u brokera nebo v případě použitého software, případně jeho nastavení.

add 2.) tady záleží v jaké podobě data dostáváte, ticková či s nějakým TF. Konkrétně pro účely J.A.testeru stačí, když se budete pohybovat na úrovni 1sec. TF. Viz uvedená technická omezení v příspěvku výše.

Ke konkrénímu případu programu SierraChart, neznám nyní přesně aktuální situaci, ale dříve právě s backfilem byl trochu problém (s TF dat), ale nyní je to nějak vylepšeno.

Pomocí J.A.testeru můžete datový soubor otestovat a zjistíte množství výskytů jednotlivých mezer mezi řádky (timeframe dat), což vám může trochu napovědět (nutno ovšem posuzovat v souvislostech jako např. jestli jsou obsaženy pouze obchodní hodiny či ne apod.).

Aleš

Link to comment
Sdílet pomocí služby

Aleš, Tak jsem ten test datového souboru hned zkusil. 200 000 řádků na FGBL H1 v lednu (od 6.1.2011) v hlavním obch. čase dopolední seance tj. 9-12. Výsledky přikládám viz. scren. Nějaké mezery tam jsou. Jde o to, "jestli je to ještě v normě", nebo ne. Každopádně je to další užitečná funkcionalita o které jsem nevěděl. Díky za odpověď. Michal

18489

18490

Link to comment
Sdílet pomocí služby

Aleš,
Ano, už jsem to zkoušel. Program se aktualizoval, export s autotestu do .csv je o.k. Program ale jakoby zůstal ve ver. 3.46 , tj. po každém spuštění program najde verzi 3.47(aktualizaci) , stáhne aktualizaci , aktualizuje , přibude zmiňovaná funkcionalita, nicméně po opětovném spuštění se program hlásí úvodním "oknem" jako verze 3.46 tj. najde aktualizaci ... 5x pokus :-) Na notebooku jsem to zatím nezkoušel. Michal

Link to comment
Sdílet pomocí služby

  • 1 month later...
  • 4 týdny později...
  • 2 years later...

×
×
  • Vytvořit...