Hatalar, hatalar, sorular - sayfa 616

 

Geliştiricilere soru:

test cihazında yapı alanını almak neden imkansız

MqlTicaretSonucu   fiyat ; // İşlem fiyatı komisyoncu tarafından onaylandı mı? 0 verir.

Demo iyi çalışıyor.

 
x100intraday :

Zaman çerçevelerinin liste yapısı ile nesne görünürlük bayrakları arasında herhangi bir ilişki var mı (sonuçta listelerin uzunluğu bile farklı: 22'ye 23)? Genel olarak, bayrakları manuel olarak listeleyip toplamak yerine, belirli sınırlarla bir döngüde zaman dilimlerindeki nesnelerin görünürlüğünü etkili ve kompakt bir şekilde atamak için soruyorum. Rastgele bir zaman dilimi alınırsa, üzerine bir grafik nesnesi inşa edilirse ve mevcut olandan daha eski olmayan tüm zaman dilimlerinde (yani, inşa edildiği zamandan) görünürlüğünü sağlamak için hangi mantık kullanılmalıdır? )? Algoritma evrensel olmalı ve belirli bir durum için değil. İndeks-endeks korelasyonu ile - zaten uçuşta, burada bir indeks yazışması bile yok. Görünürlük sabitleri durumunda bir dizeyle çalışmanın imkansızlığı nedeniyle, ad dizelerini ayrıştırma ve karşılaştırma - yine yayılma alanında. Buraya kadar karmaşık, muğlak ve çok çarpık bir uygulama akla geliyor.

Tabii ki, bir ilişki var, ancak o kadar örtük ki <visibility_flag>=F(<timeframe>) yazmak sadece şu şekilde çalışacak:

 int PeriodToTimeframeFlag( ENUM_TIMEFRAMES period)
  {
   flags= 0 ;
   static ENUM_TIMEFRAMES _p_int[]={ PERIOD_M1 , PERIOD_M2 , PERIOD_M3 , PERIOD_M4 , PERIOD_M5 , PERIOD_M6 ,
                                     PERIOD_M10 , PERIOD_M12 , PERIOD_M15 , PERIOD_M20 , PERIOD_M30 ,
                                     PERIOD_H1 , PERIOD_H2 , PERIOD_H3 , PERIOD_H4 , PERIOD_H6 , PERIOD_H8 , PERIOD_H12 ,
                                     PERIOD_D1 , PERIOD_W1 , PERIOD_MN1 };
//--- cycle for all timeframes
   for ( int i= 0 ;i< ArraySize (_p_int);i++)
       if (period==_p_int[i])
        {
         //--- at the same time generate the flag of the working timeframe
         flags=(( int ) 1 )<<i;
         break ;
        }
   return (flags);
  }
 

x100intraday :

Rastgele bir zaman dilimi alınırsa, üzerine bir grafik nesnesi inşa edilirse ve mevcut olandan daha eski olmayan tüm zaman dilimlerinde (yani, inşa edildiği zamandan) görünürlüğünü sağlamak için hangi mantık kullanılmalıdır? )?

gerekirse, dama yapmayın)

 ENUM_TIMEFRAMES TF[ 21 ]={ PERIOD_M1 , PERIOD_M2 , PERIOD_M3 , PERIOD_M4 , PERIOD_M5 , PERIOD_M6 , PERIOD_M10 ,
                     PERIOD_M12 , PERIOD_M15 , PERIOD_M20 , PERIOD_M30 , PERIOD_H1 , PERIOD_H2 , PERIOD_H3 ,
                     PERIOD_H4 , PERIOD_H6 , PERIOD_H8 , PERIOD_H12 , PERIOD_D1 , PERIOD_W1 , PERIOD_MN1 };

int Visibility[ 21 ]={ 1 , 3 , 7 , 15 , 31 , 63 , 127 , 255 , 511 , 1023 , 2047 , 4095 , 8191 ,
             16383 , 32767 , 65535 , 131071 , 262143 , 524287 , 1048575 , 2097151 };

TF[i]'yi düşünün, Görünürlüğü [i] ayarlayın..

veya görünürlük=(int)(MathPow(2,i+1)-1);

 
Swan :

Gerekirse, dama yapmayın)

TF[i]'yi düşünün, Görünürlüğü [i] ayarlayın..

veya görünürlük=(int)(MathPow(2,i+1)-1);

Görünürlük formülü için teşekkürler - belki bir yere uyarlarım. Zaman dilimlerindeki değerlerden bunun bir şeyin derecesi olduğu açıktı, ancak formülü kendi başıma geri yüklemeye çalışmadım.

-1'e ihtiyacınız var mı? Genel olarak, Görünürlük[], bence, yanlış değerlerle doludur, ancak gerçekte -1 olmadan her yerde olmalıdır, yani: 1, 2, 4, 8, 16 ...

 
uncleVic :

Tabii ki, bir ilişki var, ancak o kadar örtük ki <visibility_flag>=F(<timeframe>) yazmak sadece şu şekilde çalışacak:


Teşekkür ederim. Eksik olan değişimin kendisi dışında yapmaya çalıştığım şey tam olarak buydu.

Ve sonunda, aslında regresyon döngüsünün her yinelemesinde bayrak değerlerini _p_int zaman çerçevesi dizisine göre hesaplama konusuna döndüm (sonuçta, bayrak bayrak bir şeylerin eklenmesi gerekecek ) ve yalnızca bir geçerli olanda değil. Pekala, mevcut TF'deki görünürlük bayrağının değerini bir kaydırma ile elde ettik ve sonra her dönüşte i - bir yerde bir şeyler değişmeli ... Orada, ya üs formülü uygulanmalı ya da aynı kaydırma ilkesi kullanılmalıdır. . Nasıl olduğunu henüz çözemedim...

...evet olsa da, bu bir TF argümanı olan bir fonksiyondur - onu bir döngü içinde bükmeye çalışacağım...

Ancak, yine değil. Şimdi açıklayacağım. Örnekte, statik ENUM_TIMEFRAMES _p_int[] 21 öğeye ayarlanmıştır, ancak! Şunu isterim: Zaten benzer bir dizim var, ancak isteğe bağlı uzunlukta olabilir. Bu, üzerine bir şeyin inşa edileceği zaman dilimlerini içeren bir dizidir, ancak aynı zamanda tüm alt zaman dilimlerinde de görünürlükleri olmalıdır ve bunlarla ayrı ayrı veya mevcut olanlardan ek olarak tek bir dizi doldurulmamalıdır. Yani, burada, mevcut ve tüm alt zaman dilimlerinden bayrakları hesaplamak ve özetlemek için regresyon döngüsünde mevcut TF'den dans ederek anında ihtiyaçtan bahsediyorum. İşin püf noktası, bir şeyin önceden tanımlanmış tam bir değer dizisini (en azından zaman dilimleri, en azından görünürlük bayrakları) oluşturmak ve onları yünlemek değil, her dönüşte yalnızca tamamlanmamış önceden tanımlanmış zaman dilimleri dizisi için zihinde hesaplamaktır. İş.

Ben çözerken gideceğim, takılırsam sorarım.

 

(int)( MathPow (2,i+1)-1) veya ((int)1)<<i ... kullanmak için neden acelem yok ... döngü ve çalıştırın ... Ama üs durumunda olduğu gibi, kaydırma durumunda da - her zaman güvenilir mi? Aksi takdirde, geliştiriciler yeni zaman dilimleri eklerse, tüm mantık yokuş aşağı gitmeyecek mi? Hazırlıksız - bir kayma içeren örnekte, mevcut dönemin önceden tanımlanmış olanla çakışmasını bekliyoruz:

 if (period==_p_int[i])
bu nedenle, gerçek bir durumda, teorik olarak tamamlanmış bir diziden bazı zaman dilimleri atlansa veya bu dizi geliştiriciler tarafından genişletilse bile, mantık kaymamalıdır. Ancak saf matematiğe güvenirsek ve yeni zaman çerçevelerinin olası yokluğuna veya varlığına bakmadan döngüyü sınırdan sınıra formüle göre basitçe sürersek, o zaman er ya da geç, bir sonraki yapıda, elbette , bir eğri...
 
x100intraday :

(int)(MathPow(2,i+1)-1) veya ((int)1)<<i... kullanmak için neden acelem yok? döngüye girin ve çalıştırın... Ancak hem üs alma durumunda hem de kaydırma durumunda - her zaman güvenilir midir? Aksi takdirde, geliştiriciler yeni zaman dilimleri eklerse, tüm mantık yokuş aşağı gitmeyecek mi? Hazırlıksız - bir kayma içeren örnekte, mevcut dönemin önceden tanımlanmış olanla çakışmasını bekliyoruz:

bu nedenle, gerçek bir durumda, teorik olarak tamamlanmış bir diziden bazı zaman dilimleri atlansa veya bu dizi geliştiriciler tarafından genişletilse bile, mantık kaymamalıdır. Ancak saf matematiğe güvenirsek ve yeni zaman çerçevelerinin olası yokluğuna veya varlığına bakmadan döngüyü sınırdan sınıra formüle göre basitçe sürersek, o zaman er ya da geç, bir sonraki yapıda, elbette , bir eğri...

Korkular çok iyi kurulmuş. Yukarıdaki kod, yalnızca görünürlük bayrağı kümesinin aslında bir makro olduğunu doğrular.

Üzerinde çalışmak daha iyi olurdu:

 int result= 0 ;
//---
switch (period)
  {
   case PERIOD_M1 : result= OBJ_PERIOD_M1 ; break ;
   case PERIOD_M2 : result= OBJ_PERIOD_M2 ; break ;
   case PERIOD_M3 : result= OBJ_PERIOD_M3 ; break ;
   case PERIOD_M4 : result= OBJ_PERIOD_M4 ; break ;
   case PERIOD_M5 : result= OBJ_PERIOD_M5 ; break ;

//--- и так далее

   default : print( "Что-то новенькое" );
  }

Документация по MQL5: Стандартные константы, перечисления и структуры / Константы объектов / Видимость объектов
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы объектов / Видимость объектов
  • www.mql5.com
Стандартные константы, перечисления и структуры / Константы объектов / Видимость объектов - Документация по MQL5
 
x100intraday :

Görünürlük formülü için teşekkürler - belki bir yere uyarlarım. Zaman dilimlerindeki değerlerden bunun bir şeyin derecesi olduğu açıktı, ancak formülü kendi başıma geri yüklemeye çalışmadım.

-1'e ihtiyacınız var mı? Genel olarak, Görünürlük[], bence, yanlış değerlerle doludur, ancak gerçekte -1 olmadan her yerde olmalıdır, yani: 1, 2, 4, 8, 16 ...

1,2,4 vb. - nesnenin bir TF'de görünürlüğü. =MathPow(2,i);

mevcut ve daha küçük 1, 1+2, 1+2+4, 1+2+4+8, vb., =MathPow(2,i+1)-1;

İkili daha iyi..

amcaVic :

Korkular çok iyi kurulmuş. Yukarıdaki kod, yalnızca görünürlük bayrağı kümesinin aslında bir makro olduğunu doğrular.

Üzerinde çalışmak daha iyi olurdu:

Prensipte aynı şey. TF listesinde değişiklik yaparken kodu düzenlemeniz gerekecektir.

Herhangi bir evrensel çözüm hayal edemiyorum ve hala şüpheliyim) olası değişiklikleri öngörmek teorik olarak imkansız.


x100gün içi :

Ancak, yine değil. Şimdi açıklayacağım. Örnekte, statik ENUM_TIMEFRAMES _p_int[] 21 öğeye ayarlanmıştır, ancak! Şunu isterim: Zaten benzer bir dizim var, ancak isteğe bağlı uzunlukta olabilir. Bu, üzerine bir şeyin inşa edileceği zaman dilimlerini içeren bir dizidir, ancak aynı zamanda tüm alt zaman dilimlerinde de görünürlükleri olmalıdır ve bunlarla ayrı ayrı veya mevcut olanlardan ek olarak tek bir dizi doldurulmamalıdır. Yani, burada, mevcut ve tüm alt zaman dilimlerinden bayrakları hesaplamak ve özetlemek için regresyon döngüsünde mevcut TF'den dans ederek anında ihtiyaçtan bahsediyorum. İşin püf noktası, bir şeyin önceden tanımlanmış tam bir değer dizisini (en azından zaman dilimleri, en azından görünürlük bayrakları) oluşturmak ve onları yünlemek değil, her dönüşte yalnızca tamamlanmamış önceden tanımlanmış zaman dilimleri dizisi için zihinde hesaplamaktır. İş.

hayır, çalışmayacak. Yazışma tf ve görünürlük ayarlanmalıdır. Veya iki karşılık gelen dizi veya anahtarlı bir değişken.

+ gerekli olan TF'leri içeren bir dizi, + init, tüm bu verileri kullanarak kullanılan her TF için nesnenin görünürlüğünü hesaplar. Böyle bir şey..)

 

Bütün kafamı kırdım, sorun ne anlamadım?

 double VirtualSL;
MqlTick tick;
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit ()
  {
   VirtualSL= 0.0 ;
   return ( 0 );
  }
//+------------------------------------------------------------------+
//| Expert tick function                                             |
//+------------------------------------------------------------------+
void OnTick ()
  {
   trail();
  }
//+------------------------------------------------------------------+
void trail()
  {
   double stopcal;

   SymbolInfoTick ( _Symbol ,tick);
   stopcal=tick.bid;

//   if((VirtualSL!=0.0 && stopcal>VirtualSL) || VirtualSL==0.0) // так все работает

   if (VirtualSL== 0.0 || (VirtualSL!= 0.0 && stopcal>VirtualSL)) // так не хочет работать
     {
      VirtualSL=stopcal;
       Print ( "use Ok!" );
     }
   if (VirtualSL<stopcal) Print ( "o_O ((((( stopcal = " ,stopcal, "   VirtualSL = " ,VirtualSL);
  }
//+------------------------------------------------------------------+

2011.12.29 01:16:07 çekirdek 1 2011.09.26 02:54:13 o_O ((((( stopcal = 1.54508 VirtualSL = 1.53378)

2011.12.29 01:16:07 çekirdek 1 2011.09.26 02:54:12 o_O ((((( stopcal = 1.54507 VirtualSL = 1.53378)

2011.12.29 01:16:07 çekirdek 1 2011.09.26 02:54:12 o_O ((((( stopcal = 1.54508 VirtualSL = 1.53378)


 
her.human :

Bütün kafamı kırdım, sorun ne anlamadım?

Derleyici optimize edicide hata. Gönderdiğiniz için teşekkürler, düzelteceğiz.

Bu tasarımda bir hata oluşuyor

 if (VirtualSL== 0.0 || (VirtualSL!= 0.0 && stopcal>VirtualSL))
if (VirtualSL<stopcal)
İlk if durumunda, VirtualSL!= 0.0 ikinci kısımdan çıkarılabilir. koşulun ilk bölümünü kontrol ettikten sonra, bu ifade her zaman doğrudur. Bu durumda, optimize edici hatası kaybolacaktır.


Düzeltildi, düzeltme sonraki derlemeye dahil edilecek.