Doğrusal yavaşlama - bir programcının hatası mı yoksa MT4'ün bir özelliği mi? - sayfa 4

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
Aşağıdaki yapı tek başına bir şeye değer.
saçını biraz tara
ve neyin, hangi sırayla yapıldığı netleşir. Sadece biçimlendirme. Ancak yine de kodu mantıksal olarak tutarlı işlemlere bölebilir ve bunları ayrı işlevlere ayırabilirsiniz. Böylece karışık kod yığınlarından ana algoritmayı kolaylaştırmak.
Sorun, aşırı derecede fazla sayıda koşullu ifadede kod çoğaltmasındadır. Aslında kod satırların %99'unu şu ya da bu şekilde koşullu işleci de içeriyor. yürütme, böyle bir kodun okunması zordur. Buna ekleyen kişinin en az 2 ana görevi vardır:
1-kırmayın
2 - istenen işlevselliği ekleyin
Okunamayan kod , öyle ya da böyle, her türlü kontrolün, karşılaştırmanın ek tekrarına yol açar - ve bu yine ek maliyetlerdir. Koda baktığımda, kendimi yaklaşık 25 yıl önce, programlamaya yeni başladığımda kişisel olarak hatırlıyorum ve bunu, sadece ilginç olduğu için, Atari 800XL PC'nin öğretmensiz talimatlarına göre öğrendim.
Tabii ki, ne tür bir "eğer"den bahsettiğimiz ilginç, görünüşe göre benim teknik özelliklerim var - "eğer öyleyse, öyleyse" yazdığım yer ve programcı bunu kodda bu şekilde yorumluyor ve orada bir "eğer" emirlerle doğrudan çalışma ile ilgili ve emirlerle yapılan birçok işlem var...
Tabii ki, konunun bir tür döngüde olduğunu düşündüm, bunun yürütülmesi TK koşullarının doğrulanmasının tekrar tekrar yürütülmesine yol açtı. Ancak durumu düzeltmenin tek yolunun kodu sıfırdan yeniden yazmak olduğu ortaya çıktı.
Aşağıdaki yapı tek başına bir şeye değer.
saçını biraz tara
ve neyin, hangi sırayla yapıldığı netleşir. Sadece biçimlendirme. Ancak yine de kodu mantıksal olarak tutarlı işlemlere bölebilir ve bunları ayrı işlevlere ayırabilirsiniz. Böylece karışık kod yığınlarından ana algoritmayı kolaylaştırmak.
Ve performansı herhangi bir şekilde etkiler mi?
Kod çoğaltma ile ilgili sorun
Aşağıdaki yapı tek başına bir şeye değer.
saçını biraz tara
ve neyin, hangi sırayla yapıldığı netleşir. Sadece biçimlendirme. Ancak yine de kodu mantıksal olarak tutarlı işlemlere bölebilir ve bunları ayrı işlevlere ayırabilirsiniz. Böylece karışık kod yığınlarından ana algoritmayı kolaylaştırmak.
devir 1.1
Zararı durdur ve bekleyen emirleri filtrelemek için ayna MA'yı kullanmak için iki seçenek kullanıyoruz.
maMirror - standart iMA işlevine göre hesaplanır, çubuk başına bir kez çalışır, veriler çubuk açılış fiyatları üzerinden alınır
Hesaplama algoritması:
Satılık:
hesaplamanın başlangıç noktası maMirror=iMA+pipsXHmaM(o/b)
sonraki hesaplama noktaları maMirror=maMirror(1)-(iMA(0)+pipsXHmaM(o/b)-iMA(1)+pipsXHmaM(o/b))
hesaplama, hesaplamanın bitiş noktasından sonra sona erer.
Satın almak için:
hesaplamanın başlangıç noktası maMirror=iMA-pipsXHmaL
sonraki hesaplama noktaları maMirror=maMirror(1)-(iMA(0)-pipsXLmaM-iMA(1)-pipsXLmaM)
hesaplama, hesaplamanın bitiş noktasından sonra sona erer.
Teknik görevi basitleştirmek için, çalışma ve değişkenler açısından bağımsız olacak ve kullanıcı tarafından yapılandırılacak iki hesaplama bloğu ayarlamak gerekir.
maMBlock=0 - blokları kullanmayın (standart durdurma kaybı kullanılır)
maMBlock=1 - yalnızca blok #1'i kullanın
maMBlock=2 - yalnızca blok #2'yi kullanın (standart durdurma kaybı kullanılır)
maMBlock=3 - her iki bloğu da kullanın
Blok 1
Kayıp hesaplamasını durdurun. Stoploss yeniden hesaplanır ve sipariş her çubukta maMirror değeri ile güncellenir.
1. Hesaplamanın başlangıç noktasını belirlemek için, BaşlangıçNoktası=1 ise (hesaplama maT'ye dokunduktan sonra gerçekleşir), BaşlangıçNoktası=2 ise (hesaplama sipariş açıldıktan sonra gerçekleşir) BaşlangıçNoktası değişkeni kullanılır.
1.1 StartPointO=1 ise, hesaplamanın sonu maT'ye dokunulduktan sonra gerçekleşir;
1.2.StartPointO=2 ise, sipariş kapatıldıktan sonra hesaplamanın sonu gelir;
1.3. MaMirror'da stop loss koymak mümkün değilse, sipariş kapatılır.
1.4. Levl_Zerro=0 (kullanılmaz), Levl_Zerro!=0 (zararı belirtilen maksimum değere yükseltiriz, geri sayım açık fiyattan başlar, eksi değer zararı durdurun pozitif değere dönüştürüldüğü anlamına gelir)
Blok #2
Bekleyen siparişleri filtrelemenin hesaplanması.
0.1 maMirror> bekleyen emir açılış fiyatları ise satın alma emirleri verilir.
0.2 Satış için siparişler, eğer maMirror< bekleyen bir sipariş açma fiyatı ise verilir
1. Hesaplamanın başlangıç noktasını belirlemek için, BaşlangıçNoktası=1 ise (hesaplama maT'ye dokunduktan sonra gerçekleşir), BaşlangıçNoktası=2 ise (hesaplama sipariş açıldıktan sonra gerçekleşir) BaşlangıçNoktası değişkeni kullanılır.
1.1 StartPointB=1 ise, hesaplamanın sonu maT'ye dokunulduktan sonra gerçekleşir;
1.2. StartPointB=2 ise, sipariş kapatıldıktan sonra hesaplamanın sonu gerçekleşir;
2. maMirrorDell=0 (kullanılmıyor) ise maMirrorDell=1 (0 noktasındaki koşullar eşleşmezse tüm açık emirler silinir)
Kullanıcı değişkenleri
maMirrorO (iMA ayarları)
maMirrorB (iMA tarafından yapılan ayarlar)
Başlangıç NoktasıO
Başlangıç NoktasıB
pipXHmaMo
pipsXLmaMo
pipXHmaMb
pipsXLmaMb
maMBlock
maMirrorDell
Görevin değerlendirilmesine yardımcı olun, müşteri yeni bir iş istiyor, ne kadar tahmin edeceğimi bilmiyorum) Programcı olmadığım için Havacılık ve Uzay Akademisi'nde mühendisim)
Ve performansı herhangi bir şekilde etkiler mi?
Çok güçlü argümanlarınız var, kodunuz, deneyimli bir programcıyı nerede görebilirim?
Çoğaltmanın ifa ile de ilgisi yoktur. Gerçek yavaşlama, siparişlerle çalışmaktan geliyor.
TK'ye göre koddaki siparişlerle mi çalışıyorsunuz, yoksa TK'nin kendisi mi yoksa MT4 genel olarak siparişlerle mi çalışıyor?