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
Bence SeriesInfoInteger işlevini kullanmak gereksiz çünkü çok özgür değil.
Öyleydi:
Dönüştü:
Hızdaki kazanç yaklaşık bir buçuk katıdır.
%2 kazanır. Yorum.
PERIOD_W1 ve PERIOD_MN1 için yanlış işlenecek çünkü geri sayım 1 Ocak 1970'den ve bu Pazartesi değil Perşembe. Ve her ayın farklı bir saniye sayısı vardır.
Bunun PeriodSeconds Documentation'a eklenmesi gerekir.
Kontrol etmedim - çünkü kodun belirli bir durum için çalışıp çalışmayacağını kesin olarak bilmeniz gerekiyor, aksi takdirde kendiniz bir hata yaptıysanız diğerini suçlamak doğru değil.
Bunun gibi durumlardan bahsediyorum, diyelim ki günde 14 saatimiz var (veya her saat başı alıntı olmasaydı daha az), bir M1 grafiğim var ve önceki gün M15 boyunca çubuk kaymasını bulmam gerekiyor . Onlar. Bir saatte 45 dakika veya günde 14 saat veya başka bir zaman/mum atakları varsa her şey düzgün çalışacak mı?
Şahsen böyle bir işlevi kullanmanın uygun olduğunu düşünüyorum:
Ancak bunun, en azından Exact parametresine sahip olmadığı için normal MQL4 iBarShift işlevinin tam bir analogu olmadığına dikkat edilmelidir.
Aksi takdirde, aynıdır.
MQL4'te standardın ve bu işlevin tam kimliğini gösteren basit bir komut dosyası ekliyorum.
Normal iBarShift işlevinden ve işlevimden gelen değerler eşit değilse, Yazdır. Hiçbir şey yazdırmadım.
%2 kazanır. Yorum.
Ne, bu doğru mu?
GetMicrosecondCount()'u koymak için tembeldim ve profil oluşturmaya güvendim.
Ne, bu doğru mu?
GetMicrosecondCount()'u koymakta tembeldim ve profil oluşturmaya güvendim.
Profil oluşturma başka bir şeyle ilgilidir. %2, alabileceğiniz maksimum kazançtır.
Makinemde Tester'da 250 milyon arama 1 saniye tasarruf sağlıyor.
Kesinlikle seninki en iyisi! Ama MT5'in neden çubuklarla çalıştığını hayal bile edemiyorum.
Ama MT5'te neden barlarla çalışmanız gerektiğini hayal bile edemiyorum.
Faremi kullandığımda bunu kullanıyorum. Örneğin burada .
Faremi kullandığımda bunu kullanıyorum. Örneğin burada .
Evet, anlamadığım şey bu.
Evet, anlamadığım şey bu.
yanlış anlaşılmayı anlamıyorum
Örneğin, özelliklerinden biri başlangıç zamanı (sol kenarlık) olan bir kanalım var. Ve bu kanalı farklı TF'ler üzerine kurmam gerekiyor. Peki, bir süre sonra yeni TF'deki bar numarasını bulmak dışında başka ne alternatifim var?
Evet ve çok daha fazlası.
Örneğin, tüm TF'leri bir logaritmik ölçekle birleştirdiğimde. Bu çok güzel bir konu. Burada da iBarShift analogu olmadan yapamazsınız
Şahsen böyle bir işlevi kullanmanın uygun olduğunu düşünüyorum:
Ancak bunun, en azından Exact parametresine sahip olmadığı için normal MQL4 iBarShift işlevinin tam bir analogu olmadığına dikkat edilmelidir.
Aksi takdirde, aynıdır.
MQL4'te standardın ve bu işlevin tam kimliğini gösteren basit bir komut dosyası ekliyorum.
Normal iBarShift işlevinden ve işlevimden gelen değerler eşit değilse, Yazdır. Hiçbir şey yazdırmadım.
Hayır, Comment() nedeniyle yazdırılmadı
Kaldırırsanız, 1 ile uyumsuzluk var, ancak bunu bir hata olarak görmüyorum çünkü. aslında, yeni bir çubuğun tanımı, yarım çubuk kaydırmalı iki algoritmada gerçekleşir. Yeni bir çubuk tanımlama versiyonum bana normal olandan daha mantıklı görünüyor.
yanlış anlaşılmayı anlamıyorum
Bar kullanmanın amacını anlamıyorum. Kopyalama Oranları , vb.
Senaryo neden bu kadar yavaş?
2018.03.30 09:21:05.208 BS (Si Splice,H4) 1 Start=15 Stop=3 Day_Shift=0 index=0
2018.03.30 09:21:05.208 BS (Si Splice,H4) 1 Start=2018.03.26 00:00 Stop=2018.03.29 00:00 Day_Shift=2018.03.29 20:00 index=0
2018.03.30 09:21:20.209 BS (Si Splice,H4) 2 Start=15 Stop=3 Day_Shift=0 index=0
2018.03.30 09:21:20.209 BS (Si Splice,H4) 2 Start=2018.03.26 00:00 Stop=2018.03.29 00:00 Day_Shift=2018.03.29 20:00 index=0
2018.03.30 09:20:49.300 Scripts script BS (Si Splice,H4) loaded successfully
2018.03.30 09:21:20.209 Scripts script BS (Si Splice,H4) removed