Hatalar, hatalar, sorular - sayfa 2160
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
MQ açısından, görünüşe göre, doğru. Her zaman olduğu gibi, daha uygun olduğu için bizim için karar verdik.
Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum
Profil mesajları kayboldu.
Renat Fatkhullin , 2018.03.08 10:31
Uyumluluk modunda çalışan işlevsellik miktarını azaltmak için geçici olarak kaldırıldı.
Transfer işlemini bitirir bitirmez yeni özellikler ekleyeceğiz.
Bu yeni, çok büyük ve çok işlevli bir sistemdir.
Yeni sohbetler tanıtılıyor.
MQ açısından, görünüşe göre, doğru. Her zaman olduğu gibi, daha uygun olduğu için bizim için karar verdik.
Telepatik seviyeye geçelim ...)))))
Ana göstergede anlaşılmaz bir hata. Yalnızca H 1'in altındaki zaman dilimlerinde ve yalnızca terminalin başlatıldığı anda gerçekleşir . Metin hatalar "S-v5 (EURUSD,M10) dizisi 'S-v5.mq5' (211.54) içinde aralık dışında". Zaman serisi bayrağı tüm arabellekler için ayarlanmış olsa da, oluşturma doğru şekilde ancak ters sırada gerçekleşir.
Şablonun bileşimi ana göstergedir (No. 1) (bir hatanın meydana geldiği), ek bir göstergedir (No. 2) (ana göstergenin birkaç tutamağını farklı parametrelerle birleştirir (görüntüleme süresi)), bir göstergedir ( 1) numaralı göstergeden gelen sinyallere göre ana çizelgede okları görüntüleyen No. 3), 2 numaralı göstergeden gelen sinyallere göre ana çizelgede okları görüntüleyen gösterge (No. 4).
Zaman çerçevesini değiştirmek, şablonu yeniden uygulamak, 2'den 4'e veya yalnızca 1'in altındaki 2 göstergeyi kaldırırsanız, Piyasa İzleme'den yeni bir sembol görüntüler ve bu şablonu uygularsanız - hata yeniden oluşmaz ve tüm göstergeler doğru çizilir .
Derlerken hata
Hata mesajı, neden kapsamlı kodda olduğunu netleştirmiyor
aşağıda açık
Hata mesajı yok
üstelik yürütülür ve hatta sonuç (!)
Bu varyantta:
hata satırına geçiş çalışmıyor (Enter ile)
Derlerken hata
İşi hızlandırmak amacıyla, bu örneği oluşturduğumda, yanlışlıkla rafa koyduğum bir tuhaflıkla karşılaştım.
Ve şimdi, bu tuhaflıkla başa çıkmaya çalıştığımda kafam daha da karıştı.
Bu yüzden hesaplamada, bir çift dizi oluşturarak atlamaya karar verdiğim sqrt() karekök işlevini kullanıyorum.
Çünkü Her zaman tam sayıların karekökünü alırım, ardından bir dizi oluşturmak şöyle görünür:
SQRT[x] dizisinden okumanın sqrt(x) işlevinden daha hızlı olduğunu varsaymak mantıklıdır.
Ve bu, doğrulama koduyla onaylanır:
sonuç, hızda ~ 1,5 kat bir artış olduğunu gösterir:
Ancak koddaki sqrt() işlevini SQRT[] dizisinin öğelerini okuyarak değiştirdiğimde, işi hızlandırmak yerine korkunç frenler alıyorum.
SQRT[] dizisinden bir öğeyi okumak birçok kez, hatta sqrt() işlevinin yürütülmesinden bir büyüklük sırası daha uzun sürer.
Ve hız sızıntısının nerede olduğunu anlamıyorum. Sonuçta, yukarıdaki doğrulama kodu aksini söylüyor.
Derleyicinin garip bir şekilde büyük bir diziye eriştiği ve döngünün her yinelemesinde diziyi "unuttuğu" ve her seferinde bir tür hizmet indekslemesi gerçekleştirdiği varsayılabilir.
Ancak bu, dahili bir mantıksal veya stratejik derleyici hatasıdır. Ayrıca, bununla açıkça bir şeyler yapılmalı, tk. bu hız sızıntısı çok önemlidir ve tespit edilmesi zordur. belli değil.
Bu tuhaflığı göstermek için komut dosyası kodunu ekliyorum.
Varsayılan olarak çalıştırıldığında (dizi=yanlış), sqrt() işlevleri değerlendirilir ve dizi doğru olarak değiştirildiğinde, diziden karekök değeri alınır.
SORUN NEDİR? FRENLER NEREDEN?
İşi hızlandırmak amacıyla, bu örneği oluşturduğumda, yanlışlıkla rafa koyduğum bir tuhaflıkla karşılaştım.
SQRT[x] dizisinden okumanın sqrt(x) işlevinden daha hızlı olduğunu varsaymak mantıklıdır .
Dinamik bir diziden bir gerçek değildir.
Ayrıca, kökü almak uzun zamandır SQRTSD işlemci komutu düzeyinde olmuştur. Yani, dinamik bir dizideki kötü şöhretli erişim maliyetlerinin yardımıyla, işlemci uygulamasını yenmek artık mümkün olmayacak.
Ve bu, doğrulama koduyla onaylanır :
sonuç, hızda ~ 1,5 kat bir artış olduğunu gösterir:
Onaylandığından şüpheliyim.
Bu tür bir kod, döngü optimizasyonu üzerine bir ders kitabından çıktı. Durum çok basit olduğu için kod iyileştirici bundan bir şeyler çıkarabilir:
Yani, açıkça ideal olarak optimize edilmiş durumların kullanılması durumunda performans ölçümü, testin hedefleriyle açık bir şekilde ilişkilendirilmelidir.
Bu durumda test yanlıştır.
Ve hız sızıntısının nerede olduğunu anlamıyorum. Sonuçta, yukarıdaki doğrulama kodu aksini söylüyor.
Son montajcı kodunu görmeden, şuna doğru eğiliyorum:
Kodu dikkatlice kontrol edelim. Gerçek sebebin ne olduğunu öğrenmek ilginç.
Dinamik bir diziden bir gerçek değildir.
Son montajcı kodunu görmeden, şuna doğru eğiliyorum:
Statik bir dizi denedim - aynı şey.
sqrt kadar hızlı, bu işlevin bir dizi öğesini okumaktan 10 kat daha hızlı olabileceğine inanmakta zorlanıyorum.
Ayrıca, örneğimde tuvalin boyutu küçültülmüşse, diyelim ki 50x50 (bunun için Size bir giriş parametresi var, 0 yerine 50 ayarlamanız gerekiyor),
ve dizi çok daha küçük (5000 eleman) olacak, ardından hız resmi belirgin şekilde değişecektir. Artık böyle güçlü bir kontrast yok.
Ama anlamıyorum, öğelerine erişim hızı dizinin boyutuna mı bağlı?
Ve doğrulama kodunun basitliği hakkında belki de haklısınız.
Biraz karmaşıklaştırmaya çalıştım ve sonuç tamamen farklı: