sihirli sayı oluşturma - sayfa 3

 
//|                                                      This_EA.mq4 |
//|                      Copyright © 2010, MetaQuotes Software Corp. |
//|                                        http://www.metaquotes.net |
//+------------------------------------------------------------------+

#define This_EA   101
#define That_EA   102
#define Other_EA 103 // put this list of ea names to each of your ea's header, or...
                     // .. alternatively you can use a number suffix to your ea's file name 
                     // so it can be identified with --> StringSubstr(WindowExpertName(),x,y);
double This_EA_qty;
string magic_prefix;

int init()
  {

   if ( GlobalVariableGet (This_EA_qty) >= 0 .0 ){
             GlobalVariableSet ( "This_EA_qty" , This_EA_qty + 1 );
   }
   magic_prefix = StringConcatenate (This_EA, DoubleToStr(This_EA_qty, 0 ));

   return ( 0 );
  }

int deinit()
  {

      GlobalVariableSet ( "This_EA_qty" , This_EA_qty - 1 );
   
   return ( 0 );
  }

int start()
  {
       double lots, SL, TP; int slip, time_stamp ;
       bool BuyCondition;
   
       if ( BuyCondition == true )
      {
         time_stamp  = TimeCurrent (); 
         string magic_name = StringConcatenate (magic_prefix, time_stamp );
         int magic = StrToInteger(magic_name);
         
                                      // Integers range from -2147483648 to 2147483647
                                       // the resulting magic integer would most probably exceed that 
                                       // so we cut the number returned with TimeCurrent() short with 
                                      // MathMod(time_stamp,x) x being years, months not necessary for 
                                       // magic unique-ness. I don't include this calculation, 
                                      // since I'm short in time for testing it...
      
      
         OrderSend ( Symbol (), 0 , lots, Ask, slip, SL, TP, NULL , magic, 0 , CLR_NONE );
      }
//----
   return ( 0 );
  }
//+------------------------------------------------------------------+
düşündüğümden biraz daha uzun sürüyor...
edit : GVget koşulu != -1.0 ila >= 0.0; Düzenle
 
cameofx :
[...] düşündüğümden biraz daha uzun sürüyor ...

Bu, daha önce bahsettiğim bir önceki konunun giderek yeniden bir özeti haline geliyor (punto için özür dilerim): https://www.mql5.com/en/forum/120034 . Global değişkenleri içeren herhangi bir şey, yedekleme ve olağanüstü durum kurtarma ile ilgili sorunları ortaya çıkarır. Alım satımın yeni bir sunucuya aceleyle taşınması gerekiyorsa, o zaman ya gvariables.dat'ın yakın zamanda bir yedeğinin mevcut olması gerekir ya da kullanıcının global değişkenleri manuel olarak yeniden oluşturabilecek bir konumda olması gerekir.

Kodunuzu yakından incelemedim, ancak EA'nın birden fazla kopyası varsa ve MT4 yeniden başlatılırsa ne olacağından da emin değilim. Kod, EA'ların orijinal olarak manuel olarak yüklendikleri sırayla otomatik olarak yeniden yükleneceğini varsayıyor gibi görünüyor. Başka bir deyişle, EA'nın birden çok kopyası, yeniden başlatmalarda farklı This_EA_qty değerleri alabilir ve bu durumda, MT4 listesindeki geçmiş siparişlerini nasıl doğru bir şekilde belirlediklerini göremiyorum. Ama bu konuda yanılıyor olabilirim.

 
cameofx :
düşündüğümden biraz daha uzun sürüyor...
edit : GVget koşulu != -1.0 ila >= 0.0
 // TimeCurrent() in seconds since 1970 would most probably exceed that 

TimeCurrent(), 32 bitlik bir tamsayı döndürür. Veri zamanı türü, int türü için bir takma addır, int ayrıca 32 bitlik bir tamsayıdır.


Kodunuzda anlamadığım diğer şey, neden her açılan ticaret için farklı bir MN kullanıyorsunuz? Bu, MN'lerin ne anlama geldiğinin tam tersidir. Bir MN fikri, tüm işlemleri belirli bir EA'ya göre basitçe MN'ye bakarak tanımlayabilmenizdir. MN'nin rastgele bölümünün nedeni nedir? EA'nızdaki kod, bu EA'nın tüm açık işlemlerini kapatacak veya bu EA'nın tüm duraklarını takip edecek şekilde nasıl görünür?
 
Doğru anladıysam - yanlışlıkla aynı kimliğe sahip 2 farklı uzmana çözümünüz, tüm uzman kimliklerini her uzmanın başlığına koymaktır. Bu tam bir baş belası... O kısmı bir içerme dosyasına koysanız bile, yaptığınız her yeni uzman için tüm uzmanları yeniden derlemeniz gerekecek.

Kalıcılık sorunu hala orada. Bir terminal yeniden başlatıldıktan veya tamamen farklı bir terminale geçtikten sonra bunun nasıl düzgün çalışacağını bilmiyorum...
 
jjc :

Bu, daha önce bahsettiğim bir önceki konunun giderek yeniden bir özeti haline geliyor (punto için özür dilerim): https://www.mql5.com/en/forum/120034 . Global değişkenleri içeren herhangi bir şey, yedekleme ve olağanüstü durum kurtarma ile ilgili sorunları ortaya çıkarır. Alım satımın yeni bir sunucuya aceleyle taşınması gerekiyorsa, o zaman ya gvariables.dat'ın yakın zamanda bir yedeğinin mevcut olması gerekir ya da kullanıcının global değişkenleri manuel olarak yeniden oluşturabilecek bir konumda olması gerekir.

Kodunuzu yakından incelemedim, ancak EA'nın birden fazla kopyası varsa ve MT4 yeniden başlatılırsa ne olacağından da emin değilim. Kod, EA'ların orijinal olarak manuel olarak yüklendikleri sırayla otomatik olarak yeniden yükleneceğini varsayıyor gibi görünüyor. Başka bir deyişle, EA'nın birden çok kopyası, yeniden başlatmalarda farklı This_EA_qty değerleri alabilir ve bu durumda, MT4 listesindeki geçmiş siparişlerini nasıl doğru bir şekilde belirlediklerini göremiyorum. Ama bu konuda yanılıyor olabilirim.

Bunlar beklediğim türden geri bildirimler... teşekkür ederim gordon, 7bit & jjc..

cevaplarınız biraz düşünmeye ihtiyaç duyuyor .. ama hızlı cevap vermek için:

- This_EA uzmanı başka bir çizelgeye zaten bir kez eklenmişse, magic_number o zaman şu değere sahip olur: 101-1-time_stamp (açıklık için kısa çizgi)

- içerdiği bilgiler 101 olacaktır - uzman kimliği; 1 - Şu ana kadar faaliyet gösteren This_EA miktarı; time_stamp - OrderSend zamanı

- daha sonra StringSubStr ile tarayabilir ve belirli bir siparişin This_EA tarafından eklenmiş 1 başka This_EA varken açıldığını bilebiliriz.

 
7bit :

TimeCurrent(), 32 bitlik bir tamsayı döndürür. Veri zamanı türü, int türü için bir takma addır, int ayrıca 32 bitlik bir tamsayıdır.


Kodunuzda anlamadığım diğer şey, neden her açılan ticaret için farklı bir MN kullanıyorsunuz? Bu, MN'lerin ne anlama geldiğinin tam tersidir. Bir MN fikri, tüm işlemleri belirli bir EA'ya göre sadece MN'ye bakarak tanımlayabilmenizdir. MN'nin rastgele bölümünün nedeni nedir? EA'nızdaki kod, bu EA'nın tüm açık işlemlerini kapatacak veya bu EA'nın tüm duraklarını takip edecek şekilde nasıl görünür?

Üzgünüm, demek istediğim, sonuçta ortaya çıkan int magic_name'nin bu tahsisi aşacağıydı. Yorumu buna göre kodda taşıyacağım.

Algılarımızı eşitlemek için. Bu 'otomatik' sihirli_sayı için bu gereksinimleri öneriyorum. MN aşağıdakilere sahip olacaktır:

- Hangi EA ile - söz konusu MN ile bu özel siparişin - açık olduğunu belirleyebilirsiniz.

- Bu tekniği içeren bir EA - çok sayıda (1'den fazla) eklenmişse, bu EA'lar 1 saniyelik bir sürenin dışında aynı anda emirleri açarsa aynı sihirli sayıyı üretmez

- böylece sipariş işlemede çelişki olmaz, ancak aynı zamanda MN'nin menşei hala izlenebilir

- Listem eksikse lütfen ekleyiniz...

 
cameofx :
- içerdiği bilgiler 101 olacaktır - uzman kimliği; 1 - Şu ana kadar faaliyet gösteren This_EA miktarı; time_stamp - OrderSend zamanı

- daha sonra StringSubStr ile tarayabilir ve belirli bir siparişin This_EA tarafından eklenmiş 1 başka This_EA varken açıldığını bilebiliriz.

Ama MN'deki zaman bölümü ne için? Neden sadece EA numaralarını tek başına kullanmıyorsunuz? ve substr kullanmıyor musunuz? substr kullanımı, int'nin bir dizgeye dönüştürülmesini, ardından bazı dizge işlemleri ve bir dizge karşılaştırmasını gerektirir, MN'nin zaman kısmı atılır, çünkü asla gerekli değildir. Tamsayılarla dize işlemleri genellikle amatörce görünme eğilimindedir, çünkü çoğu durumda bilgileri 32 bitlik kelimenin farklı bitlerinde kodlayarak daha iyi çözülebilirse ve bunları işlemek veya kontrol etmek için bit düzeyinde işlemler kullanılırsa, bu çok daha hızlı ve daha zarif olacaktır.

Neden mn için sadece bir (EA-instance-unique) int değeri kullanmıyorsunuz ve ya tam sayıyı ya da onun belirli bitlerini karşılaştırmak için basit tamsayı karşılaştırmasını kullanmıyorsunuz?

Örneğin, farklı işlem türlerini tanımlamak için ilk 28 bitin ID ve son dört bitin 0..15'ten bir sayı olmasına izin verin (örneğin, 3 farklı türde emir açabiliyorsa: başlangıç, seviye1, seviye2 ve riskten korunma)

ID = hash & 0xFFFFFFF0    // this has the 4 low bits always zero


// generate the mn for level 1 trades
MN = (ID + 1 );
OrderSend (..., MN, "level 1" );


// generate the mn for hedge trades
MN = (ID + 15 );
OrderSend (..., MN, "hedge the whole mess" );


// this strategy may not make any sense, only to illustrate the code:
// close the hedge trades and trail the stops of all levels
for (...){
   if (OrderMagicNumber() & 0xFFFFFFF0 == ID){   // this trade belongs to us
       if (OrderMagicNumber() & 0x0000000F == 15 ){ // this is a hedge trade
         OrderClose(...)
      } else { // this is one of the other levels
         Trail(OrderTicket());
      }
   }
}

// or even easier:
MN = (ID + 15 ); // all our hedge trades have this MN
for (...){
   if (OrderMagicNumber() == MN){
      OrderClose(...)
   }
}
 
gordon :
Doğru anladıysam - yanlışlıkla aynı kimliğe sahip 2 farklı uzmana çözümünüz, tüm uzman kimliklerini her uzmanın başlığına koymaktır. Bu tam bir baş belası... O kısmı bir içerme dosyasına koysanız bile, yaptığınız her yeni uzman için tüm uzmanları yeniden derlemeniz gerekecek.

Kalıcılık sorunu hala orada. Bir terminal yeniden başlatıldıktan veya tamamen farklı bir terminale geçtikten sonra bunun nasıl düzgün çalışacağını bilmiyorum...

Hayır, yapmadınız :) lütfen WindowExpertName() ile ilgili koddaki yorumları okuyun.

Uzmandan çağrılırsa, ".mq4" veya ".ex4" olmadan uzman/komut dosyası/gösterge dosya adını alır, herhangi bir ekleme yapmanız gerekmez, yalnızca EA'larınızı buna göre adlandırın.

Not: spam içerikli cevap için özür dilerim :)

 
7bit :

Ama MN'deki zaman bölümü ne için? Neden sadece EA numaralarını tek başına kullanmıyorsunuz? ve substr kullanmıyor musunuz? substr kullanımı, int'nin bir dizgeye dönüştürülmesini, ardından bazı dizge işlemleri ve bir dizge karşılaştırmasını gerektirir, MN'nin zaman kısmı atılır çünkü asla gerekli değildir. Tamsayılarla dize işlemleri genellikle amatörce görünme eğilimindedir, çünkü çoğu durumda bilgileri 32 bitlik kelimenin farklı bitlerinde kodlayarak daha iyi çözülebilirse ve bunları işlemek veya kontrol etmek için bit düzeyinde işlemler kullanılırsa, bu çok daha hızlı ve daha zarif olacaktır.

Neden mn için sadece bir (EA-instance-unique) int değeri kullanmıyorsunuz ve ya tam sayıyı ya da onun belirli bitlerini karşılaştırmak için basit tamsayı karşılaştırmasını kullanmıyorsunuz?

Örneğin, farklı işlem türlerini tanımlamak için ilk 28 bitin ID ve son dört bitin 0..15'ten bir sayı olmasına izin verin (örneğin, 3 farklı türde emir açabiliyorsa: başlangıç, seviye1, seviye2 ve riskten korunma)


hmm... Zaman bölümünü kullanıyorum çünkü bir EA tarafından açılan her sipariş için MN'nin aynı anda farklı grafiklerde aynı EA ile açılan diğer siparişler açısından benzersiz olması gerektiğini düşündüm.

öncül şöyle olurdu: Bir EA aynı sihirli sayı ile aynı anda iki (daha fazla) sipariş açarsa. aynı MN'ye sahip olamazlar, aksi takdirde Sipariş işlemede çakışabilir ve veya

Sipariş tanımlama... belki yanlışlıkla bunu OrderTicket kapma ile karıştırdım (ya da değil?).

- stratejiyi MN'ye dahil etmek doğal olarak bir sonraki adım olacaktır

- Görüyorum ki yeteneğin beni ışık yılı aşmış :)). Henüz işlemleri optimize etme yeteneğim yok, bu yüzden bunu yayınladım.. Artık bitsel işlemlerle kontrol etmenin daha hızlı olacağını biliyorum.

teşekkür ederim. Daha sonra nasıl yapılır açıklamasını sormam gerekebilir :)))

 
cameofx :

hmm... Zaman bölümünü kullanıyorum çünkü bir EA tarafından açılan her sipariş için MN'nin diğer siparişler açısından benzersiz olması gerektiğini düşündüm.

Hayır, istediğin her şey olabilirler. tıpkı yorum gibi. onları bir tür sayısal yorum olarak görün. Normal MT4 kullanıcı arayüzü ile açılan tüm manuel işlemler sihirli sayı 0'a sahip olacaktır, böylece örneğin tüm siparişleri döngüye alabilir ve tüm EA işlemlerine dokunmadan tüm manuel işlemleri ve siparişleri kapatabilir/silebilirsiniz.

Tüm EA'larım (EA-adı + sembol + zaman dilimi) için benzersiz kendi numaralarını yaratırlar, bu yüzden bu numarayı oluşturmak için iyi ve kolay bir karma işlevi bulmak için çok çaba harcadım. Karma bile o kadar iyi ki, alt sayılara yer açmak için bu karmanın son birkaç bitini kolayca kesebilirim (eğer buna ihtiyacım olursa, ancak buna nadiren ihtiyacım olur) ve yine de çarpışmalara karşı oldukça güvenli olurdu.

Ancak EA'larımın çoğu, hash'i doğrudan kullanır ve bir alt numaralandırmaya sahip değildir, çünkü yalnızca bir tür ticaretleri vardır ve tüm ticaretlerine aynı şekilde davranırlar.

Yalnızca belirli bir siparişi benzersiz bir şekilde tanımlamak için her zaman bilet numarası vardır.

Neden: