Mql5 dilinin özellikleri, incelikleri ve çalışma yöntemleri - sayfa 235

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
Çalışmayı durdurursa, doğru olup olmadığını bilmek iyi olur.
Nesneler yerine işaretçiler yaparsanız, eski sürüm de çalışacaktır.
Çalışmayı durdurduysa, yapılacak doğru şeyin bu olup olmadığını bilmek iyidir.
Nesneler yerine işaretçiler yaparsanız, eski sürüm de çalışacaktır.
Harika bir nokta ve ipucu için teşekkürler!
Evet, gerçekten de durum bir işaretçi ile mükemmel bir şekilde çözülür:
Hızlı algoritma hayranları. Nanosaniyeler için savaşanlar :)
Görev: Çubuğun şu anda var olduğu bilindiğinde, verilen zamana ve TF'ye göre çubuk açılış zaman ını bulun. Örneğin, açılış ve kapanış pozisyonlarının zamanına göre.
Çoğu programcı iTime ve iBarShift'in bir kombinasyonunu kullanacaktır. Bu en yavaş uygulama olacaktır, özellikle böyle bir uygulama yüklenen verilerin veya taranmış dizilerin güncel bir geçmişini gerektirir. Ayrıca, gerekli geçmiş eksikse bu yaklaşım hata üretebilir.
Daha ileri düzey programcılar bu sorunu MqlDateTime yapısı ve TimeToStruct() fonksiyonu ile çözecektir. Bu kötü bir çözüm değildir ve yeterince hızlıdır.
Ancak, önceki çözümden birkaç kat daha üretken olan üçüncü bir çözüm daha vardır:
Bu algoritmadaki ana zorluk ayın başlangıç zamanını hesaplamaktır (yeşil ile vurgulanmıştır) Lütfen algoritmanın işleyişini anlamaya çalışmayın. Burada basitten karmaşığa gitmenin sonucu olan bir sihir var. Karmaşık olandan basit olana giden ters yolu geçmek çok daha zor olacaktır.
Performans kazancı, sarı renkle vurgulanan standart PeriodSeconds() işlevi yerine TF'den bir çubuktaki saniyeleri alma algoritması tarafından da sağlanır.
Her üç yöntemin performansını hesaplayan ve karşılaştıran bir test komut dosyası ekliyorum:
iBarShift ile sağlama toplamı eşleşmeyecektir , çünkü iBarShift gerçek çubuklarla çalışır. Sağlama toplamı yalnızca MN1 ve W1 zaman dilimlerinde çakışacaktır, çünkü bu tür çubukların geçmişinde delik yoktur.
Algoritma önceki hesaplamaları kaydetmek için çalışmaya başladığında döngüde küçük bir zaman adımı (bir günden az) kullanırsanız performans daha yüksek olacaktır:
iBarShift aracılığıyla algoritma için aşırı değerler (mavi ile vurgulanmıştır), gerekli geçmişin veya dizi tarafından hesaplanan TF'lerin mevcut eksikliğinden kaynaklanır ve bu da bunların yüklenmesini başlatır.
Yüklemeden sonra sonuç aşağıdaki gibi olacaktır:
Hızlı algoritma hayranları. Nanosaniyeler için savaşanlar :)
...😮😲😳🥴🤪
...
ah...
mmm....
oooh....
gkghm... Basit sorumun bu şekilde ortaya çıkacağını düşünmemiştim.
Aynen böyle.
😮😲😳🥴🤪
...
Ah...
Mmm.
ohhhh....
ahem. Basit sorumun bu şekilde sonuçlanacağını düşünmemiştim.
Oh.
Evet Artem, beni bir süre kandırdın.
Sportif bir ilgiydi.
Umarım ben dahil birilerinin işine yarar. :))
Evet Artem, beni bir süre kandırdın.
Sportif ilgi üzerine çalıştım.
Umarım birilerine, bu arada bana da faydalı olur. :))
Tabii ki olacak. Harika. Tekrar teşekkür ederim!
S.F. Bu beni eğlendirdi: "sadece 28.02.2100 tarihine kadar doğru sayılır !!!!".
Ondan sonra ne yapacağız?
Tabii ki işe yarayacak. Harika. Tekrar teşekkür ederim!
S.F. Bu beni eğlendirdi: "sadece 28.02.2100 tarihine kadar doğru sayılır !!!!".
Ondan sonra ne yapacağız?
haha.
Bu algoritmanın 75 yıl boyunca talep göreceğinden şüpheliyim. Kuantum bilgisayarlar muhtemelen tamamen farklı bir programlama ile dünyayı çoktan yönetecek.
Dürüst olmak gerekirse, Miladi takvimi hesaba katmak tembellikti. 2000 yüksek riskliydi, 2100 artık değil.
haha.
Bu algoritmanın 75 yıl boyunca talep göreceğinden şüpheliyim. Kuantum bilgisayarlar muhtemelen tamamen farklı bir programlama ile dünyayı çoktan yönetecek.
Dürüst olmak gerekirse, Gregoryen takvimini tamamen hesaba katmak tembellikti. 2000 yüksek riskliydi, 2100 artık değil.
MN için önceden hesaplanmış bir dizi kullanabilirsiniz, orada neredeyse hiçbir şey yoktur
Ln2(12 ay * yüz yıl)...11 if'ler ve ikili aramada karşılaştırmalar, ancak diğer hesaplamalar olmadan.
MN için önceden hesaplanmış bir dizi kullanabilirsiniz, orada neredeyse hiç veri yoktur.
Ln2(12 ay * yüz yıl)...11 if'ler ve ikili aramada karşılaştırmalar, ancak başka hesaplamalar olmadan.
MN için önceden hesaplanmış bir dizi kullanabilirsiniz, orada neredeyse hiç veri yoktur.
Ln2(12 ay * yüz yıl)...11 if'ler ve ikili aramada karşılaştırmalar, ancak diğer hesaplamalar olmadan.
Ah, ilk başta yanlış okumuşum.
Hayır, yanılıyorsunuz. Performans artışı işe yaramayacaktır. Hala hesaplamalarda takılıp kalacaksınız. Ve dizi elemanlarına erişim algoritmayı çok yavaşlatır.