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
Vladimir yok. Biraz öyle değil.
Bu durumda ArraySetAsSeries(array, false); iMAOnArray() öğesinin dikkate alındığı üç yüz öğeden oluşan bir diziye uygulanır. Ancak bunun için dizi doldurma döngüsü yerine CopyOpen() kullanmak daha iyidir.
Anladığım kadarıyla, bu seçenek daha iyi olurdu
Vladimir yok. Biraz öyle değil.
Bu durumda ArraySetAsSeries(array, false); iMAOnArray() öğesinin dikkate alındığı üç yüz öğeden oluşan bir diziye uygulanır. Ancak bunun için dizi doldurma döngüsü yerine CopyOpen() kullanmak daha iyidir.
Anladığım kadarıyla, bu seçenek daha iyi olurdu
Aslında bir konu. Tüm diziyi değil, yalnızca son N öğelerini saymam gerekiyorsa.
Bu fonksiyonları kısıtlama altında hesaplamanın mantığını tam olarak anlamıyorum. Bir zaman serisi dizisi vardır (gösterge tamponlarından biri), eleman sayısını 0'a eşit bırakırsanız, soru yoktur, her şey hesaplanır ve ortaya çıkar, ancak hesaplamalara katılan eleman sayısı aynı olduğunda ofsetler azalır, sadece birincil olanları alırım. Basitçe söylemek gerekirse, 5000 elemanlık bir dizi var (tablodaki çubuklar), zaman kazanmak için sadece son 300'ü hesaplamam gerekiyor, ancak ikinci parametrede 300 belirttiğimde birincil 5000-4700 öğeleri alıyorum, ancak 300-0 ofsetinde ve ardından arama sırasındaki değerler değişmez. Bu parametreyi kullanmanın amacı nedir?
Cehennem biliyor. Basitçe öldür. Hesaplamaları hızlandırmanız gerekiyorsa, döngünüzde hesaplanan öğelerin sayısını azaltın.
İki şeyden biri: ya imkansız ya da zaman serisinin değil, zaman serisinin bazı gizli kombinasyonu, hesaplama talimatlarına ihtiyaç var.
Cehennem biliyor. Basitçe öldür. Hesaplamaları hızlandırmanız gerekiyorsa, döngünüzdeki hesaplanan öğelerin sayısını azaltın.
İki şeyden biri: ya imkansız ya da zaman serisinin değil, zaman serisinin bazı gizli kombinasyonu, hesaplama yönüne ihtiyaç var.
Evet, biraz daha önce yazdığım gibi, sadece bir seçenek var - bu, en az tek bir unsurun dikkate alınabileceği belirtilen işlevlerin kendi analoglarının kullanılmasıdır.
Durumun paradoksu, herhangi bir göstergeye (fiyat çizgisi) bir ortalama veya bollinger bandı atarak benzer bir model yaparsanız, bu işlevleri kodda kullanırken olduğu gibi, tüm geçmiş çubuklarının ilk hesaplanmasındaki bu tür frenler, terminali yeniden başlattığınızda veya zaman dilimlerini değiştirdiğinizde gözlemlenmez, burada ve bu fonksiyonlarda neyin hesaplanmasının bu kadar uzun sürdüğü net değildir.
Cehennem biliyor. Basitçe öldür. Hesaplamaları hızlandırmanız gerekiyorsa, döngünüzdeki hesaplanan öğelerin sayısını azaltın.
İki şeyden biri: ya imkansız ya da zaman serisinin değil, zaman serisinin bazı gizli kombinasyonu, hesaplama talimatlarına ihtiyaç var.
Ben de bu tasarımı kullandım
Bu arada, "MovingAverages.mqh" , eski sürüme göre bile "iMAOnArray" den iki kat daha hızlı hesapladı .
https://www.mql5.com/ru/forum/79988
Evet, biraz daha önce yazdığım gibi, sadece bir seçenek var - bu, en az tek bir unsurun dikkate alınabileceği belirtilen işlevlerin kendi analoglarının kullanılmasıdır.
Durumun paradoksu, herhangi bir göstergeye (fiyat çizgisi) bir ortalama ve bir bollinger bandı atarak benzer bir model yaparsanız, bu işlevleri kodda kullanırken olduğu gibi, tüm geçmiş çubuklarının ilk hesaplanmasındaki bu tür frenler, terminali yeniden başlattığınızda veya zaman dilimlerini değiştirdiğinizde gözlemlenmez, burada ve bu fonksiyonlarda neyin hesaplanmasının bu kadar uzun sürdüğü net değildir.
iMAOnArray kullanırken bile fren mi yapıyorsunuz? Böyle olmamalı. O zamanlar StdOnArray'den (veya BandsOnArray'den hatırlamıyorum) bir yavaşlama oldu, geliştiriciler uzun süre bir bug'ın varlığını kabul etmediler. Sonra aniden düzelttiler ve hızlı çalıştı. Kim bilir, böcek geri dönmüş olabilir. iMAOnArray()'den gözle görülür bir yavaşlama varsa, bu bir hatadır. Görünüşe göre birkaç ay önce bunun hakkında konuşulmuştu ... görünüşe göre işler hala orada.
iMAOnArray kullanırken bile fren yapıyor musunuz? Böyle olmamalı. Bir süredir olduğu gibi StdOnArray'den bir yavaşlama oldu, geliştiriciler uzun bir süre bir bug'ın varlığını kabul etmediler. Sonra aniden düzelttiler ve hızlı çalıştı. Kim bilir, böcek geri dönmüş olabilir. iMAOnArray()'den gözle görülür bir yavaşlama varsa, bu bir hatadır. Görünüşe göre birkaç ay önce bunun hakkında konuşulmuştu ... görünüşe göre işler hala orada.
Çok yavaşlayıp yavaşlamadığına veya kabul edilebilir olup olmadığına karar vermek zordur, çünkü her şey grafiğin uzunluğuna (çubuk sayısı) bağlıdır, buradaki yakalama, optimizasyon için biraz hesaplamanız gerektiğidir ve aslında öyledir. hesaplamanın uzunluğunu sınırlamak imkansız.
MovingAverages.mqh üzerinde bir hesaplama yapın ve her şey çok hızlı bir şekilde hesaplanacaktır.
Bu yüzden kodun "çalışan" versiyonunu gösterin, orijinal kaynak kodu burada, istediğim üç yüz yerine 12 görüntülenen öğeye kesmeye çalışıyorsunuz ve belirtilenle 3 gösterge tamponu ile sonuçlanmalısınız. altbilgide en az 300 öğe görüntülenecek şekilde veriler ve dahası, yeni bir çubuk geldiğinde sırasıyla 301 ve ardından değerler çizildi, ancak unutmayın ki, bir hesaplama kısıtlaması olarak 0 kullanılması durumunda, sadece yeni çubuğun değerleri yeniden hesaplanır ve ikinci arabellek için ortalama (düzeltme) türü mutlaka SMA olmayacaktır ve mevcut 4'ten herhangi biri olabilir.
Devam etmek.