Hozzászólások
-
SzerzőBejegyzés
-
Hozzászólás: Több devizapár backtest-jének egybeolvasztása #3401
Egyik olvasóm nemrég ezzel a programmal kapcsolatban kérdezett: ReportManager.
Sajnos arra jutottunk, hogy a riportokból nem teljesen jól olvassa ki az értékeket a program, és amikor ezt jeleztük a fejlesztőnek, akkor nemigazán értette a problémát, és emiatt nem lett javítva a hiba.
Mindenesetre azért nézd meg, mert ez a program ingyenes.
Hozzászólás: Függő megbízás adott időben #3397A megoldásodban az a hiba, hogy a feltétel állandóan teljesülni fog, ha az idő nagyobb vagy egyenlő mint az adott Entry_Hour. Ezért arra is figyelned kell, hogy az adott napon bekövetkezett-e már a feltételed. Ellenőrizheted például a számlatörténet alapján, hogy történt-e már belépés a mai napon, vagy még jobb, ha egy jelzőt (szemafort) helyezel el. Például egy globális változó átállításával és lekérdezésével meggyőződhetsz erről.
Az első feltétel ellenőrzésekor a TimeHour(TimeCurrent()) helyett használd a Hour() függvényt!
Itt egy alap példa:
// A beállított órában vagyunk? if (Hour() >= Entry_Hour) { // Ha igen, ellenőrizzük hogy a mai napon történt-e már belépés Mai_belepo = GlobalVariableGet("entry_date"); if (Mai_belepo != Day()) { // Cselekvés Print ("A mai napon (", TimeToStr(TimeCurrent(), TIME_DATE), ") megtettem valamit..."); // A mai nap mentése a globális változóba GlobalVariableSet("entry_date", Day()); } }Természetesen a fenti példa nem 100%-os, hiszen a teszt végén a deinitben figyelni kell arra, hogy a globális változó törlésre kerüljön:
if (IsTesting()) { GlobalVariableDel("entry_date"); }A programozás során figyelni kell a következőkre is, amire a tesztkódom nem tér ki:
- valósidejű futtatásnál ne csak a napot, hanem a konkrét dátumot mentsük el TimeCurrent() segítségével, és a visszaellenőrzésnél csináljunk belőle napot a TimeDay() függvénnyel
- ha egy számlán belül több robotpéldányt futtatnánk, akkor a globális változó neve valami módon egyedi legyen – például legyen benne az instrumentum neve és a robot magic száma is: pl. entry_date_EURUSD_88
Hozzászólás: Veszteség, külső input #3396Ellenőrizd le, hogy van-e elegendő pénz a tesztben (induló tőke).
A 0/1-es változód kapcsán: a billentyűre reagálás megoldható, de rendkívül körülményes. Az egyszerűbb jobb alapján inkább egy külső változót javaslok, amely a meglévő kereskedések menedzselését engedi, míg az új pozíció nyitást tiltja. Pl.: TradeEnabled = true/false.
Hozzászólás: Chart terület nagyítás #3395Nincs mit, jó monitor-vadászatot! :)
Hozzászólás: Ledarálás? #3394herp: sajnos én csak mezei metaeditoros programírással foglalkozom, így a vizuális szerkesztőkben nem vagyok kompetens :( Azt hiszem, István segítségével többre mész! :)
István: köszönöm, hogy válaszoltál és segítettél!
Hozzászólás: Chart terület nagyítás #3391A második képen a felbontásod miatt ugyanazon a zoom szinten több adat fér el a képernyődön. Tudomásom szerint ezt más módon nem tudod elérni, csak ha a felbontásodat növeled.
Megnyugtatlak: nekem 27″-es monitorom van, és 1920×1080-as felbontásom. És ez sem elég mindenre:)
Remélem, jól értettem a kérdésed.
Hozzászólás: Veszteség, külső input #3390Szia Gábor!
Az első kérdésed kapcsán:
Milyen stratégiáról van szó? Ha pl. ellentrendben/trendben építkezős, akkor a problémád onnan ered, hogy nem mindegy az első kötés helye, ami alapján a többi kötés majd datálódik. A bővebb válaszhoz ismernem kéne a stratégiát – így látatlanban a pozícióhalmozódás, és az ezzel kapcsolatos elszállás/túlzott kitettség lehet az ok (sok más egyéb mellett).A második kérdésed kapcsán:
A kérdésed vizuál tesztben, manuális megállításra vonatkozik? Mert ott a Pause/Break feliratú gomb használható a billentyűzeten.Amennyiben programkódon belül szeretnél ilyen megoldást eszközölni, ott én az úgynevezett „szemafor” módszert javaslom. Azaz kell hogy legyen egy szemaforod (jelződ), amely megakadályozza a robotot az új pozíciónyitásban (többpozíciós rendszer esetén építkezés indításában), azonban a meglévő pozíciót/pozíciókat lemenedzseli. Szemafornak használhatsz egy fájlt, vagy akár egy globális változót – én jellemzően az utóbbiakat veszem igénybe.
Az így elhelyezett szemaforokat természetesen majd kézzel kell törölni, mert a robot nem mindig tudhatja, hogy az adott szemafor érvényben van-e még, vagy csak egy korábbi futtatás eredményeként maradt ott.
A jelző elhelyezése történhet pl. az első pozíció megnyitásakor, vagy egy más esemény bekövetkeztekor – ez teljes mértékben rád van bízva.
Programkódot azért nem írnék most első körben, mert egyelőre megvárom hogy kifejtsd hogy pontosan mire is gondolsz.
Hozzászólás: Több idősíkot használó indikátorok #3379Én köszönöm, hozzáadtam a hibajegyet a MetaQuotes rendszerében. Amennyiben kapok választ, jelzem azt ebben a topikban.
Egyébként kijött egy új build a tesztszerveren (650), és az még nem tartalmaz semmilyen változást ezzel a problémával kapcsolatban.
Hozzászólás: CloseBy() invalid ticket #3373Nekem nem teljesen tűnik átláthatónak az a kódrész, amelyben a RefreshRates() és a két OrderCloseBy sor van, hiszen az a kódrész mindig lefut, függetlenül attól hogy mi az if kiértékelések eredménye.
Illetve a két OrderCloseBy helytelen, hiszen egy nyitott pozíciót zársz a másik ellenében.
A következő for iterációban pedig az egész indexelés felborul.
Ha {} jelek nélküli ifet használsz, akkor az első pontosvessző után befejeződik az adott feltétel.
int type = OP_BUY; if (type == OP_BUY) Print ("Ez egy BUY!"); if (type == OP_SELL) Print ("Ez egy SELL!");A kódodban viszont a SELL feltétel sora után van egy { } kódrész, ami mindig lefutásra kerül. Javaslatom az, hogy az átláthatóság kedvéért minden feltételt – főleg, ha több utasítás van utánuk – így használj:
int type = OP_BUY; if (type == OP_BUY) { Print ("Ez egy BUY!"); } if (type == OP_SELL) { Print ("Ez egy SELL!"); }Illetve, olvasd el még a Pozíciók zárása című cikkemet, mert a pozíciók indexelésének felborulása is okozhat kellemetlen meglepetéseket.
A fentiek közül bármelyik okozhatja a hibák tömkelegét. Azonban ezek a hibák nem az új fordítótól, hanem eleve programozási hibákból erednek.
A continue; használata is teljesen felesleges, hiszen akár egymásba ágyazott, akár párhuzamos if-ekkel kiválthatod őket.
Hozzászólás: Több idősíkot használó indikátorok #3366Szívesen bejelentem, de idő szűkében vagyok. Így megköszönném, hogy – amennyiben jól írsz angolul – megírnád a leírást, képernyőképekkel együtt (úgy, ahogy nekem küldted, csak angol kiírásokkal). Ezt megtennéd?
Hozzászólás: csv adatformátum #3365Szia kilovolt78!
Az a cikk már meglehetősen idejétmúlt infókat tartalmaz. Olvasd el ezt a cikket, és használd a Tickstory Lite programot!
Hozzászólás: Több idősíkot használó indikátorok #3362abunba, végülis jelentetted már a hibát a Service Desk-en? E-mailben mástól is megkaptam ezt a felismerést, úgyhogy egyre inkább úgy fest, hogy bugot találtál, amit jó lenne jelenteni.
Hozzászólás: kernel32.dll #3360Köszönöm, hogy megosztottad.
Kódformázásra a következő tagekkel nyílik lehetőség (a space-eket ki kell venni a p r e-ből, csak azért írtam be, hogy látszódjon a kód):
<p r e lang="mql"> MQL forráskód </p r e> <p r e> Egyéb forráskód </p r e>Hozzászólás: Több idősíkot használó indikátorok #3356Úgy nézem, teljesen helytálló a megállapításod. A témától független észrevételem: a jövőben javaslom, hogy használj konstans neveket (1440 helyett PERIOD_D1), mert így nehezebben olvasható a kód.
Megoldást egyelőre nem tudok, mert ez így valóban nem normális működés, és régen tényleg nem volt ezzel baj.
Hozzászólás: Több idősíkot használó indikátorok #3355Elküldenéd az indikátort és az expertet a radu kukac radu pont hu címemre? Megnézem úgy is. Nincs kizárva, hogy a MetaQuotes megint valami disznóságot követett el :)
-
SzerzőBejegyzés
