
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
Yani, yalnızca iCustom değişiklikleri olan bu satır mı? O zaman bu göstergeyi ayrıntılı olarak ele almak gerekir.
Temanız yanlış. Optimizasyona odaklanıyorsunuz ve konu, açıkçası danışmanda ( parametreleri geçmek , vb.). Bir süre optimizasyonu unutun, yorum ve baskı danışmanına bağlı kalın, görselde farklı parametrelerle sürün, ara verileri kontrol edin, tüm hataları bulun ve ardından optimizasyona dönün.
Aynı sonuçlar, optimize edilmiş parametrelerin bir ticaret sinyali oluşumunu etkilemediğini ve bunun test edenin değil Uzman Danışmanın sorunu olduğunu göstermektedir.
Parametreleri şöyle ayarlarsam: (iCustom(NULL, 0, "ART", MA_Period, KFK, 0, 1), Digits); - o zaman yukarıda örnek verdiğim gibi tüm sıfırlar elde edilir.
iCustom(NULL, 0, "ART", 0, 1), Digits); - daha sonra hesaplanan değerler görünür,
ancak hepsi aynıdır, ancak test cihazında farklı parametrelerle çalışırken, işlemlerin sonuçları çok farklıdır.
Angela, optimizasyonun çalışması için, optimizer tarafından algoritmada değiştirilen değerleri bir şekilde kullanmanız, özellikle göstergeye geçirmeniz gerekiyor. Optimizasyon istiyorsanız gösterge parametreleri geçirilmelidir. Göstergeyi parametresiz olarak çağırdığınızda (yani ikinci seçenek, iCustom(NULL, 0, "ART", 0, 1)), aslında parametreleri atlarsınız ve gösterge ART içinde yazılan varsayılan parametrelerle çalışır (elbette , optimize edilmediklerinde). Parametrelerle tam çağrı - ilk seçenek, optimizasyon için ihtiyacınız olan şeydir. Büyük olasılıkla, sorun parametreleri yanlış geçirmenizdir. Örneğin, göstergedeki sayıları daha azsa ve fazladan bir değer iletirseniz veya tam tersi, tüm parametreleri eklemezseniz. Gösterge bir sır ise, en azından parametrelerinin bir listesini verin.
Herkese teşekkürler, anladım, sebebi çok basit, göstergeden Uzman Danışmana iletilen parametrelerin beyan sırası eşleşmedi:
danışman vardı
harici int MA_Period=151; // 101 10 201
dış çift KFK=0.9; // 0.7 0,005 1.
göstergede tam tersi
dış çift KFK=0.9; // 0.7 0,005 1.
harici int MA_Period=151; // 101 10 201
bu nedenle, oluşturma modunda her şey çalıştı, ancak optimizasyon modunda çalışmadı.
Tebrikler. Titizliğe alışana kadar geçiş parametreleriyle de uğraştığımı hatırlıyorum. Şimdi, tüm extern'lerle birlikte gösterge kodunun bir parçasını Expert Advisor'a kopyalayıp yapıştırıyorum ve örneğe bakarak iCustom yazıyorum . Aptal, ama o zamandan beri hata yok.
Ve ilerisi. Komposter'ın görsel iCustom yazı stilini gözetledim. Her şey avucunuzun içinde.
TS'nin ikinci versiyonunda hata ayıklıyorum, birincisine kıyasla, işlem sayısı arttı, optimize edilmiş parametre sayısı, düşüş iki katına çıkmasına rağmen önemli ölçüde azaldı.
Ancak belirsiz şüpheler içimi kemiriyor, sistem optimize edilene, optimizasyon başlatılana kadar sistem aydan aya çok kararlı davranmıyor, ancak GA kullanarak sonuç sadece iki gün içinde olacak. iyimserliğe ilham vermeyin, Haziran için geçmişe ilişkin optimizasyon sonuçları, aynı dönemde ilk parametrelerle test edildiğinden daha kötü. Haziran, Temmuz ve Ağustos için üç durum veriyorum, sadece Buy'da hata ayıklarken, böyle bir sistemi istikrarlı sonuçlar için optimizasyon yoluyla çıkarmak mümkün mü yoksa hemen yeni bir tane geliştirmeye başlamalı mıyım?
EA'da yalnızca mql kodu varsa, o zaman görünüşe göre orada bir şey kodlanmamıştır, çünkü açılış fiyatlarına dayalı bir modelle 800 çalıştırma çok fazla yavaşlamamalıdır. Yoksa bir şeyi yanlış mı anlıyorum. Sinir ağı kütüphaneleri vb. gibi harici bağlamalara sahip uzmanlar genellikle çok düşüncelidir.Elbette, birçok iç içe döngünün (veya bazı "obur" göstergelerin çağrılarının) mql'de yazıldığını da varsayabiliriz - o zaman tamamen yavaşlatılabilir. . Bu bağlamda, yalnızca yeniden düzenleme ihtiyacı olduğu fikrini tekrarlayabilirim ;-) - kod parçalarını veya tüm kodu yeniden kontrol etme ve yeniden yazma.
8000'den fazla çalıştırmadan 800'ü, 5 saatlik optimizasyon ile gönderiyi yazarken geçti ve hala 2 gün kaldı. Ancak sonunu beklemedim, bazı parametrelerin numaralandırma aralığını azalttım, yeniden başlattım ve 8 saat içinde tüm optimizasyon tamamlandı.
En iyi sonuç:
Kârlı işlemlerin sayısı, kârsız işlemlerin sayısını aşıyor, ortalama kârlı işlem, kaybedenden daha fazla - çok iyi bir işaret. Bence bu sistem terk edilmemeli, davranışını daha uzun bir süre boyunca düzgün bir şekilde incelemek gerekiyor. Başka bir haç üzerine de koyabilirsiniz.