Çok para birimli Uzman Danışmanların test sonuçları - sayfa 5
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Hangi gerçeklikten bahsediyorsun? Gerçek zamanlı test? Evet ise, kesinlikle katılıyorum. İki uzmanı sembollerine asarsanız, her şey doğru olacaktır. Ama çoklu para birimi modunu test ediyorum. Ve aynı sonuç yalnızca OnTimer () işleviyle (10 saniye) gösterilir.
Çoklu para birimi modunda gerçek bir lansmandan bahsediyorum (Uzman Danışmanlarda (her bir Uzman Danışmanda) her bir sembol için ayarlanmış N sembol üzerinde işlem yapmak) - bu gerçek bir değerlendirme sağlar ve bir testçi durumunda, siz her şeyden önce test modlarını karşılaştırın ve çok para birimli onay işleme yöntemlerinin her birinin doğru çalışmasını değil. Hepsi test cihazının yapay ortamına dayanıyorsa, farklı modları karşılaştırmanın anlamı nedir? Çalışmaların sonuçlarının kimliği, ticaret açısından en doğru sonuçları verdiğini iddia etmek için temel oluşturmaz, bu, test cihazının iç mekanizmaları açısından en uygun olanıdır.
Doğru ifadeyle başlayalım. Orijinal örnekte, "Eurodollar'ın işlem görmesini" istiyorsunuz. Aslında, kullanıcı olayları iki sembolden alındı ve olay işleyicide, olaylar bu iki sembolden herhangi birinden alındığında TradeSignalCounter()+TradePerformer() işlevleri çağrıldı. Olay kuyruğunun her zaman sınıra kadar dolu olduğu varsayılabilir.
Şimdi sinyal kaynaklarından birini kaldırdınız, ancak bir nedenden dolayı olay işleyicisine " if (sparam == Symbol_01)" kontrolünü girdiniz. Ama başka bir soru farklı. Koda bakılırsa, "Tüm işaretler" modunda Lizar'ın şemasını kullanırsınız ve sinyal kaynağından (EURUSD) gelen her işarette TradeSignalCounter()+TradePerformer() işlevleri çağrılır. İlgi zaten olay kuyruğunun olası bir taşmasına işaret etti. Ayrıca bu iki işlev için Symbol_01 parametresi olarak hangi enstrümanı kullandığınızı merak ediyorum ve Lizar'ın şemasındaki olayların sıklığını değiştirmeyi denediniz mi?
Evet, istedim. Sonuçta, her eylemimiz arzumuz tarafından kışkırtılır. Bu durumda, tam olarak istediğimi aldım. Yani ticaret sadece EURUSD üzerinde gerçekleştirilmiştir, çünkü TradePerformer () işlevinde sembol dizisindeki her bir sembol için ticaret izni için bir kontrol yapılır. Bu seçenek harici değişkenlerdedir ve o sırada GBPUSD sembolü üzerinde işlem yapmak yasaktı. Kullanıcı olayları iki sembolden geldi, ancak olay işleyicide tekrar ediyorum, TradePerformer () işlevi yalnızca EURUSD sembolü üzerinde işlem yapılmasına izin verdi. TradePerformer () işlevi ayrıca belirli bir sembol üzerinde yeni bir çubuk oluşup oluşmadığını belirleyen bir işlev içerir, bu durumda EURUSD . Olay kuyruğunun her zaman dolu olduğu varsayımınız doğruydu, ancak bu durumda her şey ayrı ayrı işlendi ve günlük çubuklarda test yaparken bir tık gecikmesi önemli değil.
Teste katılmaması gereken bir sinyal kaynağının kaldırılması, yalnızca her şeyin daha önce doğru şekilde yapıldığını doğruladı. " if (sparam == Symbol_01)" testi, test edilmemesi gereken, ancak geçmesi gereken sinyal kaynağını çıkarmadan sonuçları kontrol ettiğimde kaldı. Bu kontrolün aslında gereksiz olduğu bile ortaya çıktı. Sonuçlar değişmedi. Symbol_01 parametresi EURUSD sembolüdür. Olayların sıklığını değiştirmeyi denedim ama bu hiçbir şeyi değiştirmedi. Daha doğrusu all tiki modu en doğru olanı diyebilirim.
Çoklu para birimi modunda gerçek bir lansmandan bahsediyorum (Uzman Danışmanlarda (her bir Uzman Danışmanda) her bir sembol için ayarlanmış N sembol üzerinde işlem yapmak) - bu gerçek bir değerlendirme sağlar ve bir testçi durumunda, siz her şeyden önce test modlarını karşılaştırın ve çok para birimli onay işleme yöntemlerinin her birinin doğru çalışmasını değil. Hepsi test cihazının yapay ortamına dayanıyorsa, farklı modları karşılaştırmanın anlamı nedir? Çalışmaların sonuçlarının kimliği, ticaret açısından en doğru sonuçları verdiğini iddia etmek için temel oluşturmaz, bu, test cihazının iç mekanizmaları açısından en uygun olanıdır.
Şimdi net. Ancak başlangıçta tartışma, test cihazında test etmekle ilgiliydi. Sonuçta, ticarete başlamadan önce sistemin test edilmesi gerekiyor. Ve test ne kadar doğru yapılırsa, gerçek ticarette o kadar güvende hissedeceksiniz. Sunulan test sonuçları, neyin doğru ve yanlış olarak test edilebileceğini göstermektedir. Artık herkesin bir seçeneği var ve herkes neyin doğru neyin yanlış olduğuna kendisi karar verebilir. Tüccarlardan biri çok haklı bir şekilde belirtti (yanılmıyorsam bu Van Tharp): "Fikirlerimizle ticaret yapıyoruz." Bu cümleye şunu ekleyebilirim. Biz sadece fikirlerimizi satmıyoruz. Hatta sadece fikirlerimizle yaşıyoruz. ))
Gerçek ticarette veya testte her bir sembole ayrı ayrı bir uzman koyarsanız, bu en doğru seçenek olacaktır. Buna elbette katılıyorum. Ancak bunun için çubukları senkronize etmenize gerek yoktur. Kesinlik ile süre gelir. Test cihazında uzun tarihsel dönemleri değerlendirebilirsiniz. Ve kişisel olarak, doğru test sonuçlarını görmeyi tercih ederim.
Bir şeyi daha belirtmek istiyorum, bir yerde yanılmış olma ihtimalimi asla dışlamıyorum ve her zaman her şeyi kontrol ediyorum. Ancak en sıkı kontrollerden sonra bile, ilk bakışta her şey yolunda görünüyorsa, yine de bir yerde bir hata olabileceğini göz ardı etmiyorum. Şu anda, sunulan test yöntemlerinin sonuçlarının değerlendirilmesi ile aynı fikirde olmayan biri varsa, test sonuçlarınızı karşılaştırmalı olarak sağlamanız gerekir. Ne de olsa, bu başlığın amacı, kimin doğru veya yanlış olduğunu sadece kelimelerle değil, nasıl doğru yapılacağını veya daha kesin olmak gerekirse, çok para birimli Uzman Danışmanların nasıl doğru bir şekilde test edileceğini bulmaktır. Gerçekler, sadece gerçekler ve sadece gerçekler! )))
Hepsi test cihazının yapay ortamına dayanıyorsa, farklı modları karşılaştırmanın anlamı nedir?
Önemli olan, elde edilen sonuçlara göre doğru kararı vermektir. Ancak çarpıtılmış verileri analiz etmekte kesinlikle bir anlam görmüyorum. Sonuçta ne ekersen onu biçersin.
Teste katılmaması gereken bir sinyal kaynağının kaldırılması, yalnızca her şeyin daha önce doğru şekilde yapıldığını doğruladı.
"... ondan önce her şey doğru yapıldı" - bu gönül rahatlığı kategorisinden. Başlangıçta yanlıştı. Görünüşe göre, "olay kuyruğunun taşması" gibi bir olguya önem vermiyorsunuz. Özellikle olayları kenelerle aktarırken. Bu konudaki yardım materyallerine ve foruma bakın. Anahtar kelime "sıra" dır.
... ticaret sadece EURUSD üzerinde gerçekleştirildi, çünkü TradePerformer () işlevinde, sembol dizisindeki her bir sembol için ticaret izni kontrolü var. Bu seçenek harici değişkenlerdedir ve o sırada GBPUSD sembolü üzerinde işlem yapmak yasaktı. Kullanıcı olayları iki sembolden geldi, ancak olay işleyicide tekrar ediyorum, TradePerformer () işlevi yalnızca EURUSD sembolü üzerinde işlem yapılmasına izin verdi. TradePerformer () işlevi ayrıca belirli bir sembol üzerinde yeni bir çubuk oluşup oluşmadığını belirleyen bir işlev içerir, bu durumda EURUSD . Olay kuyruğunun her zaman dolu olduğu varsayımınız doğruydu, ancak bu durumda her şey ayrı ayrı işlendi ve günlük çubuklarda test yaparken bir tık gecikmesi önemli değil.
TradeSignalCounter()+TradePerformer() işlevlerinin yalnızca bir sinyal kaynağından gelen olayları işlemesi, olay kuyruğunun durumunu ve olası taşma durumunu değiştirmedi. Başka bir deyişle, "GBRUSD sembolündeki olayların işlenmesini yasaklamak", ilgili olayları olay kuyruğundan hiç kaldırmadı. Üçüncü kez soruna dikkat çekiyorum: "İlgi zaten olay kuyruğunun olası bir taşmasına işaret etti" :) Sadece "bir tık geç kalmaktan" bahsettiğimizi düşünüyorsanız, o zaman bu tür sonuçlar neye dayanıyor?
"... bu durumda, her şey ayrı ayrı ele alındı." Sorun, orijinal sürümde, olay işleyicinin her iki sinyal kaynağından da olaylar alındığında işlevleri çağırması ve ardından bu işlevlerin "gereksiz" kaynaktan gelen sinyali filtrelemesidir. Ancak işlevler her (!) seferde çağrıldı.
Günlük çubuklarda test yapılırken bir tık gecikmesi önemli değildir.
Evet, olay işleyicisinin hangi periyotta test edildiği önemli değildir. Lizar'ın planı tik başına sinyal üretiyorsa, günde bir kez değil, tik başına olay kuyruğunu doldururlar.
"Olayların sıklığını değiştirmeye çalıştım ama bu hiçbir şeyi değiştirmedi. Daha doğrusu all-tick modunun en doğru olduğunu söyleyebilirim." Lizar'ın kene olmayan modlarında karşılaştırmalı ekran görüntüleri sağlayabilir misiniz?
Gerçek ticarette veya testte her bir sembole ayrı ayrı bir uzman koyarsanız, bu en doğru seçenek olacaktır. Buna elbette katılıyorum. Ancak bunun için çubukları senkronize etmenize gerek yoktur. Kesinlik ile süre gelir. Test cihazında uzun tarihsel dönemleri değerlendirebilirsiniz. Ve kişisel olarak, doğru test sonuçlarını görmeyi tercih ederim.
Önemli olan, elde edilen sonuçlara göre doğru kararı vermektir. Ancak çarpıtılmış verileri analiz etmekte kesinlikle bir anlam görmüyorum. Sonuçta ne ekersen onu biçersin.
"Doğruluk" kategorisinin artık test cihazı çalıştırma kimliği ile değiştirildiğini belirtmeye çalışıyorum, ancak bu, bu tür verilerin daha az çarpık olduğu anlamına gelmiyor. Özellikle, 10 saniyelik bir aralık seçtiniz, bu da kuşkusuz verileri örneğin 5 veya 1 saniyelik aralıklarla olduğundan daha fazla bozuyor. Onlar. 10 saniyelik bir zamanlayıcı ile size tercih edilen yöntemi sağlayan test ortamındaki bir özellikten yararlanıyorsunuz. Aslında, zamanlayıcı olayları olan tüm enstrümanlara yeni çubukların tiklerinin geldiği anı "yakalamaya" çalışıyorsunuz ve bunu yapmanın en iyi yolunun OnTick olayı olduğu oldukça açık.
Zamanını boşa harcama. Keneler üzerinde asla tam bir eşleşme elde edemezsiniz. Barın kapanma süresi, farklı enstrümanlar için farklıdır ve biri için farklıdır.
Enstrüman, şimdiki zaman barın kapanma zamanıdır, ikincisi için bar henüz oluşmamıştır ve üçüncüsü için birkaç tik önce oluşmuştur.
Tik geçmişine bakın, tik hacimleri zaman zaman enstrümandan enstrümana farklılık gösterir.
Yedelkin 2011.08.25 08:16 #
"... ondan önce her şey doğru yapıldı" - bu gönül rahatlığı kategorisinden.
---
Günaydın! ))
Bu cümleye ek olarak, metinden ayrı olarak şunu da yazdım: "... Bir yerde yanıldığımı asla göz ardı etmem ve her zaman her şeyi kontrol ederim. Ama en sıkı kontrollerden sonra bile, her şey ilk bakışta doğru göründüğünde. , Ben hala bir yerlerde bir hata olabileceğini göz ardı etmiyorum . Her zaman her konuda haklı olduğunu düşünen insanlardan olmadığımı da ekleyeceğim. )))
---
Yedelkin:
Başlangıçta yanlıştı. Görünüşe göre, "olay kuyruğunun taşması" gibi bir olguya önem vermiyorsunuz. Özellikle olayları kenelerle aktarırken. Bu konudaki yardım materyallerine ve foruma bakın. Anahtar kelime "sıra" dır.
---
Zamanlayıcı konusuna baktım. Vurgulanan kilit noktalar şunlardır:
1. Bir olay işlenirken diğerleri işlenemez.
2. Olay yığını taşarsa, eski olaylar işlenmeden kuyruktan kaldırılır.
Sırayla gidelim. Olayların bir listesi var:
Başlatma sırasında, olayı hangi karakterden alacağımızı ve hangi olayı alacağımızı belirtiriz:
Yani CHARTEVENT_TICK olayını sadece EURUSD sembolünden kabul edeceğiz. Başka karakter yok.
Test başladı. Bir olay meydana geldiğinde, program OnChartEvent () işlevine girer, ticaret sinyalleri için değişken dizileri bildirir ve olayın ne olduğunu kontrol eder. Bu özel bir olay ise, program TradeSignalCounter ()'da bir sinyal tanımlar, ardından TradePerformer () fonksiyonunda yeni bir çubuğun gelip gelmediğini kontrol eder ve buna bağlı olarak diğer koşullara karar verir. İşlev işini tamamladı ve ancak EURUSD grafiğinde bir olay meydana geldikten sonra başlayacak. Bu, bu durumda kene.
Yedelkin:
TradeSignalCounter () + TradePerformer () fonksiyonlarının sadece bir sinyal kaynağından gelen olayları işlemesi, olay kuyruğunun durumunu ve olası taşma durumunu değiştirmedi. Başka bir deyişle, " GBRUSD sembolündeki olayların işlenmesini yasaklamak", ilgili olayları olay kuyruğundan hiç kaldırmadı. Üçüncü kez soruna dikkat çekiyorum: "İlgi zaten olay kuyruğunun olası bir taşmasına işaret etti" :) Sadece "bir tık geç"ten bahsettiğimizi düşünüyorsanız, o zaman bu tür sonuçlar neye dayanıyor?
---
Bu işlevlerin yürütülmesi çok hızlıdır. Hiçbir etkinlik kuyruğunun taşacak zamanı olmayacak ve hiçbir önemli etkinliği kaçırmayacağız. Ve sıra taşarsa ve olaylar atlanırsa, neyi kaçıracağız? Tik, iki tik, üç? Peki ya ne? Bu, günlük barlarda ihmal edilebilir.
---
Yedelkin:
Sorun, orijinal sürümde, olay işleyicinin her iki sinyal kaynağından da olaylar alındığında işlevleri çağırması ve ardından bu işlevlerin "gereksiz" kaynaktan gelen sinyali filtrelemesidir. Ancak işlevler her (!) seferde çağrıldı.
---
Neden bu ikinci kaynağa tutunuyorsun.))) Artık ikinci bir kaynak yok. Bir - EURUSD var, ancak EA GBPUSD'den EURUSD grafiğine işlem yapıyor. Ve sonuçlar aynı şekilde yanlıştır. Kopyala. Yani, ikinci kaynak mevcutmuş gibi. )))
-----------
Testi kendiniz yapmak, test sonuçlarını göstermek ve doğru test sonuçlarını almak için ne yaptığınızı (kısaca) yazmak, tabii ki yapabilirseniz daha iyidir. En basit Expert Advisor bu test için uygundur. Herhangi bir koşulla giriş, Zarar Durdur, Kar Al. Son 10 yıldır günlük barlar olsun. Ve kendin kendin göreceksin. Bazı parçalar eşleşecek ve bazıları olmayacak. Sonuç grafiğini açın ve tutarsızlığın nerede olduğunu görün.
Çubukları çevrimiçi olarak senkronize etmek nasıl gerekli değildir?!
Çünkü ondan önce yazdın:
pazarlamacı :
Çoklu para birimi modunda gerçek bir işlemden bahsediyorum (sembollerin her birinde ayarlanan EA'larda (her EA'da) N sembolleri üzerinde işlem yapmak) - bu gerçek bir tahmin verir ...
Bundan, gerçek başlatma ile birkaç Uzman Danışman başlatıldığında ve her biri doğrudan kendi sembolünde asılı kaldığında çevrimiçi bir testi kastettiğinizi anladım. Demek istediğin buysa, o zaman soru şu. Bu durumda, her bir Uzman Danışman kendi sembolüne asılıyorsa, neden çubukları senkronize etmeniz gerekiyor? Belki de ticaret sistemi aynı anda birkaç sembol üzerinde bir karar verilecek şekilde tasarlanmışsa, bu durumda çubukların senkronizasyonu gereklidir, bu nedenle bu birkaç sembol üzerindeki çubukların oluşturulması gerekir. Bir sembol üzerindeyken (herhangi bir sembol üzerinde) birden fazla sembol üzerinde bağımsız işlem yapmayı kastediyorum.
pazarlamacı :
Test cihazındaki tüm bu deneyler, çevrimiçi ticareti değerlendirmek için gereklidir ve bu konunun konusu, test cihazı (çevrimiçi öykünür) değil, çevrimiçi sorununa dayanmaktadır ve her şeyden önce, çubukların çevrimiçi olarak senkronize edilmesi gerekir (çünkü ilgili Uzman Danışmanlar).
Benim için, tarihteki ticaretin sonuçlarını değerlendirmek için test cihazındaki deneylere ihtiyaç var. Ve çevrimiçi ticaret için seçimim bu değerlendirmeye bağlı. Bu nedenle, bu konunun konusu çevrimiçi değil, test cihazının sorununa dayanmaktadır ve bu nedenle test cihazında (ilgili uzmanlar için) çubukların senkronizasyonuna ihtiyaç duyulmaktadır. Bir çeşit ayna görüntüsü.
pazarlamacı :
"Doğruluk" kategorisinin artık test cihazı çalıştırma kimliği ile değiştirildiğini belirtmeye çalışıyorum, ancak bu, bu tür verilerin daha az çarpık olduğu anlamına gelmiyor. Özellikle, 10 saniyelik bir aralık seçtiniz, bu da kuşkusuz verileri örneğin 5 veya 1 saniyelik aralıklarla olduğundan daha fazla bozuyor. Onlar. 10 saniyelik bir zamanlayıcı ile size tercih edilen yöntemi sağlayan test ortamındaki bir özellikten yararlanıyorsunuz.
Evet, aralık ne kadar küçükse sonuç o kadar doğru olur. Ama aslında, en azından benim için son test için gerekli. Ve ön hazırlık için, Vladimir'e ( MetaDriver ), bir dakikalık aralığın yeterli olduğu konusunda hala katılıyorum.
pazarlamacı :
Aslında, zamanlayıcı olayları olan tüm enstrümanlara yeni çubukların tiklerinin geldiği anı "yakalamaya" çalışıyorsunuz ve bunu yapmanın en iyi yolunun OnTick olayı olduğu oldukça açık.
Ve burada konunun ilk gönderisini dikkatsizce okuduğunuzu görebilirsiniz. Zamanlayıcı olayları değil, OnChartEvent (). Yoksa bir yazım hatası mı?
Bundan, gerçek başlatma ile birkaç Uzman Danışman başlatıldığında ve her biri doğrudan kendi sembolünde asılı kaldığında çevrimiçi bir testi kastettiğinizi anladım. Demek istediğin buysa, o zaman soru şu. Bu durumda, her bir Uzman Danışman kendi sembolüne asılıyorsa, neden çubukları senkronize etmeniz gerekiyor? Belki de ticaret sistemi aynı anda birkaç sembol üzerinde bir karar verilecek şekilde tasarlanmışsa, bu durumda çubukların senkronizasyonu gereklidir, bu nedenle bu birkaç sembol üzerindeki çubukların oluşturulması gerekir.
Aşağı yukarı böyle.
Ve burada konunun ilk gönderisini dikkatsizce okuduğunuzu görebilirsiniz. Zamanlayıcı olayları değil, OnChartEvent (). Yoksa bir yazım hatası mı?
Nedenmiş? Size orada OnTimer üçüncü numara. Bu konuda zaten alıntı yaptınız: Sadece doğru bir şekilde test edecek bir yöntem uygulamanız gerekiyor. O öyle. Bu, minimum aralıklı OnTimer () işlevidir. Yani başka bir şey düşünüyor olmalısın.
Bir - EURUSD var, ancak EA GBPUSD'den EURUSD grafiğine işlem yapıyor. Ve sonuçlar aynı şekilde yanlıştır.
Bu sizin için önemliyse, geliştiricilere ilk beşte dörtlü bir fxt dosyasının analogunun ne olduğunu kontrol etmenizi tavsiye ederim. Farklı testler için büyük olasılıkla farklı kene tabanlarının oluşturulduğunu zaten yazdım.