Hatalar, hatalar, sorular - sayfa 673
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
Renat, sıfır noktası - konuya gösterdiğiniz ilgi ve yapıcı yanıt için çok teşekkür ederiz!
Daha ileri.
1. profesyonel x64
Renat :
Daha doğru bir seçenek, x64'e geçmektir.
...
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.
Herhangi bir şekilde x64'e geçmek doğru eylemdir. Ancak. Biri diğerini dışlamaz. 16gig'im bile (bunlara sahibim) gerçekten ihtiyacım olmayan verileri israf etmek istemiyorum. Paralel olarak çalışacak başka bir şeyim var - üzerinde hacimli görevleri de hesaplamak istediğim MSVS, Matlab, vb. Bunu anladığınıza ve para biriktirmenin yollarını aramaya hazır olduğunuza sevindim.
2. Hikayenin sabit başlangıcı hakkında:
Renat :
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.
Tamamen (neredeyse) katılıyorum. Sorumluluk Reddi: Çoğu durumda optimizasyon, en son geçmişin küçük bir parçası üzerinde gerçekleştirilir. Bu durumda, tasarruf oldukça önemli olabilir. Yine de, seçeneğin nispeten işe yaradığını düşünüyorum - özellikle uygulama için iyi gelişmeler veya tahminleriniz varsa. Örneğin, seçenek bana tam olarak görünmüyor - çok fazla işçilik maliyeti var, ancak sonuç radikal değil. Yarım çözüm.
3. Ve işte o bir ide! :
Renat :
Belirli bir derinliği korurken bir göstergenin geçmişini gerçek zamanlı olarak kesmek , 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 .
Hayır ! , dolu değil - grafiğin çubukları aynı şekilde davranıyorsa - eşzamanlı olarak . Başka bir deyişle - halka arabellekleri (boyut olarak farklı olsalar bile) her zaman (zorla) AsSeries bayrağını kullanıyorsa - kullanıcının büyük sorunlar yaşaması beklenmez.
// Bu durumda, kullanıcıya sağlanan tüm geçmiş arabellekleri - gösterge (yani, AsSeries=true ile halka) yapmak uygun olacaktır.
Bu varyantta:
(1) gösterge ve fiyat dizilerinin dahili bir temsili vardır (sizin tarafınızda): soldan sağa indeksleme (AsSeries==false), kullanıcı boyutları önemli değildir ve genellikle " giriş yok".
Ve (2) bir kullanıcı tarafı vardır - tüm tamponlar daireseldir (uygulamada kullanıcı sanal bir doğrusal dizi görür), sağdan sola indekslenir (AsSeries==true) ve boyut kullanıcı tarafından belirlenir.
Burada kullanıcının çatısının yıkımları nelerdir? Hiçbiri. Belirtilen aralığın ötesine geçerken - standart reaksiyon Dizisi aralık dışında.
Zorluklar (dürüst olmak gerekirse, dikkate değer) sadece sizsiniz. Ancak! Programın çok yönlülüğü göz önüne alındığında, yalnızca bir kez zorlamanız gerekecektir. Ve beta hata ayıklarken, tomurcuktaki tüm "güzel aksaklıkları" düzeltin. Bundan sonra - evrensel mutluluk ve çok ekonomik bir tasarım.
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.
3. Ve işte o bir ide! :
Hayır ! , dolu değil - grafik çubukları aynı şekilde davranıyorsa - eşzamanlı olarak . Başka bir deyişle - eğer halka arabellekleri (boyut olarak farklı olsalar bile) her zaman (zorla) AsSeries bayrağını kullanıyorsa - kullanıcının büyük sorunlar yaşaması beklenmez.
// Bu durumda, kullanıcıya sağlanan tüm geçmiş arabellekleri - gösterge (yani, AsSeries=true ile halka) yapmak uygun olacaktır.
Bu varyantta:
(1) gösterge ve fiyat dizilerinin dahili bir temsili vardır (sizin tarafınızda): soldan sağa indeksleme (AsSeries==false), kullanıcı boyutları önemli değildir ve genellikle " giriş yok".
Ve (2) bir kullanıcı tarafı vardır - tüm tamponlar daireseldir (uygulamada kullanıcı sanal bir doğrusal dizi görür), sağdan sola indekslenir (AsSeries==true) ve boyut kullanıcı tarafından belirlenir.
Burada kullanıcının çatısının yıkımları nelerdir? Hiçbiri. Belirtilen aralığın ötesine geçerken - standart reaksiyon Dizisi aralık dışında.
Zorluklar (dürüst olmak gerekirse, dikkate değer) sadece sizsiniz. Ancak! Programın çok yönlülüğü göz önüne alındığında, yalnızca bir kez zorlamanız gerekecektir. Ve beta hata ayıklarken, tomurcuktaki tüm "güzel aksaklıkları" düzeltin. Bundan sonra - evrensel mutluluk ve çok ekonomik bir tasarım.
İyi bir fikir. için. Ancak, halka şemasının girişini iptal etmez, ancak onu iyi bir şekilde tamamlar.Test koşullarını açıklayacağım:
Göstergenin otomatik kırpılmasının bir sonucu olarak:
Test koşullarını açıklayacağım:
Göstergenin otomatik kırpılmasının bir sonucu olarak:
1.
Evet, tolere edilebilir. Bunun kitlesel bir memnuniyetsizliğe yol açması pek olası değildir; aksine, tasarruflar çok cesaret verici olacaktır. Hiç kimse devasa bir MaxBar ayarlayarak hafızanın boşa harcanmasını yasaklamaz.
// Burada göstergeler atlama çubukları nedeniyle hatalı! Memnuniyetsizliğin ciddi bir şekilde haklı olduğu yer burasıdır!
// Yani sen buna bile katlanıyorsun... :) Eh, yapmalıyız... :(
2.
Bu sadece hayır ve hayır! Halka şeması, tarih boyunca geçiş yaparken kopyalamada büyük tasarruf sağlar. Aslında, bir çubuk (N çubuk) kaydırırken, tam olarak bir değer (N değer) kopyalanmalıdır. Bir dizinin sanallaştırılması için yapılan harcamalar ( kullanıcı ) ihmal edilebilir düzeydedir. Aslında, stres testleri sırasında tespit edilmeleri bile zordur ( bölmenin geri kalanı işlemci tarafından bir döngüde hesaplanır + geçmişteki her vardiyada tamponun sanal başlangıcının ofseti - birkaç döngü daha). Böylece pratikte hız kaybetmiyoruz. Bu yavaşlamayı tespit etmek imkansız, çok küçük. Ve devasa bellek tasarrufu fonunda, bu kayıplar kazançla kıyaslanamaz.
3.
Ahh yüz...
Nedense, sınırsız çubuklarda boğulan göstergelerin etrafında çok fazla dans ve çığlık var, ancak dans eden grafik nesneler hakkında tek bir kelime yok. Örneğin, Unlimited'da (örneğin MN1'de) süper büyük Andrews Pitchfork oluşturmaya çalışın, ardından terminal ayarlarındaki çubuk sayısını sınırlayın, daha düşük zaman çerçevelerine gidin ve bağlantı noktalarına geri sarın. Bazıları, aşırı uçlardan görkemli bir zaman ayrımında olacak (bu, üç noktanın tümüne sahip olan dirgen, yalnızca gerçek M1 çubukları alanında, daha yüksek zaman dilimlerinden sahte olanların sınırlarının ötesine geçmeden! ). Ve hepsi neden? Görünüşe göre, M1'de bazı otomatik bağlantı noktalarının tam M1 -değerini hesaplamak için yeterli geçmiş veri olmadığı için. Her ne kadar tarihsel veriler nerede?! Yeterli olmuş olabilirler, ancak pencerede görüntülenen çubuklar değil, bu nedenle vardiyalar var. Yani, bazı noktalar "nerede yattıklarını gerçekten bilmiyorlar".
Keşke biri evde kontrol etse, aksi halde belki böyle bir pandemiye girerim ...
Garip bir şey fark ettim!
Yeni bir çubuğun oluşumu sırasında, önceki çubukların (örneğin, önceki 10 çubuk) Aç ve Kapat değerlerini sayarsanız ve ardından 5 saniye sonra tekrar alırsanız, bu değerlerden bazıları farklılık gösterir ve sonra onları yeni çubuk oluşturulurken alırsanız, her şey yolundadır, ancak burada ilk birkaç saniyede, bir nedenden dolayı bu değerler farklıdır.
Umarım net bir şekilde anlatmışımdır.
Yeni bir çubuğun başlangıcından itibaren Aç ve Kapat çubuklarının değerlerini okumadan önce bana söyleme, 5 saniyeden fazla bir gecikme ayarlamanız mı gerekiyor?
İşte bir çalışma örneği:
Üstünde bir gecikmeden sonra doğru çalıştı, altında hatalı yeni bir çubuğun ortaya çıkmasından hemen sonra ve sağda 6. satır için standart.
Belki de sorun senkronizasyon dışıdır, kullanılan tüm enstrümanlar için yeni çubuğun izlenmesi arzu edilir.
Evet, haklıydın, teşekkürler!
Aynı şekilde opera.