Hatalar, hatalar, sorular - sayfa 672
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
Penceredeki çubuklar ne kadar?
Sorun şu ki, TF değiştirilirken terminaldeki bellek serbest bırakılmaz. Görev yöneticisini başlatın, göstergeyi grafiğin üzerine bırakın ve hafızanın büyümesini izleyin. Peter başka bir TF'ye geçer. Hafızanın yeniden büyümeye başladığını göreceksiniz. Mantıksal olarak, başka bir TF'ye geçerken, önceki TF'nin verileri bellekten kaldırılmalıdır. Önceki TF'lerden gelen veriler yok edilmediğinden, bellek aşırı yüklenene ve bir hata üretilene kadar büyür. Göstergenizi tablodan kaldırırsanız belli bir süre sonra hafızanın temizlendiğini göreceksiniz. Ancak gösterge çalışırken silinmez.
Benim fikrim: Bu sorunun çözümü ServiceDec.
Teşekkürler, TF'yi değiştirmeden önce göstergeyi kaldıracağım. Ek olarak, penceredeki maksimum çubuk sayısını 2000000'den 1000000'e düşürdüm, görünüşe göre MetaDriver bana anlatmak istiyor.
Çalışıyor gibi görünse de.
Teşekkürler, TF'yi değiştirmeden önce göstergeyi kaldıracağım. Ek olarak, penceredeki maksimum çubuk sayısını 2000000'den 1000000'e düşürdüm, görünüşe göre MetaDriver bana anlatmak istiyor.
Çalışıyor gibi görünse de.
Neden bir çizgi filme ihtiyacın var? 100.000 (yüz bin) bana yeter. Ben de bunu kastetmiştim.
Bu, testi hiçbir şekilde herhangi bir derinlikle sınırlamaz.
Bu, yalnızca (1) pencerelerde gösterimi (2) gösterge arabelleklerinin boyutlarını sınırlar.
"Görünür tarihi" uzun ve bilinçli olarak sınırladım. Sonuç - Hafızayla ilgili bir sorunum yok.
Neden bir çizgi filme ihtiyacın var? 100.000 (yüz bin) bana yeter. Ben de bunu kastetmiştim.
Bu, testi hiçbir şekilde herhangi bir derinlikle sınırlamaz.
Bu, yalnızca (1) pencerelerde (2) gösterimi , gösterge arabelleklerinin boyutlarını sınırlar.
"Görünür tarihi" uzun ve bilinçli olarak sınırladım. Sonuç - Hafızayla ilgili bir sorunum yok.
Evet teşekkür ederim daha da düzenleyeceğim ki hafızada sorun olmasın yoksa InstaForex'te 108 çift kullanacağım.
Vapche teması hala aynı. MT5'in şafağında bile, tüm göstergelere yeni bir standart parametre - hesaplama için çubuk sayısı - eklemenin gerekli olacağını haykırdım.
Aksi takdirde, tek bir sınırlayıcı elde edilir - TERMINAL_MAXBARS . Bu, birçok enstrümanı gerçek zamanlı olarak göstergeleri kullanarak analiz eden uzmanlar için kabul edilemez. Çoğu zaman (%99) Expert Advisors AND ALL'daki son çubukların kesinlikle belirli bir sayısına ihtiyacım var. Diğer her şey boğazımda. Tabii sadece ben değil...
Göz ardı edildi. Sonuç olarak, bu tür hesaplamalar Expert Advisor'ın koduna aktarılır.
Oh evet! Ve kendi kendine yazılmış birçok yamanın görünümü. Akıllı makaleler bile yazılır ve yayınlanır, örneğin:
Yardımcı göstergeler için bellek tüketimini azaltın
Göstergelerin Zigzag ve ATR örneğinde sınıflar halinde uygulanması
...
Düzenli görüntülenen göstergeleri ve kısa hesaplanan göstergeleri ayırırsak, uzun kümülatif göstergelerde bir tutarsızlık elde etmek kolay olacaktır.
Aynı zamanda bizim tarafımızda tehlikeli koltuk değneklerine yol açacaktır.
Grafik başına 100000 çubuk ayarlamak veya x64'e geçmek iyi bir yoldur.
Renat :
Индикаторы на короткой истории нельзя рассчитывать, так как они являются общим разделяющимся между всеми процессами (терминал, окна, эксперты) ресурсом. Причем на индикаторах действуют множество правил обновления, синхронизации и пересчета рыночного окружения.
Если разделить штатные отображаемые индикаторы и короткие расчетные, то легко будет получить расхождение на длинных кумулятивных индикаторах.
Так же это приведет к опасным костылям на нашей стороне.
Хороший способ - устанавливать 100000 баров на чарт или переходить на х64.
Genel olarak, hiçbir şey değişmez. Gösterge arabelleklerinin boyutunu sınırlamak için MQL5 kullanma yeteneğinin tanıtılması talepleri reddedilir ve programınız kullanılan çok sayıda gösterge arabelleği nedeniyle çok büyük miktarda bellek tüketmeye başlarsa, bu hemen "programcı hatası" olarak adlandırılır.
"Uzman Danışmanlarda, çoğu zaman (%99) son çubukların ve HER ŞEYİN kesinlikle belirli bir sayısına ihtiyacım var. Gereksiz her şey boğazımda. Tabii ki, sadece ben değil..." (c)
2. Kısa bir geçmişe ilişkin göstergeler, tüm süreçler (terminal, pencereler, uzmanlar) arasında paylaşılan ortak bir kaynak olduğu için hesaplanamaz. Ayrıca, göstergeler üzerinde piyasa ortamının güncellenmesi, senkronize edilmesi ve yeniden hesaplanması için birçok kural bulunmaktadır.
3. Düzenli görüntülenen göstergeleri ve kısa hesaplanan göstergeleri ayırırsak, uzun kümülatif göstergelerde bir tutarsızlık elde etmek kolay olacaktır.
Aynı zamanda bizim tarafımızda tehlikeli koltuk değneklerine yol açacaktır.
1. Grafik başına 100000 çubuk ayarlamak veya x64'e geçmek iyi bir yoldur.
1. Ben sadece bunu yaptım. Yine de, bu rahatsız edici bir uzlaşma. İdeal olarak, geliştirme sorunlarını tamamen görmezden gelirseniz (tamamen bir kullanıcı olarak), hesaplamanın uzunluğunu ayarlarken bir seçeneğim olmasını isterim. Tablo için - tam uzunlukta ( her zaman olmasa da, ciddi ve önemli istisnalar vardır), uzmanlar için - tam olarak ihtiyacınız olduğu kadar.
2. Bir düşünelim. Bir geliştirici olarak, aynı zamanda karmaşıklıkları ve sınırlamaları anlıyorum. böyle bir yaklaşım (hesaplamanın uzunluğunun bir göstergesi ile) ve yine de hafıza tüketimi de benim sorunum ve inatla ikincil rollere geri dönmek istemiyor. Belirli bir teklif-çözümüm var - fatura dönemini (hadi buna diyelim) eşit bir parametre-olmayan-diğerlerinden daha kötü- olarak değerlendirmek için. O zaman, aynı parametrelere sahip, ancak farklı bir hesaplama periyoduna sahip iki gösterge, yalnızca iki farklı göstergedir. Evet, teoride ek maliyetlere yol açabilecek aptalca kullanım durumları vardır (kullanıcı fatura dönemleri oluşturursa), ancak pratikte bu pek olası değildir. Biri bu tırmıkla yürümek isterse, bu onun hatasıdır. Yaklaşık olarak şu andan itibaren TÜM kullanıcılar "çok fazla gösterge açmak ve TERMINAL_MAXBARS'ı azaltmakla ilgilenmemek" için suçlanacak.
3. Biliyorum . Örneğin, EMA hesaplanırken zamanın başlangıcından itibaren tüm çubukların kullanıldığını biliyorum. Ancak stokastikte, RSI'da ve çok sayıda ( baskın ) diğer göstergelerde, hesaplamanın sınırlı bir uzunluk için yapıldığını da biliyorum. Ve bu bilgi , fatura döneminin (MaxBar) seçimine esnek bir şekilde yaklaşmamı sağlıyor. Sadece bana bir seçenek ver.
Yaklaşık olarak şu andan itibaren TÜM kullanıcılar "çok fazla gösterge açmak ve TERMINAL_MAXBARS'ı azaltmakla ilgilenmemek" için suçlanacak.
Evet, özellikle şampiyona koşullarında, TERMINAL_MAXBARS'ın boyutunu hiç etkileyemediğiniz zaman.
1. Ben sadece bunu yaptım. Yine de, rahatsız edici bir uzlaşma. İdeal olarak, geliştirme sorunlarını tamamen görmezden gelirseniz (tamamen bir kullanıcı olarak), hesaplamanın uzunluğunu ayarlarken bir seçeneğim olmasını isterim. Tablo için - tam uzunlukta ( her zaman olmasa da, ciddi ve önemli istisnalar vardır), uzmanlar için - tam olarak ihtiyacınız olduğu kadar.
2. Hala düşünelim. Bir geliştirici olarak, aynı zamanda karmaşıklıkları ve sınırlamaları anlıyorum. böyle bir yaklaşım (hesaplamanın uzunluğunun bir göstergesi ile) ve yine de hafıza tüketimi de benim sorunum ve inatla ikincil rollere geri dönmek istemiyor. Belirli bir teklif-çözümüm var - fatura dönemini (hadi buna diyelim) eşit bir parametre-olmayan-diğerlerinden daha kötü- olarak değerlendirmek için. O zaman, aynı parametrelere sahip, ancak farklı bir hesaplama periyoduna sahip iki gösterge, yalnızca iki farklı göstergedir. Evet, teoride ek maliyetlere yol açabilecek aptalca kullanım durumları vardır (kullanıcı fatura dönemleri oluşturursa), ancak pratikte bu pek olası değildir. Biri bu tırmıkla yürümek isterse, bu onun hatasıdır. Yaklaşık olarak şu andan itibaren TÜM kullanıcılar "çok fazla gösterge açmak ve TERMINAL_MAXBARS'ı azaltmakla ilgilenmemek" için suçlanacak.
3. Biliyorum . Örneğin, EMA hesaplanırken zamanın başlangıcından itibaren tüm çubukların kullanıldığını biliyorum. Ancak stokastikte, RSI'da ve çok sayıda ( baskın ) diğer göstergelerde, hesaplamanın sınırlı bir uzunluk için yapıldığını da biliyorum. Ve bu bilgi , fatura döneminin (MaxBar) seçimine esnek bir şekilde yaklaşmamı sağlıyor. Sadece bana bir seçenek ver.
Fikir açık.
Biz kendimiz kaynak tüketimini azaltmak istiyoruz. Belki de çözüm, yalnızca bu Uzman Danışmanda oluşturulan göstergelere göre hareket edecek olan bir GöstergeMaxDepth(uint len) işlevi olabilir.
Ancak sorun şu ki, test sırasında birikim modundaki gösterge arabellekleri geçmişle birlikte büyüyecek ve tasarruflar işe yaramayacak. Belirli bir derinliği korurken bir göstergenin geçmişini gerçek zamanlı olarak kırpmak, grafik çubuklarının ve gösterge arabelleğinin senkronizasyonunu düşünen / alışık olan programcılar için güzel hatalar ve çatının doğrudan yıkılması ile doludur.
Daha doğru bir seçenek, x64'e geçmektir.
Artık bellek tasarrufu ilkesine karşı maksimum verimlilik ilkesine sahip olan gösterge önbelleğini revize edeceğiz. Şimdi olduğu gibi bir süre hafızada tutmak yerine, bırakılan göstergeleri boşaltmaya çalışalım. Bu, IndicatorRelease aracılığıyla doğrudan yükleme ile art arda yüzlerce göstergenin çağrılmasını mümkün kılacaktır.
Tabii ki, birileri piyasa tarama modunda yüzlerce göstergeyi boşaltmadan çağırırsa, yalnızca 64 bit sürüme + ek bellek yüklemeye doğrudan bir yolu vardır.
Şimdi x32'de büyük testler yapmak garip. 16 GB belleğe sahip herhangi bir iyi x64 bilgisayar (video kartlarında ve monitörlerde fanatizm olmadan) 15.000 ruble için satın alınabilir.