Göstergesiz Uzman Danışman Mümkün mü? - sayfa 3
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
Tehlikeli yanılsama.
Ancak dizim nadiren grafikteki çubukların sayısına eşittir. Bazen daha az, bazen daha fazla.
Daha büyük olabileceğinden endişeleniyorum.
Her şeyden önce, gösterge arabelleği ile aynı dahili bir veri dizisine sahip olmanızı ve onu aynı şekilde doldurmanızı engelleyen nedir.
Ve kaynak tasarrufu, göstergede sayma veya aynısını bir Uzman Danışmanda sayma açısından hangisi daha uygun, neyi daha hızlı denediniz?
Ancak dizim nadiren grafikteki çubukların sayısına eşittir. Bazen daha az, bazen daha fazla.
Daha büyük olabileceğinden endişeleniyorum.
Endişelenmene gerek yok Alexei.
Bunun gerekli olduğu durumlar olabilir gugilyon.
Örneğin.
Zaman çerçevesinden bağımsız olarak çoğunlukla dakika çubuğu veya kene verilerini kullanırım.
Uzman Danışmanınızın her zaman çerçevesi değişiminde tüm tampon göstergelerini yeniden hesaplaması çok yanlış ve israftır. Bu bana olmaz.
Bu nedenle, haftalık bir zaman dilimindeysem, dizim elbette grafikteki çubuk sayısından çok daha büyük olacaktır.
Genel olarak tiklerden bahsediyorum.
Kural olarak, performansı artırmak ve bellekten tasarruf etmek için birkaç yapı dizim ve dizin dizim var. Boyutları çok farklı olabilir.
Genel olarak, iCustom aracılığıyla göstergeleri kullandığınızda, birçok şeyde çok sınırlısınız.
Grafikteki çubuk sayısına eşit dizi boyutuna kesinlikle bağlısınız. Ve orada sınırsız varsa?
Yalnızca bir çift tipe bağlısınız. Bir dizi yapıyı hayal bile edemezsiniz.
Genel olarak renk göstergeleri ile kahkahalar. Çubuk başına 8 bayt çok fazla.
Gösterge arabellekleri, bellek tüketimi açısından çok savurgandır.
Ayrıca, yalnızca son bir çubuğa ihtiyacınız olsa bile, arabelleklere yalnızca CopyBuffer aracılığıyla erişebilirsiniz. Her durumda, bu işlem bir dizi öğesine basitçe erişmekten önemli ölçüde daha yavaştır.
Tabii ki, iMA gibi standart yerleşik göstergeler kullanırsanız, fazla uğraşamazsınız. Ama yine de, bunun özel göstergelerle ilgili olduğunu düşünüyorum. Profesyonellerin gerçek ticaret için yerleşik göstergeler kullandığından şüpheliyim.
Ve kaynak tasarrufu, göstergede sayma veya aynısını bir Uzman Danışmanda sayma açısından hangisi daha uygun, neyi daha hızlı denediniz?
Bir önceki gönderide kısmen cevaplandı.
Bu son derece hacimli bir sorudur ve geliştiricilere ve çoklu kullanımdan sorumlu olanlara sormak daha iyidir.
Ben bu konuda uzman değilim. Ama düşüncelerimi paylaşabilirim. Bir konuda yanılıyorsam, eminseniz lütfen beni düzeltin.
Bildiğiniz gibi, her Expert Advisor kendi ayrı iş parçacığında çalışır ve bir enstrümanın tüm göstergeleri (farklı grafiklerde bile) tek bir ortak iş parçacığında çalışır.
Bu nedenle, sembol göstergelerle aşırı yüklenmezse, Uzman Danışmanın çalışması ve gösterge arabelleğinin hesaplanması, şanslıysanız ve işletim sistemi zamanlayıcı bulursa paralel olarak ve hatta farklı işlemci çekirdeklerinde gerçekleşeceğini varsayabiliriz. gösterge akışınız için ayrı bir işlemci çekirdeği. Ve böyle bir şema ile sonucun daha verimli olması oldukça olasıdır. Gösterge akışı için ayrı bir çekirdek almanın ne kadar olası olduğunu bilmiyorum, ancak çok yüksek olmadığını düşünüyorum.
Ancak, iş parçacıklarının bağlam değiştirme hızı ve birkaç iş parçacığının etkileşiminin diğer birçok inceliği gibi kavramlar vardır. İş parçacıklarının işlemlere kıyasla bu geçiş hızının çok yüksek olduğunu biliyorum, ancak yine de ücretsiz değil.
Ayrıca, daha önce de söylediğim gibi, CopyBuffer aracılığıyla gösterge arabelleği öğesine erişim daha pahalıya mı mal olacak? dizinindeki bir dizi öğesine göre.
Ayrıca, gereksiz hesaplamaları optimize etme imkanı, dahili veri dizilerinin boyutu ve bunların Expert Advisor içinde indekslenmesi, kaynak maliyetlerini azaltmak için çok büyük bir potansiyel sağlar.
Elbette sorunuza tam olarak cevap verebilmek için deneylere ve doğru testlere ihtiyaç vardır. Ama yine de ortalama olarak daha üretken olduğunu düşünmeye meyilliyim - hepsi tek bir EA dizisinde.
Ve her seferinde bir döngüde mi çalışıyorsunuz? EMA ile daha da ilginç olacak.
Tek geçişli üstel ağırlıklı ortalama hesaplama algoritması kullanın
ana = (1 - a) * fiyat + bir * ana
Normal bir gösterge tüm çubukları yalnızca başlangıçta sayar ve ardından 1 çubuğu sayar. Göstergede SMA yapmak kolaydır, böylece 1. çubuğu hesaplarken bile tüm MA dönemi boyunca geçiş yapmanız gerekmez.
Elbette Expert Advisor'da bir diziden buffer yapmak da mümkün... Ama özel olarak tasarlanmış bir element - göstergeler varsa neden?
Peki sorun tam olarak nedir? Yeni bir çubuk belirdi - dikkate aldılar.
Danışmanın göstergeye bağlı olmamasını istiyorum. Ve çubukları hesapladı ve kendi içinde al/sat sinyallerini aldı. Mümkün mü?
Tek geçişli üstel ağırlıklı ortalama hesaplama algoritması kullanın
ana = (1 - a) * fiyat + bir * ana
Çok yanlış!
Bu şekilde düzeltin:
ma[i] = (1 - a ) * fiyat + a * ma[i+1]
onlar. gerekli derinliği a parametresine bağlı olan bir dizi gereklidir.
Aksi takdirde, en azından a parametresine bağlı olarak oldukça uzun sürebilen geçici süreç devam ettiği sürece tamamen saçmalık olacaktır.
Tüm bunları, Expert Advisor'daki gösterge okumalarını ve ilgili hesaplamaları karşılaştırarak kontrol etmek kolaydır.Elbette Expert Advisor'da bir diziden buffer yapmak da mümkün... Ama özel olarak tasarlanmış bir element - göstergeler varsa neden?
Göstergeden gelen eksik sinyallerle ilgili bir sorunum var, kimse bir tavsiyede bulunmadı
https://www.mql5.com/ru/forum/365021
baskılar casus göstergesinden bir olay geldiğini, yeni bir çubuğun kontrol edildiğini ve yeni çubuktan değil önceki çubuktan veri olduğunu gösterdi
aynı anda 3 terminalde test edildi, her iki geçiş de üç terminalden birindeydi, belki bir kaza