iBarShift'e benzer - sayfa 3

Yeni yorum
 
Vasiliy Pushkaryov :

İşte senaryo

Sadece asılı kalıyor. Tablodan zorla sildiğimde sonucu alıyorum.

Ben de denedim, sana tavsiyede bulundum. Ama kullandığın ve sana yakıştığı için seni ikna etmeyeceğim.

Üzgünüm Vasili. Seni yanlış anladım. Mesajını çabucak okudum, tk. sürüyordu. 32000000000'e sahip olduğum son parametreden bahsettiğimizi sanıyordum, t parametresini kastettiğiniz ortaya çıktı. Evet, gerçekten de sonucun orijinal MQL4 iBarShift()'ten farklı olduğu tek durum budur. Ancak, zamanın mevcut anından çubuk (veya çubuk indeks) sayısını almak için bu işlevi kullanmaya çalışmak çok garip, yani. TimeCurrent() , çubuğun sıfır olduğu açık olduğunda. Genel olarak, TimeCurrent () 'deki Bars () işlevinin 1 değil 0 vermesi garip. Ancak standart Bars() işlevinin kullanımı nedeniyle bir şey askıda kalamaz, nasıl olursa olsun, özellikle komut dosyası Print() çalıştığından beri, yani her şey yolunda.
Anlayın, Vasily, iBarShift analogunun diğer uygulamalarını küçümsemek istemiyorum, şahsen böyle bir yapı kullanıyorum ( Bars ( NULL , 0 , t , 32000000000 )- 1 ;), çünkü en hızlısı. Ve bu yapı iBarShift'in yerine geçmez, sadece belirli bir zamanda bar indeksini bulmak için bir fonksiyon olarak kullanılır ve evrensellikten ne demek istediğinizi anlamıyorum. Ve daha büyük zaman maliyeti nedeniyle yukarıdaki işlevlerin tümünü kullanmayı makul bulmuyorum. (Dosya tozu reklamını hatırlayın). Gerçek şu ki, bu işlevin kullanımı genellikle programların yürütme süresini önemli ölçüde artıran büyük döngülerde gerçekleşir ve yürütme süresi için çok açgözlüüm. Çeşitli işlevlerin yürütme süresini hesaplamayı denedim (yalnızca ben değil , önceki mesaja bakın ) ve bu seçenek kesinlikle en hızlısı. En hızlı olarak konumlandırılan bu seçenek bile aynı, sadece yapımında ( Bars ( NULL , 0 , t , 32000000000 )- 1 ;) daha da basitleştirildi. Tabii ki, ne kullanacağı herkese kalmış.

Her durumda, esas hakkındaki yorumunuz için teşekkür ederiz.

 
Nikolai Semko :

Ancak, zamanın mevcut anından çubuk (veya çubuk indeks) sayısını almak için bu işlevi kullanmaya çalışmak çok garip, yani. TimeCurrent() , çubuğun sıfır olduğu açık olduğunda. Genel olarak, TimeCurrent () 'deki Bars () işlevinin 1 değil 0 vermesi garip.

TimeCurrent () gibi özel bir durum elimize geldi.

Şimdi Bars () işleviyle ilgili bu notu daha dikkatli okudum:

"Belirli bir tarih aralığındaki çubuk sayısı istenirken sadece açılış saati bu aralıkta olan çubuklar dikkate alınır . Örneğin, haftanın geçerli günü Cumartesi ise, o zaman ile haftalık çubuk sayısı istenirken start_time=last_Tuesday ve stop_time=last_Friday, haftalık zaman dilimindeki açılış saati her zaman Pazar gününe denk geldiğinden ve haftalık tek bir çubuk belirtilen aralıkta olmadığı için işlev 0 döndürür."

TimeCurrent() zamanı, geçerli çubuğun açılış zamanından hemen hemen her zaman daha sonra olduğundan, bu nedenle, Bars() işlevi 0 döndürür. Saatlik zaman diliminde 02:05'e karşılık gelen zamanı geçersek, start_time parametresini seçin ve çubuğun bize yatırılmasını istiyorsanız, saat 2'de başladı, ardından CopyTime( ) aracılığıyla çubuğun açılış saatini (02:00:00) almanız gerekir. Aksi takdirde , Bars() işlevi bu çubuğu yok sayar.

Onlar. şimdi saat 3:30 ise, saatin saat diliminde 2:05'in indeks 1'e sahip çubuğa atıfta bulunduğunu anlıyorum. 2. sayfadaki fonksiyonların hiçbiri bu indeksi döndürmez. Bu değişiklikle Renat Akhtyamov işlevi beklediğimi döndürdü.

 int iBarShift2( string symbol, ENUM_TIMEFRAMES timeframe, datetime time)
{
   datetime tm0[ 1 ], tm1[ 1 ];      
   CopyTime (symbol, timeframe, 0 , 1 , tm0);             // время открытия 0-го бара
   CopyTime (symbol, timeframe, time, 1 , tm1);           // время открытия бара, в который попадает указанный time

   return Bars (symbol, timeframe, tm0[ 0 ], tm1[ 0 ])- 1 ;
}

Test olarak kullandığım dizin arama işlevleri için 4 seçenekli bir komut dosyası ekliyorum.

Dosyalar:
TestIBS.mq5  5 kb
 
Vasiliy Pushkaryov :

TimeCurrent () gibi özel bir durum elimize geldi.

Şimdi Bars () işleviyle ilgili bu notu daha dikkatli okudum:

"Belirli bir tarih aralığındaki çubuk sayısı istenirken sadece açılış saati bu aralıkta olan çubuklar dikkate alınır . Örneğin, haftanın geçerli günü Cumartesi ise, o zaman ile haftalık çubuk sayısı istenirken start_time=last_Tuesday ve stop_time=last_Friday, haftalık zaman dilimindeki açılış saati her zaman Pazar gününe denk geldiğinden ve haftalık tek bir çubuk belirtilen aralıkta olmadığı için işlev 0 döndürür."

TimeCurrent() zamanı, geçerli çubuğun açılış zamanından hemen hemen her zaman daha sonra olduğundan, bu nedenle, Bars() işlevi 0 döndürür. Saatlik zaman diliminde 02:05'e karşılık gelen zamanı geçersek, start_time parametresini seçin ve çubuğun bize yatırılmasını istiyorsanız, saat 2'de başladı, ardından CopyTime( ) aracılığıyla çubuğun açılış saatini (02:00:00) almanız gerekir. Aksi takdirde , Bars() işlevi bu çubuğu yok sayar.

Onlar. şimdi saat 3:30 ise, saatin saat diliminde 2:05'in indeks 1'e sahip çubuğa atıfta bulunduğunu anlıyorum. 2. sayfadaki fonksiyonların hiçbiri bu indeksi döndürmez. Bu değişiklikle Renat Akhtyamov işlevi beklediğimi döndürdü.

Test olarak kullandığım dizin arama işlevleri için 4 seçenekli bir komut dosyası ekliyorum.

Doğal olarak, çubuğun zamanını aktarmanız gerekir. Açıklığa kavuşturmayı unuttum.
 
Bu işlevin neden hala SB'de olmadığını anlamıyorum
 
transcendreamer :
Bu işlevin neden hala SB'de olmadığını anlamıyorum

Tüm seçenekleri denedim, en doğru olanı Alain Verleyen'den.
(bir grup nesneyle karmaşık bir gösterge üzerinde test edilmiştir)
 
Taras Slobodyanik :

Alain Verleyen'den tüm seçenekleri denedim, en doğru olanı.
(bir grup nesneyle karmaşık bir gösterge üzerinde test edilmiştir)
https://www.mql5.com/ru/code/18305
Высокопроизводительная библиотека iTimeSeries
Высокопроизводительная библиотека iTimeSeries
  • oylar: 17
  • 2017.05.25
  • nicholishen
  • www.mql5.com
Эта библиотека предоставляет молниеносный доступ к таймсериям для реализации привычных методов MQL4 (например, iBarShift) в чувствительных к задержкам приложениях на MQL5.
 
fxsaber :
https://www.mql5.com/ru/code/18305

Bence SeriesInfoInteger işlevini kullanmak gereksiz çünkü çok özgür değil.

Öyleydi:

 int iBarShift3( const string Symb, const ENUM_TIMEFRAMES TimeFrame, datetime time, const bool Exact = false )
{
   static int Res = - 1 ;
   static string LastSymb = NULL ;
   static ENUM_TIMEFRAMES LastTimeFrame = 0 ;
   static datetime LastTime = 0 ;
   static bool LastExact = false ;

  time -= time % :: PeriodSeconds (TimeFrame);

   if ((time != LastTime) || (Symb != LastSymb) || (TimeFrame != LastTimeFrame) || (Exact != LastExact))
  {
     datetime LastBar;

     if (:: SeriesInfoInteger (Symb, TimeFrame, :: SERIES_LASTBAR_DATE , LastBar))
     {
         if (time > LastBar)
          Res = 0 ;
         else
        {
           const int Shift = :: Bars (Symb, TimeFrame, time, LastBar);

           if (Shift > 0 )
            Res = Shift - 1 ;
        }
      }

    LastTime = time;
    LastSymb = Symb;
    LastTimeFrame = TimeFrame;
    LastExact = Exact;
  }

   return (Res);
}

Dönüştü:

 int iBarShift3( const string Symb, const ENUM_TIMEFRAMES TimeFrame, datetime time, const bool Exact= false )
  {
   static int Res=- 1 ;
   static string LastSymb= NULL ;
   static ENUM_TIMEFRAMES LastTimeFrame= 0 ;
   static datetime LastTime= 0 ;
   static bool LastExact= false ;
   static int PerSec=:: PeriodSeconds (LastTimeFrame);
   
   if (LastTimeFrame!=TimeFrame) PerSec=:: PeriodSeconds (TimeFrame);
   time-=time%PerSec;

   if ((time!=LastTime) || (Symb!=LastSymb) || (TimeFrame!=LastTimeFrame) || (Exact!=LastExact))
     {
      Res=:: Bars (Symb,TimeFrame,time, UINT_MAX )- 1 ;
       if (Res< 0 ) Res= 0 ;

      LastTime = time;
      LastSymb = Symb;
      LastTimeFrame=TimeFrame;
      LastExact=Exact;
     }

   return (Res);
  }

Hızdaki kazanç yaklaşık bir buçuk katıdır.

Ve en hızlı seçenek gibi görünüyor. Doğru, son Tam parametre sahtedir ve kaldırılabilir. Ama bana gelince - bu yüzden gerekli değil. Şahsen, Exact = true kullanmanın gerekli olacağı görevlerim olmadı.

Ancak yine de birinin buna ihtiyacı varsa, CopyTime vazgeçilmezdir ve bu seçeneği @Alain Verleyen'den kullanmak daha iyidir.

Not: Son çağrıdan bu yana TF değişmediyse, PeriodSeconds işlevine yapılan gereksiz çağrıları da atladım. Kazançlar gerçekten zayıf - yüzde birkaç, ama yine de.

Ve bir açıklama daha: tasarım 

time-=time%PerSec;
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.
 
Nikolai Semko :

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.

Ve en hızlı seçenek gibi görünüyor. Doğru, son Tam parametre sahte. Ama bana gelince - bu yüzden gerekli değil.

Yoksa yanılıyor muyum?

Not: Son çağrıdan bu yana TF değişmediyse, PeriodSeconds işlevine yapılan gereksiz çağrıları da atladım. Kazançlar gerçekten zayıf - yüzde birkaç, ama yine de.

Kod ne kadar karmaşık yazılmış, anlamadım, o yüzden soracağım. Grafik tam gün değilse kod çalışır mı?

 
Aleksey Vyazmikin :

Kod ne kadar karmaşık yazılmış, anlamadım, o yüzden soracağım. Grafik tam gün değilse kod çalışır mı?

Sorunun özünü anlamadım. Farklı formüle edin.

Grafik, günün ilk saniyesi dışında her zaman tam bir gün değildir.

Ne TF'sinden bahsediyorsun? Gün?

Ve seni kontrol etmekten alıkoyan ne?

Kod benim değil, sadece basitleştirdim ve daha hızlı hale getirdim.

Bir önceki mesajımda PERIOD_W1 ve PERIOD_MN1 hesabına bir ekleme yapmıştım.

@Alain Verleyen dahil daha önceki tüm algoritmalarda anormal durumlar var.

Tam bir iBarShift MQL4 analogu oluşturabilirsiniz, ancak kod çok hacimli olacak ve bunda herhangi bir nokta görmüyorum.

 
Nikolai Semko :

Sorunun özünü anlamadım. Farklı formüle edin.

Grafik, günün ilk saniyesi dışında her zaman tam bir gün değildir.

Ne TF'sinden bahsediyorsun? Gün?

Ve seni kontrol etmekten alıkoyan ne?

Kod benim değil, sadece basitleştirdim ve daha hızlı hale getirdim.

Bir önceki mesajımda PERIOD_W1 ve PERIOD_MN1 hesabına bir ekleme yapmıştım.

@Alain Verleyen dahil daha önceki tüm algoritmalarda anormal durumlar var.

Tam bir iBarShift MQL4 analogu oluşturabilirsiniz, ancak kod çok hacimli olacak ve bunda herhangi bir nokta görmüyorum.

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 (ya da her saat tırnak olmasaydı daha az), bir M1 grafiğim var ve çubuğun önceki gün M15 boyunca 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ı?

12345678910...17
Yeni yorum
Neden: