Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret 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
Uyumluluk için sıfırlamanın yapıldığı açıktır, ancak kullanılmayan enum = WRONG_VALUE doğru başlatıldığında neden doğru çalışmadığı açık değildir. Bu yaklaşımla taşınabilirlik yoktur ve gizli hataların olasılığı önemli ölçüde artar.
Bu kuralı hatırlıyor musun?
Kural : adlandırılmış bir sabit - numaralandırmanın bir üyesine açıkça belirli bir değer atanmamışsa, değeri otomatik olarak oluşturulur. Numaralandırmanın ilk üyesi ise 0 değeri atanır.Sonraki tüm üyeler için değer bir önceki üyenin değerine göre bir eklenerek hesaplanır.
Büyük olasılıkla, istek alanlarının doldurulmasının doğruluğunu kontrol etmek, bir numaralandırma üyesinin değerinin negatif olamayacağı gerçeğinden kaynaklanmaktadır. Bu durumda, numaralandırmanın bir üyesine WRONG_VALUE değerinin atanma olasılığı dikkate alınmaz.
Bu durumda, numaralandırmanın bir üyesine WRONG_VALUE değerinin atanma olasılığı dikkate alınmaz.
Hatanın tam olarak bu olduğunu düşünüyorum. Belirli bir numaralandırma kullanılmazsa - değerinin WRONG_VALUE olması mantıklıdır ve örneğin aslında = 0 olan ORDER_TYPE_BUY değil
ve en önemlisi, uyumluluğu korurken OrderCheck() ve OrderSend() mantığını değiştirmenizi hiçbir şey engelleyemez
ve en önemlisi, uyumluluğu korurken OrderCheck() ve OrderSend() mantığını değiştirmenizi hiçbir şey engelleyemez
Garip bir hata buldum.
Bu kodu danışmanlarımda kullanıyorum:
Test cihazında tek bir çalıştırma sorunsuz çalışır, ancak parametre seçimini tam numaralandırmaya ayarladığımda test cihazı on ila on kat daha yavaş çalışmaya başlar. Tek seferde hızın neden yeterli olduğunu ve optimizasyonla hızın neden belirgin şekilde düştüğünü anlayamıyorum. Ve katlanarak düşüyor. Yüzde, ilk başta her şeyin olması gerektiği gibi gittiğini, ancak finale yaklaştıkça hızın giderek düştüğünü gösteriyor. Kodumda döngü veya başka bir sorun aradım ama bulamadım. Ondan sonra yukarıdaki kodu kendi algoritmamla değiştirdim ve bak işte! Optimizasyon artık normal sabit hızda çalışıyor. Buradan sorunun MQL5'in içinde, OnTradeTransaction işlevinin gövdesinde bir yerde olduğu sonucuna varıyorum. Geliştiricilerin buna dikkat etmelerini rica ediyorum.
ps Uzmanın kodunu yaymak mümkün değildir. benim için değeri var. Uzman Danışmanlarınızdan herhangi birinde yukarıda belirtilen kodu kullanmayı deneyin ve 2000'den günümüze kadar olan dönem için OHLC M5 için optimizasyon hızına bakın.
Garip bir hata buldum.
Bu kodu danışmanlarımda kullanıyorum:
Test cihazında tek bir çalıştırma sorunsuz çalışır, ancak parametre seçimini tam numaralandırmaya ayarladığımda test cihazı on ila on kat daha yavaş çalışmaya başlar. Tek seferde hızın neden yeterli olduğunu ve optimizasyonla hızın neden belirgin şekilde düştüğünü anlayamıyorum. Ve katlanarak düşüyor. Yüzde, ilk başta her şeyin olması gerektiği gibi gittiğini, ancak finale yaklaştıkça hızın giderek düştüğünü gösteriyor. Kodumda döngü veya başka bir sorun aradım ama bulamadım. Ondan sonra yukarıdaki kodu kendi algoritmamla değiştirdim ve bak işte! Optimizasyon artık normal sabit hızda çalışıyor. Buradan sorunun MQL5'in içinde, OnTradeTransaction işlevinin gövdesinde bir yerde olduğu sonucuna varıyorum. Geliştiricilerin buna dikkat etmelerini rica ediyorum.
ps Uzmanın kodunu yaymak mümkün değildir. benim için değeri var. Uzman Danışmanlarınızdan herhangi birinde yukarıda belirtilen kodu kullanmayı deneyin ve 2000'den günümüze kadar olan dönem için OHLC M5 için optimizasyon hızına bakın.
Farklı parametrelerle, uzman farklı zamanlar için çalışabilir
Yukarıdaki kodu kendi algoritmamla değiştirdikten sonra
Onlar. OnTradeTransaction() kullanmayı reddettiniz mi? - o zaman hızın artması mantıklı - her fırsatta çağrılıyor
Ve minimum bir test senaryosu oluşturmanızı ve hizmet masasına aboneliğinizi iptal etmenizi engelleyen nedir?