Hozzászólások
-
SzerzőBejegyzés
-
Hozzászólás: Több MT4 idővel lelassítja a gépet? #4573
Nincs mit!
Én mpeter javaslatát is megszívlelendőnek tartom, próbáld ki azt is!
Hozzászólás: tickstory adatok 840 built #4567765-ös MT4 és fontos tudnivalók (olvasd ezt el előbb).
Hosszabb távon egyébként 7 ezer forintot abszolút megér a program – tuti, hogy megkímél némi szívástól a fizetős változat.
Hozzászólás: tickstory adatok 840 built #4565A 765-nél újabb buildeket csak fizetős TSL változat tudja indítani.
Részletek az új változat kapcsán.
Az ingyenes változat 765 vagy annál korábbi MT4 build verziót igényel.
Hozzászólás: Több MT4 idővel lelassítja a gépet? #4558- a naplófájlok esetén a több tíz megabytenál nagyobb fájlok a súlyosnak nevezhetőek, így esetedben nem ez a helyzet;
- nem a forráskód vizsgálata az első lépés, hanem a viselkedés ellenőrzése;
- a naplófájlokat kikapcsolt MT4 esetén minden akadály nélkül törölheted; ezzel viszont csak lemezterületet nyersz, egyebet nem!
- az, hogy hiba nélkül lefordul egy kód az nem azt jelenti, hogy a működés során nem okozhat problémát vagy lassulást.
A Hogyan lehet backtesztelni Metatrader4 alatt? I. rész – alapok és adatok című cikkemben a Gyertyák (oszlopok) száma bekezdés kapcsolódik ide:
A Max oszlop a chartban beállítási lehetőség jelentése: egy charton maximum ennyi darab gyertya lesz megjelenítve. Például az indikátorok értékeinek számításakor ennek a paraméternek nagy jelentősége van, hiszen ha ez az érték extrém magas, az indikátori értékek kiszámítása több időt vehet igénybe – emiatt egy erős(ebb) számítógép is belassulhat. Egy chart megnyitásakor maximum az itt megadott darabszámnyi múltbeli gyertyát fog letölteni a MT4, azonban a folyamatos futtatás közben beérkező árváltozásokkal létrejövő új gyertyák miatt ez a szám túlléphető.
Második lépésként ellenőrizd tehát a fentieket, olvasd el a cikk ide vágó részét és ellenőrizd a beállításaidat!
Ha ez sem segít, akkor érdemes egyenként tesztelni az indikátorokat és kidobálni azokat, amelyek a lassulást okozzák.
Hozzászólás: Több MT4 idővel lelassítja a gépet? #4556Az ilyen jellegű problémákért jellemzően a rosszul megírt indikátorok/expertek okolhatóak. Első lépésként azt nézném meg, hogy mekkora méretű .log kiterjesztésű fájljaid vannak a Rendszermappa\MQL4\Logs könyvtárban. Ha jelentős méretűek, akkor elképzelhető, hogy egy-egy indikátor – tudatosan vagy hibaüzenetekből fakadóan – teleírja ezeket a fájlokat. Ez eredményezhet lassulást egy idő után.
Az, hogy „üresen” jók a termináljaid, biztosan azt jelentik, hogy egy vagy több segédeszközöddel van probléma. Magától az MT4 nem lassul be.
Hozzászólás: Renko backtest #4554Nem tudok olyan módszerről, amely lehetővé tenné az egyszerű renko chart visszatesztelhetőségét.
Én nemrég egy renko stratégiát írtam meg robotnak, és abban megoldottam, hogy a robot saját magának hozza létre a szükséges renko gyertyákat a beérkező tickek alapján, majd az így kapott renko gyertyák alapján cselekszik – mindezt backtesztben. A megjelenítés egy nagyon egyszerű módon történik meg, cserébe viszont bármilyen mezei charton képes működni.
Ha opció lehet számodra fizetős megoldás is, akkor keress meg a Névjegy oldalon található elérhetőségeim valamelyikén.
Na, megvan a megoldás, válaszolt a Tickstory – ki is bővítem majd a cikket ezzel, mert valószínűleg nem volt egyértelműen benne.
Tehát: a licencet – amit kaptál a fizetés után – meg kell adnod a program Súgó – Licenc száma menüben. Ha ezt beállítod, akkor 845-ig bezárólag minden új build változatot is el tud indítani a TSL. Egyébként eleve csak 765-ig fog próbálkozni.
A másik problémád kapcsán valószínűleg az idősík, az időtartam kapcsán lesz valami probléma. Ezeket ellenőrizd elsőként.
Szerintem 765-ig működik az indítás, ezt az eredeti cikk írásakor 730 felettiként írtam. Írtam levelet a TSL fejlesztőinek, hogy mi a legutolsó build amit támogatnak – ide megírom majd a választ, ha reagáltak.
A TickData Suite-tal kapcsolatban: mindig a TDS.exe -vel kell indítanod az adott MT4-et, ha nem így teszel, akkor nem lesz megfelelő az adatminőség. Figyelj még arra is, hogy a generált adatok megfelelő helyen vannak-e, illetve hogy kizárólag „Minden tick” módban működnek ezek a megoldások.
Az utolsó kérdéseddel kapcsolatban olvasd el ezt a cikkemet, mert ebben mindent leírok amit az adatokkal kapcsolatban tudni érdemes. Az, hogy van a brókercégtől visszamenőleges gyertya adatod az utóbbi x napra, az nem jelenti azt hogy 99%-os adatminőség lesz belőle.
Hozzászólás: Éles kötés VS Backteszt utólagos különbség?? #4466Korrekt válasz!:)
Hozzászólás: Éles kötés VS Backteszt utólagos különbség?? #4464Az Ask ár járt ott, más magyarázat nincs (a manipuláción kívül, de erre kisebb az esély). Magyarul kitágult a spread.
Hozzászólás: Éles kötés VS Backteszt utólagos különbség?? #4462Csatold lécci legalább a flickeres kép pontos linkjét!
Hozzászólás: Mászkáló Trail #4436A stopleveles ellenőrzés dicséretes, de a javított érték kapcsán mindig ellenőrizd, hogy maga a javított érték kedvezőbb-e mint a jelenlegi beállított stoploss érték (értsd: LONG esetén magasabb, SHORT esetén alacsonyabb). Ha ez a feltétel nem teljesül, akkor ne engedd a módosítást, mert akkor fog „táncolni” a stoploss.
Illetve ez az 1 pont hozzáadás katasztrófális, soha ne drótozz ilyesmit a kódodba. Nincs szükség reszelésre, ha valami nem működik univerzálisan, akkor rosszul van felépítve:
OrderStopLoss() > sl + 1*Point*fpc()
Ezt felejtsd el! Használd a NormalizeDouble() eljárást, és hasonlítsd össze a konkrét, megfelelő tizedesjegyre kerekített értékeket. (Amúgy az fpc() függvény nem tudom mit csinál, mivel azt nem csatoltad.)
Ez a sor (és a Bid-es párja) hibás, mivel az egyenlőség egyébként megengedhető:
if (sl <= Ask + StopLevel*Point) continue;
Értem, hogy mit akarsz, de javítsd ki mert ez így ebben a formában helytelen.
Illetve még egy javaslatom van: a continue-k féktelen használata helyett a feltételek igaz ágára építs inkább, lévén hogy egy jól felépített kondíciós rendszernél a nem teljesülés miatt úgyis továbblép a ciklus, nem kell erre külön megkérni. Ráadásul ha már egyszer leellenőrzöd a feltételeket, akkor miért kell újra szűrni rájuk 4 sorral lejjebb? Gondolok itt az instrumentumra, magic számra, stb. Ugyanez igaz a többszöri OrderSelect-re is.
Hozzászólás: Új gyertyák azonosítása #4431Én erre úgy jöttem rá, hogy for ciklussal végigmentem 1000 darab gyertyán és kiolvastattam a másodperces pontosságra formázott időpontokat a Time[] tömbböl először az aktuális idősíkon, aztán pedig az összes többin. Sosem volt olyan, hogy ne nullára végződött volna a másodperc száma.
Dokumentálva szerintem egyébként ez sincs, bár lehet hogy azóta pótolták – a fentieket én 2009-ben próbáltam ki.
Hozzászólás: Új gyertyák azonosítása #4429Az, hogy mikor helyezi rá, azért fontos mert a felhasználók – érthetően – össze-vissza indítanak robotokat. Erre próbáltam utalni.
Ez nem befolyásolja a Time[0] értékét! – persze, hogy nem – nem is írtam ilyet.
Már miért lenne annyi? Lehet az 00:00:45 is. Mondjuk. (Vagy a Time[0] mindig kerek egész óra értéket vesz fel H1 idősíkon?) Na, itt a probléma! A Time[0] értéke mindig szabályos gyertyaidőpont lesz! Azaz hiába jön be 00:00:25-kor a H1-es gyertya első tickje, a gyertya open time -ja mindenképpen 00:00:00 -nak megfelelő unix timestamp lesz.
Amit írsz az akkor lenne igaz, ha én a TimeCurrent() -hez adnám hozzá a 3600-at – de nem, épp ezért írtam a Time[0]-át, hiszen az mindig szabályos gyertyaidőpont, függetlenül attól hogy az első tick azon a gyertyán belül mikor érkezett meg.
Ha pedig nem volt egyáltalán tick, akkor az adott gyertya kompletten kimarad.
Az utolsó Time[] elmentése és az új gyertya Time[] értékének összehasonlítását kifejezetten speciális esetekben szoktam használni, például renko gyertyáknál, ahol a kezdőidőpontok teljesen össze-vissza alakulnak ki.
Hozzászólás: Új gyertyák azonosítása #4426Nem jó a levezetésed! 25 másodpercről beszélsz az elején, a levezetésben meg ugyanez már percben van megadva.
Példa:
A felhasználó ráhelyezi a chartra a robotját, és óránkénti futtatást szeretne; a ráhelyezés mondjuk 00:22:16-kor történik meg. Ebben az esetben a következő futás időpontja 00:00:00 + 1 óra lesz, azaz 01:00:00. Amikor beérkezik a következő tick, az lehet 01:00:00, 01:00:25 és akár 01:15:06 is, lényegtelen – hiszen minden jóravaló belépési ellenőrzés egy gyertya első tickjéhez kötődik a stratégiák többségében, ezért ezzel semmiféle probléma nincs.
Gap-et is simán meg tudsz vele állapítani, csak akkor nyilván amúgy is több adattal kell hogy dolgozz. Amennyiben új gyertya jön létre, arról biztosan értesülök a következő futásos megoldásommal is – nem értem, hogy miért gondolod hogy ez nincs így. Az, hogy ez a gyertyát megelőzendő éppen mennyi gap van, az az esetek 99%-ban irreleváns, ha pedig mégis fontos, akkor az új gyertyában bekövetkező vizsgálattal egy pillanat alatt ki lehet deríteni, hogy mely gyertyák hiányoznak.
Amit utoljára írtál, az is jó megoldás.
Természetesen ha a gyertyaidőpontok kezdetével akarsz dolgozni függetlenül attól, hogy jön-e egy árva tick és épülnek-e gyertyák, akkor értem a célod, csak a megoldásod nem – hiszen te is ugyanúgy gyertyákra építesz, így a te tömbös megoldásod sem nyújt semmivel többet, mint a megfelelő idősíki Time gyertyaadatok használata. Éppen ezért nem értem, hogy miért gondolod, hogy az megfelelő. Ha gyertyák nélkül akarsz fizikai kezdőidőpontokkal dolgozni, akkor minimum TimeCurrent() vagy valamelyik Timer-es megoldás kell neked – minden másnál továbbra is a gyertyákra vagy utalva. Hiszen ha tick jön, akkor minden idősík frissül, míg ha egyáltalán nincs tick, akkor egyik sem fog.
-
SzerzőBejegyzés
