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
Web sitesi politikasını ve kullanım şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Diyelim ki elimizde
Aynı zamanda start_time'ın 2018.04 olması gerektiğini de biliyoruz . 28 23:00 _
Zamanın doğru olmadığı ortaya çıktı?
Alex, örneğime bak. Geçtiğiniz saatlik zamanın mevcut çubuktan en yakın zamana nasıl dönüştüğünü satır satır gösterdim.
Limit değişken tipinin bildirimini bulamadım. Vizyon zayıf
50 posta, prosedür OnCalculate
Post 50, prosedür OnCalculate
Teşekkürler ama hangisi 50? Belki bir bağlantı sağlayabilirsin?
Teşekkürler ama hangisi 50? Belki bir bağlantı sağlayabilirsin?
https://www.mql5.com/en/forum/262864/page5
Yalnızca sayfaya bağlantı. Yazının başlığında #50 yazıyor. #74 ))
Önce limit=start_index-stop_index+ 1, yani limit==1 yazdınız ve ardından 2'ye bölmenin limit=(int)(stop_time-start_time)/PeriodSeconds(_Period) olduğu yerde yazdınız. Birim eklenmedi. Sıfır nokta ile bölünür.
Bu doğru, limit=start_index-stop_index+ 1 i>0 içindir, yani. geçmiş üzerinde hesaplama için ve geçerli çubukta limit=(int)(stop_time-start_time)/PeriodSeconds(_Period) hesaplaması için.
Evet ve asıl mesele, zamanımızın neden bu kadar çarpık olduğu - eğer bir saatlik zaman çerçevemiz varsa, o zaman tarihler hem başlangıçta hem de sonunda yuvarlak olmalıdır - asıl sorun bu, zamanın bar ilk tarihte bir şekilde yanlış olur !!!
Belki bir sorun vardır
start_time bu noktada doğru geldiği için
datetime start_time=rates[i].time;Alexey, "sonunda" yok. Bu sadece kuantizasyon. Tam 18:00'de bar açıldı, minimum ve maksimumu gösterdi ve aynı anda güvenli bir şekilde kapandı.
Bakın, barımız 18:00'de açıldı, yani başlangıç zamanı ( start_time ) 18:00 olacak ve TF saat için bitiş ( stop_time ) tahmini bar bitiş zamanı 19:00 olacak. Böylece aralarındaki indeks M1 zaman diliminde farklı olacaktır. Ve kodda, başlangıç ve bitiş indeksinin aynı olduğu görülür, bu doğru değildir.
Bu doğru, limit=start_index-stop_index+ 1 i>0 içindir, yani. geçmiş üzerinde hesaplama için ve geçerli çubukta limit=(int)(stop_time-start_time)/PeriodSeconds(_Period) hesaplaması için.
Evet ve asıl mesele, zamanımızın neden bu kadar çarpık olduğu - eğer bir saatlik zaman çerçevemiz varsa, o zaman tarihler hem başlangıçta hem de sonunda yuvarlak olmalıdır - asıl sorun bu, zamanın bar ilk tarihte bir şekilde yanlış olur !!!
Belki bir sorun vardır
start_time bu noktada doğru geldiği için
Ve ilk önce saatlik zaman diliminden CopyRates yaparsanız (yuvarlak sayılar elde edilir), ardından mevcut zaman diliminden (Zamana dönüşen zaman) zamanı ve saatlikten Rates'i Create Figure prosedürüne geçirirseniz, sizin için nasıl yuvarlak olacaklar ve o zaman halihazırdaki zaman diliminin zaman dizisine göre dizini mi arıyorsunuz? start_index= ArrayBsearch ( Zaman ,başlangıç_zamanı);