Eubie

@flakac: A jaký jste měl důvod k tomu začít psát vlastní software? Ptám se proto, že z vašeho příspěvku není jasné ani proč jste začínal, ani proč máte problémy. Jestli jste začínal psát vlastní platformu doslova a do písmene (tj. např. vlastní parser FIX protokolu), tak by mě zajímala Vaše motivace. Pokud jste začal psát jen třeba optimizer, proč Vás to zabrzdilo?

Dobrý den, Petře, mohl byste nastínit, o jakých fondech mluvíte konkrétně? Zajímaly by mě ty materiály, které jste od nich získal. Díky a zdravím, Daniel

trader0501: Ahoj, v době, kdy jsem je porovnával (cca 5 let zpět, cenově to bylo stejné jako dnes) jsme je porovnávali s daty ze ZenFire a z replaye a rozdíly tam byly, pokud si pamatuju, denní volume se lišilo i o procenta, což na kontraktu jako je Russell není zrovna pár kontraktů. Jelikož disktrading neříkají, odkud data mají, považoval jsem je implicitně za ta "nedůvěryhodná", ale tahle konkluze může být mimo. Obecně ale záleží na tom, na čem obchoduješ. Pokud obchoduješ na 5m grafech s indikátory, tak ti pár kontraktů asi nic moc nezmění. Pokud už bys hledal něco ve volume distribuci nebo dokonce deltě, tak bych si dovolil tvrdit, že jet na datech, která denním volume nejsou hodně blízko dennímu volume reportovanému samotnou burzou, je tak trochu ruleta. Hodně zdaru, D.

Zdravím, Honza K má pravdu. Kdo chce "rychle zbohatnout", ať si směle koupí data z disktrading.com a pro zachování duševního zdraví a iluze svojí světáckosti je neporovnává s těmi nahranými ze CQG nebo nedej bože IQFeedu (proč si taky platit IQFeed když CQG je zadara, "logicky"...) . Jít na fórum a chtít data dokáže každej. Někde data zadarmo jsou - pak mě napadá, proč si je lidi na fóru žádající o data nesosli z těch free zdrojů sami. Pokud free nejsou a jejich sehnání/zpracování vyžaduje čas a úsilí, je odměna úplně na místě - potom nechápu výkřiky, jak je ta dvacka děsná. Dvacka za rok kvalitních dat jsou šušně, rok dat z CME pro jeden instrument stojí USD 1800, jen pro představu, a s jejich zpracováním je práce jak na kostele, bez vlastního parseru si neškrtnete. Kdo data chce, způsoby si najde. Já stahuju replay do NT, přehrávám si je a pomocí gomRecorderu ukládám do .gom formátu, odkud je potom v C++ čtu do vlastního backtesteru. Mnoho úspěchu, D. P.S. Honzo, díky za pěkný a konstruktivní poslední post, já bych ty nervy neměl:)

Dobrý den kvočure, můžu se zeptat, jaká historie je při takovém settingu k dispozici? Jsou k dispozici jednotlivé splatnosti nebo spojitý kontrakt? Jedná se o tick data? Díky!

kvocour: Jaka data ma SieraCharts? Tickova? Pokud ano, jdou asi jednoduse prekonvertit mezi SC a NT. Pro NT bych nejaka data mel. Jde o to, jestli SC ma tickova:)

Tak toto je naprosto skvělý článek. Díky za něj, fakt moc.

Ještě ad. TF data poslaná za rok 2010 - zřejmě překlepem došlo k vynechání úseku 10.9.2010 - 10.10.2010, výřez z tick souboru je 20100909 171849;638;1 20100909 171907;638.1;1 20101009 003003;691;1 20101011 000000;691.7;1 20101011 000000;691.7;4 Nešlo by to nějak napravit a postnout celá data? Díky, Dan.

Ahoj Tome, chtěl jsem tě požádal, jestli bys byl tak hodný a postnul ticková data z TFka od 8.12.2010, kde končila ticková data za rok 2010. Díky mockrát! Zdraví Dan

fxmagico: Možná už jsou tyhle výsledky překonané, ale už v Golbergovi se píše, že vyšší počet jedinců v GA nemá na rychlost konvergence vliv. O GA v SVM nic nevím, takže pokud jste 1000 jedinců bral z nějakého doporučení, neberte tento komentář v potaz, pokud jste ho ale jen tak nastřelil, zkusil bych i menší počet, až budete mít hotové operátory a selekci.

Zdravím Vás! Jsem rád, že se tu na finančníkovi objevilo takovéhle téma. V nadcházející době se chystám modelovat range následujícího dne a chtěl jsem se zeptat, zda tu někdo s touto problematikou má zkušenosti. Akademická obec nabízí VECM/ARMA modely nebo modely z ARCH rodiny, nicméně R-kvadrát se spíš ve výjimečných případech přehoupne přes 50%, což je pro trading žalostně málo. Ad MSE: Na internetu jsem narazil na jeden paper, který do vyhodnocování predikčních modelů na obchodních datech zahrnul vedle MSE a podobných měr i profit nějaké sample strategie. Výsledek byl takový, že vztah mezi kvalitou modelu dle MSE a dle profitu není jednoznačný a model s nejhorším MSE byl snad v jednom případě nejprofitabilnější. Tedy, pokud chcete modelovat něco pro praktické použití v tradingu, je použití MSE apod. diskutabilní. Mnoho zdaru!

Díky vladko, už jsem měl bobky, že se indikátory vykreslují na základě tickových dat a ne na základě barů.

vladko11, posílám screenshot z NT. Dole jsou dva indikátory, RSI počítané z Close s periodou 14 a různým smooth. Zřejmě parametr smooth je to, co o čem je moje otázka. Ví k němu někdo něco bližšího? Obrázek mi nešel vložit přímo do fóra, proto jsem ho dal sem eubie.sweb.cz//ES%2009-09%20%2031_7_2009%20(1000%20Volume).jpg RSi s vyšším smooth je prostě víc vyhlazené a jakýsi algoritmus, který hodnotu Smooth využívá, dělá ze skákající nehladké křivky RSI (ta zelená) něco hezky koukatelného:) Problém je, že při různých hodnotách Smooth proráží RSI nějaké hodnoty v jiných časech. Že by další parametr na zbacktestování?

Zdravím všechny, jsem na foru nový a proto nemohu zakládat vlastní topicy. Proto píšu sem. Snažím se napsat vlastní polobacktestovací aplikaci z tickových dat. Vše se pomalu vyjasňuje, ale jedna věc mi zůstává záhadou. Pokud si vezmu například indikátor EMA, mohu jeho hodnotu vypočítat při uzavření každé svíčky. Co nechápu je princip, jakým se například ta EMA vykresluje jako spojitá křivka a nikoliv jako množina bodů nad/pod/uvnitř dané svíčky pokaždé po jejím uzavření. Nechápu, jak dostanu ty "body mezi". Nebo je to tak jednoduché, že se mezi ty body vloží nějaká křivka, třeba spline, a ve skutečnosti je ta EMA pouze množina pospojovaných bodů nad/pod/uvnitř svíček? Děkuji za odpověď, E.

fishkiller Napsal: ------------------------------------------------------- > Zdravím, > rád bych se optal na to jak správně převést > ticková data na volume data, řekněme Volume2000. > Díky moc za odpovědi Zdravím fishkillere. také mě tato otázka napadla a moje řešení je asi takové: 0/ Jsme v situaci, kdy čteme první tick a z nového baru ještě nemáme vykresleno nic 1/ načtu tick 2/ Open volume baru nastavím na cenu ticku 3/ proměnnou Sparovanych_Obchodu nastavím na pocet kontraktu ticku Nyní příchází while cyklus: 4/ dokud je Sparovanych obchodu menší než požadované Volume, činíme 4.1/ je-li Price ticku menší než low volume baru, nastavíme low = price 4.2/ obdobně pro high 4.3/ načti další tick 5/ přečetli jsme tolik ticků, že spárovaných obchodů překonalo požadované volume. Proto close volume baru nastavíme na price ticku a můžeme celý proces opakovat pro vytvoření dalšího volume baru. V Excelu neumím, nicméně si dokážu představit, že ve VBScriptu je to věc na čtyřicet řádek i s načítáním do struktur. Díky tvojí otázce mi došlo, jak je možné, že někdy je close jedné a open následující svíčky různé a někdy totožné. Pokud budeme mít data ve formátu Cena Počet_Kontraktů potom sekvence Cena1 5 Cena2 2 Cena3 1 Cena4 2 vytvoří při Volume 6 dva bary. První z nich bude obsahovat prvních 5 kontraktů za cenu1 a jeden kontrakt za cenu2, open bude cena1, close bude cena2. Následující bar bude mít open cena2 (neboť jsme z druhého obchodu započítali do prvního baru pouze první kontrakt). Pokud ale budeme vytvářet Volume5 bary, vytvoří se sice taky dva, ale open i close prvního baru bude Cena1 zatímco open druhého baru bude Cena2. V prvním případě tedy Open a Close přilehlých barů navazují, v druhém případě nikoliv. Doufám, že se v tom zmatlaném rádoby-pseudo-kódu někdo vyzná:)