As isvis abejoju ar imanoma padaryt ant MT4 "tikrai gera" robota, man tokio neteko matyt. Tas "tikrai geras" buvo tureta omenyje apie koks nors desninguma kuris dar mazai zinomas.

Buvo kazkada toks robotas FapTurbo ar panashus shudas, kuris naudojo menka vidurnakcio likviduma, buvo ten toks desningumas , vienas forumietis simbav buvo ji atrades taip pat. Roboto backtestas buvo vos ne 100% pataikymas vienu momentu, pardavimai buvo kosminiai. Paskui girdejau kad burokeriai pradejo su tuom kovot plesdami spreda, chebra pradejo skustis kad nebeveikia, nu vnz. Kas toje situacijoje islose daugiausiai ? Zinoma FapTurbo pardavejai.

O jeigu tu platinsi sekmingas strategijas sukurtas pvz. fjuceriu birzai ar akcijoms, tai konkreciai shausi sau i koja ir manau daugumai akivaizdu tas.

Mano nuomone boto pardavimai ir prekyba - negali eit kartu. Arba darai viena arba kita.

Pamatuos realiai orderio įvykdymo laiką. Jei viskas tvarkoj, turėtų su pingu sutapti.
latencyTester_ea

Neatidavei pagarbos narcisistui. Pirmiausia turejai kazkaip nors pamaloninti, pagirti, paskui klausima uzduoti.





Vsio, kraustykis i opozicija.

Šita, dar norėčiau grįžti prie praslydimų temos. Daugelis robotų turi nustatymą "max. slippage". Vidutiniškai ant EURUSD poros pagal nutylėjimą jis būna 2 pip., bet gali būti tiek didesnis, tiek mažesnis. Tačiau, youngcat sakė, kad ECN brokeris iš viso negali kontroliuoti praslydimų. Pamėginsiu įsivaizduoti: prekiautojo terminalas atsiunčia brokeriui market tipo pavedimą. Pagal kokią kainą brokeris sudarys kontraktą su savo likvidumo tiekėju (to žinoti iš anksto neįmanoma), pagal tokią kainą ir įskaitys sandorį į prekiautojo sąskaitą. Dar daugiau: prekiautojo robotas signalą, kad atėjo laikas sudaryti sandorį nedelsiant, sugeneravo esant konkrečiai specifinei kotiruotei. Brokeris nežino ant kokios kainos robotas generuoja signalą. Todėl, įvykdęs market pavedimą, pats nežino kiek kaina spėjo nuslysti, t.y. į prekiautojo sąskaitą sandoris buvo įskaitytas kita kaina, nei kad susigeneravo signalas. Dėl atidėtų pavedimų padėtis kiek kitokia, brokeris žino ties kokia kaina prekiautojas norėtų, kad jo pavedimas būtų įvykdytas. Bet vėlgi, kažin ar brokeris norės dar prisiimti ir praslydimų riziką. O kiek atidėto pavedimo įvykdymo kaina skirsis nuo prekiautojo nustatytos, priklauso nuo kotiruočių, kurias brokeris gauna iš savo likvidumo tiekėjų.
Dabar pažiūrėkime kaip yra su market-makeriais. Netgi toks brokeris negalėtų kontroliuoti praslydimų market pavedimams, nes paprasčiausia nežino kur yra ta "teisinga" kaina, ties kuria generavosi signalas. Matyt belieka tikėtis, kad market-makeris sukontroliuos praslydimus atidėtiems pavedimams. Tą ir žada pvz. brokeris Exness. Ar dar yra kitų atvejų, kai galima pasitikėti "max. slippage" nustatymu?

Jei pavedimas "Market" tai "max slippage" nieko nieko nereiskia. Pas Market-Maker sis nustatymas taip pat nieko nereiskia. O praslydimas siuo atveju priklauso tik nuo brokerio malones. "Max slippage" nustatymas reiskia tik kur vykdymas yra ne "Market", o "Instant" tipo. Dabar pagrinde naudojamas "Market" vykdymas, anksciau pagrinde "Instant". Bet "Instant" nebutinai reiskia, kad tai Market-Maker brokeris. "Instant" vykdyme siunciamas ne "Market" pavedimas, o "Limit", todel galimi requote. Bet brokeris Market-Maker ne sprendimas, ilguoju periodu vistiek busi nugesintas.




Brokerio rizikos cia nera, dazniausia cia yra brokerio pelnas.



Jei tai Stop orderiai tai taip, bet jei Stop-Limit orderiai tai jau kitaip.

Na, čia dar man reikėtų plačiau pasidomėti. Kažkaip įsivaizdavau kad pas ECN brokerius visad market vykdymas, o pas Market-makerius - instant.

Jeigu ECN brokeris gali vykdyti tiek market (paprastai), tiek ir instant (retkarčiais), tai market-makeris tada - tik instant?



Tada išeitų, kad instant atveju praslydimai būna tik teigiami. Tačiau, kad tą pasiekti, dalis pavedimų iš viso lieka neįvykdyti?

Nu ne. Tikras ECN-STP brokeris gali tureti tik Market vykdyma, del to kad jis privalo ivykdyti pavedima. Be to jam ir nenaudingas Instant vykdymas. O jei pas Brokeri Instant vykdymas tai dar nereiskia, kad jis tikrai Market-Maker, nors taip greiciausia ir yra. Market vykdymas visiskai nesako, kad jis yra ne Market-Maker.




Taip, dalis pavedimu bus neivykdyti, bus requote. Teoriskai Instant turetu buti kaip ir tik teigiami pavedimai (cia jei atidarai pozicija tiesiogiai), bet praktikoje gali buti ir kitaip. Ten dar yra vienas nustatymas "deviation", tai jei nustacius "0" tai turetum gauti tik tuos teigiamus praslydimus, bet su ivykdymu gali buti problematiska. Esme tokia, kad Instant pavedimai yra atgyvena. Ir kai as pradejau treidinti, tai ir atsirado ECN su Market vykdymu, tai manes jau netrauke knaisiotis po atgyvenusi varianta, tai labai ir netyrinejau. Iki tol buvo 99 proc brokeriu Market-Makeriai (gal ir dabar panasiai) su Instant vykdymu. Ir ten jie visokias makles dare kokias tik sugalvojo su tais praslydimais ir requote. Ten kiti desniai galiojo

Ziuriu Dukascopy raso, kad pas juos Instant execution. Nu buna kartais, kad atmeta, kai bandai tiesiogiai Buy/Sell, na kai labai juda kotiruotes.

Taip, bet pas Dukascopy panašiai, kaip ir MT4 terminale galima pasirinkti maksimalų deviation'ą... Rankinės prekybos aš praktiškai nenaudoju, bet prieš 1.5 metų, kai programavau vieną sistemą JForex platformai, buvau radęs, kaip tą dydį nustatyti programiškai.

Taip, pasirenki max slippage ir jis labai gerai realizuotas. Jei praslydimas didesnis uz nustatytaji tai nei tiesioginis orderis neatidaromas, nei atidetas. Pvz as nusistates 0, tai jei Buy Stop, arba Sell Stop isstatatu, jei praslydimas didesnis uz 0, tai toje Stop orderio vietoje isstatomas Limit. Ir praktikoje jis visada ivykdomas pagal mano ne HFT strategijas. As labai retai tiesiogiai atidarineju, beveik visada su atidetais dirbu. Bet siemet tai is viso tik kelis sandorius tepadariau pas Dukas. Programiskai dar nieko nedariau, labai tingiu prisiversti nauja programavimo kalba isisavinti. Pas juos yra BID/OFFER orderiai, na tipo tokie kurie jau perduodami ir likvidumo tiekejams, o likvidumo tiekejai juos gali ivykdyti be spread. Kaip ten yra praktikoje tai neaisku. MT kol kas nepalaiko tokio tipo orderiu.

Susidūriau su gana keista problema. Niekaip negaliu atlikti roboto backtesto, nors ką. MT4 Journal man rodo:

2017.03.22 20:41:03.794 EURUSD,H1: 31230149 tick events (5957 bars, 31231149 bar states) processed in 0:00:49.951 (total time 0:01:36.081)
2017.03.22 20:40:13.830 2016.04.20 00:00:00 (expert name) inputs: (inputs);
2017.03.22 20:39:30.244 TestGenerator: spread set to 2
2017.03.22 20:39:16.330 (expert name) EURUSD,H1: loaded successfully

Report'e rašo, kad buvo nulis sandorių, ir visur kitur rodo nulius.
Tačiau, realioje sąskaitoje tas pats robotas prekiauja.
Gal įsivaizduojate kas nors, ką tokio įmanoma padaryti netinkamai, kad gauti "nulinius" backtesto rezultatus.

Jei roboto kūrėjas taip sugalvotų, galėtų realizuoti tokį tikrinimą... MQL kalboje yra funkcija, kuri leidžia atlikti tikrinimą, ar robotas veikia BackTest'o režimu.
Na, bet aš labai abejoju, ar ši priežastis yra tikroji...

Ar įmanoma turint tik roboto ...ex4 failą pridėti naujus tam tikrus nustatymus? Šiuo atveju labai reikėtų pridėtu nustatymą "Max. spred". Kaip jau kalbėjome forume, nustatymas "Max. slippage" realiai gali riboti praslydimus nebent jeigu brokeris naudoja instant vykdymą. Tačiau, nebuvo kalbos kad nustatymas "Max spread" būtų beprasmis. Jeigu ....ex4 failo pakoreguoti neįmanoma, tai gal yra kokia nors kitokia alternatyva, kaip techniškai riboti tą nelemtą spredą. Ar čia tada gaunasi maždaug: "bijai išsiplėtusio spredo - rinkis fiksuoto spredo sąskaitą".

Pastebėjau, kad išsiplėtusį spredą robotas gali palaikyti staigiu kainos judėjimu ir atidaryti sandorį ne tik kai pagal algoritmą akivaizdžiai tam nėra pagrindo, bet ir pačiu netinkamiausiu metu. Na, ko galime tikėtis, atidarius sandorį su 15 pip. spredu.

Dar galvoju, kad gal įmanoma kaip nors alternatyviai padaryti, kad robotas neprekiautų per didžiuosius spredo išsiplėtimus (pvz. per tarpušvenčio savaitę, pirmadienio rytą vos tik atsidarius rinkoms). Pvz. gal galima būtų sukonstruoti pagalbinį robotą, kuris pats neprekiautų, tačiau, "pamatęs" kad spredas išsiplėtė labiau nei kad nustatėme, padarytų taip, kad dingtų terminalo ir brokerio serverio ryšys. Terminalą vėl "pažadinti" robotas turėtų spredui tapus leistinam. Tokiu būdu apsisaugočiau nuo visiškai nepageidautinų ir neišvengiamai nuostolingų sandorių, spredui nenormaliai išsiplėtus.

Ar iš viso, geriau tiesiog rašyti tokius klausimus MQL5 bendruomenės tinklapyje. Ten kas negalės, tas patylės. jei kas galės, tai ne tik pasakys, kad įmanoma, bet ir suprogramuos tokį pagalbininką.

O tai kaip robotas zinotu, kad spreadas jau pasidare normalus, jei nebutu rysio su serveriu?

Na gal tada tam menamam pagalbiniam robotui būtų galima tiesiog nurodyti konkretų laiką, kad terminalas turėtų netekti ryšio su brokerio serveriu, ir kada jį atstatyti. Pvz. paskutinę senųjų metų savaitę, pirmą naujųjų, ir pirmą valandą (t.y. iki 01:00) kiekvieną pirmadienį vos tik atsidarius rinkoms.

Bet toks variantas visiskai negelbetu nuo isispletusio spreado. Jei tik tiek retai, tai ir pats geletum ijungti / isjungti EA.
Siaip as is viso nezinau ar yra kokia nors galimybe pas MQL "prarasti rysi" kaip nors, kokiu nors atsiloginimo / prisiloginimo budu ar kitokiu. Niekada neprireike, tad ir nesidomejau.

Mano tikslas - pasiekti, kad į roboto darbą galėčiau VISIŠKAI nesikišti. Kad užtektų pora kartų per metus pažiūrėti, kiek pelno jis priprekiavo Tai nenorėčiau pats prisiimti rūpestį įjunginėti ir išjunginėti. Be to, kartą per savaitę įjungti ir išjungti nėra taip jau retai. Jeigu jau yra pagalbinis robotas, kuris, dingus ryšiui ir savaime jam neatsistatant, ryšį atkuria http://tradelikeapro.ru/fxblue-auto-restart/ tai gal yra ir toks, kuris reikalui esant tą ryšį pradangina. Kita vertus, geriau jau tokį užsakymą paskelbti MQL5 markete, tada ir bus matyti, ar čia nenuklydau į fantazijų pasaulį.



Kaip tai negelbėtų? Kai spredas bus išsiplėtęs (nekalbu apie momentinį išsiplėtimą prieš pat skelbiant naujienas), tai terminalas neturės ryšio su brokerio serveriu ir nebus sudarytų sandorių, prie 15 pip. spredo.

Paprastai kuriant EA tikslai buna kuklesni - padaryti, kad jis butu pelningas. Bet tai labai sunkiai igyvendinama ir su pastoviais atnaujinimais bei korekcijomis.



Tai realizuota ne MQL funkciju pagalba.



Gera ideja.



Nu jei tik tiek tereikia tai viskas OK. Bet gausis kad issigelbesi nuo 15pip spreado tam tikrais laiko periodais, bet nesisigelbesi nuo dvigubai didesnio per newsus. Bet jei konstruoti EA ne tik is standartiu MQL funkciju, tai jau gal ir nebutu skirtumo kuri varianta dayti.

Naujus roboto parametrus pridėti galima tik jį perkompiliuojant... Žodžiu, reikalingas roboto išeities failas *.mq4. Su senesniais MQL kompiliatoriaus Build'ais kompiliuotus robotus buvo galima dekompiliuoti - t.y. iš *.ex4 paversti į *.mq4. Tiesa, tokiu būdu dekompiliuotas *.mq4 failas neprilygsta 100% išeities failui, nes prarandama kintamųjų vardų informacija, komentarai ir kt. Tačiau tai tik nežymūs trūkumai, nes robotą perkompiliavus vėl gaunamas pilnai funkcionalus *.ex4 robotas.
Su naujesniais MQL kompiliatoriaus Build'ais problema ta, kad dekompiliatoriaus versijos nuolat atsilieka. Gal pačių naujausių net iš viso nebeįmanoma dekompiliuoti - šios info aš nežinau...