Strateji Test Cihazında Optimizasyon - sayfa 10
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
En son sürümlerde, görev başlangıcında sistem ek yüklerinden tamamen kurtulduk ve bunları neredeyse 2000 ms'den sıfıra indirdik.
İşte joo'nun önerdiği hesaplama görevini çalıştırmanın sonuçları:
Ayarlar (tarihler, grafik geçmişi kullanılmayacak şekilde özel olarak ayarlanır):
Yinelenen parametreler:
Kullanılan ajanlar (4 yerel ajan):
Optimizasyon sonuçları:
Optimizasyon sadece 25 saniye sürdü, 18.432 geçiş yapıldı:
Alt satır: MetaTrader 5 ve aracılar ağı, büyük matematiksel hesaplamalar için kullanılabilir.
En son sürümlerde, görev başlangıcında sistem ek yüklerinden tamamen kurtulduk ve bunları neredeyse 2000 ms'den sıfıra indirdik.
İşte joo'nun önerdiği hesaplama görevini çalıştırmanın sonuçları:
Ayarlar (tarihler, grafik geçmişi kullanılmayacak şekilde özel olarak ayarlanır):
Yinelenen parametreler:
Kullanılan ajanlar (4 yerel ajan):
Optimizasyon sonuçları:
Optimizasyon sadece 25 saniye sürdü, 18.432 geçiş yapıldı:
Alt satır: MetaTrader 5 ve aracılar ağı, büyük matematiksel hesaplamalar için kullanılabilir.
Bu çok iyi bir sonuç. Şimdi, gerçekten de, optimize edici, optimizasyon problemlerini çözmek için aşağı yukarı uygundur (hem ticaret hem de doğrudan ticaretle ilgili değildir). Optimize edicinin varsayılan GA ayarlarıyla özellikle bu görev için geçiş sayısı 2-3 bine düşerse sonuçlar daha da iyi olacaktır, ancak bunun için kullanıcı erişimi için GA ayarlarını görüntülemeniz gerekir (eğer mümkünse kullanıcı, geçiş sayısını 500-900'e düşürmek istiyor).
Arama uzayındaki sınırlamayla ilgili bir sorun devam etmektedir. Optimize edici için ilgili teklif hizmet masasında yayınlandı.
Bu çok iyi bir sonuç. Şimdi, gerçekten de, optimize edici, optimizasyon problemlerini çözmek için aşağı yukarı uygundur (hem ticaret hem de doğrudan ticaretle ilgili değildir). Optimize edicinin varsayılan GA ayarlarıyla özellikle bu görev için geçiş sayısı 2-3 bine düşerse sonuçlar daha da iyi olacaktır, ancak bunun için kullanıcı erişimi için GA ayarlarını görüntülemeniz gerekir (eğer mümkünse kullanıcı, geçiş sayısını 500-900'e düşürmek istiyor).
Arama uzayındaki sınırlamayla ilgili bir sorun devam etmektedir . Optimize edici için ilgili teklif hizmet masasında yayınlandı.
Ve bu sorunun çözümü öncelikle bu sorunla ilgilidir:
optimizasyon geçişlerinin taşması zaten 4 parametrede meydana geliyorsa, o zaman parametre sayısını izin verilenden daha fazla artırmaktan (64) bahsetmek henüz uygun değildir.
Ve bu sorunun çözümü öncelikle bu sorunla ilgilidir:
optimizasyon geçişlerinin taşması zaten 4 parametrede meydana geliyorsa, o zaman parametre sayısını izin verilenden daha fazla artırmaktan (64) bahsetmek henüz uygun değildir.
Elbette. Kabaca, arama alanı P=n*adımdır, burada n, optimize edilecek parametre sayısıdır ve adım, parametrenin adımıdır. Bu durumda, P alanı, Pmax alanından daha az olmalıdır (kromozomun ikili kodlamasının özellikleri ile sınırlı, mümkün olan maksimum arama alanı). Bu nedenle, yapay olarak getirilen kısıtlamalardan biri (sonuçta, örneğin, 10.000 parametre üzerinde bir kısıtlama yapmak mümkündür, ancak daha sonra adım, çoğu optimizasyon problemini çözmek için gerekenden daha büyük olacaktır), böylece P, Pmax'ı aşmaz. , n ile ilgili bir kısıtlama getirildi.
Bu konudaki düşünceler, hizmet masasındaki optimize edici teklifinde dile getirilmiştir.
PS Uzak aracı ağlarının büyümesiyle birlikte, çok sayıda çalıştırmayla ilgili sorun boşa çıkıyor. Ancak, elbette, yalnızca kromozomların ikili kodlamasındaki kısıtlamalar kaldırılırsa (okuduk - kromozomu gerçek sayılarla kodlamaya geçiş).
Elbette. Kabaca, arama alanı P=n*adım'dır , burada n, optimize edilecek parametre sayısıdır ve adım, parametrenin adımıdır. Bu durumda, P alanı, Pmax alanından daha az olmalıdır (kromozomun ikili kodlamasının özellikleri ile sınırlı, mümkün olan maksimum arama alanı). Bu nedenle, yapay olarak getirilen kısıtlamalardan biri (sonuçta, örneğin, 10.000 parametre üzerinde bir kısıtlama yapmak mümkündür, ancak daha sonra adım, çoğu optimizasyon problemini çözmek için gerekenden daha büyük olacaktır), böylece P, Pmax'ı aşmaz. , n ile ilgili bir kısıtlama getirildi.
Bu konudaki düşünceler, hizmet masasındaki optimize edici teklifinde dile getirilmiştir.
PS Uzak aracı ağlarının büyümesiyle birlikte, çok sayıda çalıştırmayla ilgili sorun boşa çıkıyor. Ancak, elbette, yalnızca kromozomların ikili kodlamasındaki kısıtlamalar kaldırılırsa (okuduk - kromozomu gerçek sayılarla kodlamaya geçiş).
Biraz yanlış, doğru seçenek sayısı şu şekilde değerlendiriliyor: P=step_0* step_1*...* step_n
adım boyutu eşitse, P=adım^n ile sonuçlanır
Biraz yanlış, doğru seçenek sayısı şu şekilde değerlendiriliyor: P=step_0* step_1*...* step_n
adım boyutu eşitse, P=adım^n ile sonuçlanır
En son sürümlerde, görev başlangıcında sistem ek yüklerinden tamamen kurtulduk ve bunları neredeyse 2000 ms'den sıfıra indirdik.
Fantezi! Ah, yaz aylarında optimizasyon için boşuna ne kadar zaman harcandı ...
Sırayla. Testi joo'dan mevcut yapı ve 319. yapı üzerinde çalıştırdım (02 Eylül 2010). Sonuçlar:
2010.12.29 15:49:18 Test cihazı genetik optimizasyonu 15360 (100000020000001) geçişinde tamamlandı
2010.12.29 15:49:18 Test cihazı sonuç önbelleği 7265 kez kullanıldı
2010.12.29 15:49:13 Tester genetiği bitti
2010.12.29 17:10:59 Test cihazı genetik optimizasyonu 18176 (100000020000001) geçişinde tamamlandı
2010.12.29 17:10:59 Test cihazı sonuç önbelleği 10582 kez kullanıldı
2010.12.29 17:10:52 Tester genetiği bitti
Tebrik mi edeceğim, teşekkür mü edeceğimi bile bilmiyorum. Teşekkür ederim!
Ve bu sorunun çözümü öncelikle bu sorunla ilgilidir:
optimizasyon geçişlerinin taşması zaten 4 parametrede meydana geliyorsa, o zaman parametre sayısını izin verilenden daha fazla artırmaktan (64) bahsetmek henüz uygun değildir.
Aramak için makul bir yaklaşım kullanın, ancak "Rus adamları Japon testeresini kırar" modunda tutamaçları maksimuma döndürmeyin.
Genetik optimizasyonu gerçek işte uygulamaya başlar başlamaz, hemen makul limitleri seçmeye başlayacaksınız.
Fantezi! Ah, yaz aylarında optimizasyon için boşuna ne kadar zaman harcandı ...
Sırayla. Testi joo'dan mevcut yapı ve 319. yapı üzerinde çalıştırdım (02 Eylül 2010). Sonuçlar:
2010.12.29 15:49:18 Test cihazı genetik optimizasyonu 15360 (100000020000001) geçişinde tamamlandı
2010.12.29 15:49:18 Test cihazı sonuç önbelleği 7265 kez kullanıldı
2010.12.29 15:49:13 Tester genetiği bitti
2010.12.29 17:10:59 Test cihazı genetik optimizasyonu 18176 (100000020000001) geçişinde tamamlandı
2010.12.29 17:10:59 Test cihazı sonuç önbelleği 10582 kez kullanıldı
2010.12.29 17:10:52 Tester genetiği bitti
Tebrik mi edeceğim, teşekkür mü edeceğimi bile bilmiyorum. Teşekkür ederim!
Her başlatmada 1.5-2 saniyelik bir tasarruf sağlayan "terminalden temsilciye ilk verilerin senkronizasyonu/aktarı ve temsilciden sonuçların alınması" aşamalarında sistem yükünü azalttığımızı lütfen unutmayın. Dildeki hesaplamaların hızlandırılması olmadı.
Yani, hesaplamanın sıfıra yakın zaman aldığı hızlı ateşleme yanlış hesaplamalarında en ciddi etkiyi verir. Büyük bilgi işlem için tasarruflar çok belirgin değildir. 10.000 başlatma başına 2 saniye tasarruf etmek 20.000 saniye = 333 dakika = 5.5 saat verir.
Etkilemez.
Ve öyle olduğunu fark ettim. EA'yı hafta içi günlerde çalıştırdım ve şimdi genişletilmiş bir yayılma ile çalıştırdım, sonuç oldukça farklı, euroback'teki yayılma şimdi yaklaşık 4 puan (dört haneli). Bu, hafta sonu yayılmanın "yapışmasının" MT5'te de ortadan kalktığı anlamına geliyor. Bu nedenle, optimizasyon doğru olmayacağından hafta sonları optimize etmeye değmez. MT4'te bile görsel olarak görüyorum EA o Pazartesi'den beri optimizasyonda, sonuç eğrisi hafta sonundan beri düştü, bu yayılmanın optimizasyon sonuçlarını etkilediğini gösteriyor, daha da kötüleştiler.