Hatalar, hatalar, sorular - sayfa 2377

Yeni yorum
 
Slava :
Evet. OnInit'ten Herhangi Bir Baskı

Teşekkür ederim. Acaba kazara fark etmeseydim, bunu öğrenmenin nasıl mümkün olabileceğini merak ediyorum ...


ZY, bu sayacı yalnızca yerel Temsilciler için bırakırdı. Bulutta, günlüğü bu şekilde kolayca spam yapabilirsiniz.

 
fxsaber :

Teşekkür ederim. Acaba kazara fark etmeseydim, bunu öğrenmenin nasıl mümkün olabileceğini merak ediyorum ...


ZY, bu sayacı yalnızca yerel Temsilciler için bırakırdı. Bulutta, günlüğü bu şekilde kolayca spam yapabilirsiniz.

Bulutta mevcut değil. çünkü gerek yok
 
Slava :

Genetiği çalıştırdığınızda, özel bir kritere göre optimize ediyor musunuz?

Sunulan günlüklere bakılırsa, OnTester her durumda 0 döndürdü

Genelde kendi kriterlerime göre optimizasyon yapıyorum ama burada normal kriterlere göre denedim. Sonuç benzer.

OnTester 0 döndürür, bu nedenle sonuçlardaki sıfırlar anlaşılabilir. Soru, neden genel bir çalıştırmada (optimizasyon) "0" döndürüyor ve "sıfır sonuçlardan" (aynı parametrelerle) tek bir çalıştırmada normal bir sonuç, grafik vb. üretiyor mu? Onlar. "Kaba Kuvvet"te bir şey çalışmıyor ve aynı zamanda genetik iyi çalışıyor. Başka düşünce/fikir var mı?

 
Kuzmich :

Başka düşünce/fikir var mı?

Optimizasyon geçişinin tüm bilgilerini benzer şekilde çekin

Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum

MT5. STRATEJİ TEST CİHAZI. Test ve optimizasyon sonuçları arasındaki tutarsızlık.

fxsaber , 2017.08.22 11:06

Bu satırları EA'ya ekleyin

 #define REPORT_TESTER // В тестере будут автоматически записываться отчеты
#include <Report.mqh>

ve Optimizasyon'u çalıştırın. Ardından, eşleşmeyen tek çalıştırmayı çalıştırın.

Ardından, Optimizasyon ve Tek Geçişten ilgili geçişlerin kaydedilmiş iki raporunu karşılaştırın.

Bu iki raporu karşılaştırmanın sonucu, nedenleri hızla ortaya çıkaracaktır.

 
Socket* işleviyle tanışmamızın bir parçası olarak, mevcut uygulamayla ilgili bir dizi soru ortaya çıktı.
Amaç yapılanları mümkün olduğunca iyileştirmek, geliştiricilerin olası eleştirilerden rahatsız olmamalarını rica ediyorum.



1. Soket Okuma işlevleri için "arayüzlerde" bu kadar güçlü farklılıkların nedenleri açık değildir:
a) Şifreli bir bağlantı için, okuma için iki fonksiyon ve şifrelenmemiş bir bağlantı için bir fonksiyon vardır.
b) SocketRead'de timeout_ms'yi açıkça belirtmelisiniz, ancak SocketTlsRead ve SocketTlsReadAvailable'da böyle bir parametre yoktur (ayrı bir SocketTimeouts işlevi tarafından ayarlanır).
 int   SocketTlsRead( int socket, uchar & buffer[], int buffer_maxlen);
int   SocketTlsReadAvailable( int socket, uchar & buffer[], int buffer_maxlen);

int  SocketRead(int socket, uchar& buffer[], int buffer_maxlen, uint timeout_ms);


2. SocketIsReadable işlevinin adının, gerçekte ne yaptığıyla hiçbir ilgisi yoktur:

 bool   SocketIsWritable( const int   socket); // Return true if writing is possible, otherwise false.
uint    SocketIsReadable ( const int   socket); // Number of bytes that can be calculated. In case of an error, 0 is returned.
bool   SocketIsConnected( const int socket); // New function without description. May be, it returns true if connection is not closed.

Aslında SocketIsReadable, Ws2_32.dll'deki FIONREAD bayrağıyla ioctlsocket() işlevinin eşdeğeridir.


3. Şifrelenmemiş bir bağlantı üzerinden Socket* işlevini kullanan bir kullanıcı, veri aktarımından sonra sunucu bağlantıyı kesmezse, sunucudan minimum gecikmeyle nasıl yanıt alabilir?

- SocketIsReadable işlevi, açıkça zaman gecikmesi kullanmadan (örn. Uyku olmadan) 0 döndürür.
- SocketRead işlevi ne kadar okuyacağını bilmiyor, buffer_maxlen değerini bir kenar boşluğu ile belirteceksiniz - timeout_ms kadar zaman aşımını beklemeniz gerekecek

Evet, şu şekilde yapılır:

- SocketRead'de 1 bayt veri bekliyoruz;
- daha sonra SocketIsReadable kullanarak tüm yanıtın boyutunu öğrenin;
- SocketRead'de eksik uzunluğu okuyun;
- dizileri kopyalayarak elde edilen sonuçları tek bir bütün halinde birleştirmek:

 #define PRINT(x) Print ( #x, ": " , string (x))
                
void OnStart () {
   string domain = "www.mql5.com" ;
   int port = 80 ;
 
   string request = "GET / HTTP/1.1\r\nHost: " + domain + "\r\n\r\n" ;
   char req[];
   
   int socket = SocketCreate();
   PRINT(SocketConnect(socket, domain, port, 5000 ));
   int len= StringToCharArray (request,req)- 1 ;
   PRINT(SocketSend(socket,req,len));
   
   
   
   uchar resp[];
   uchar result[];
   
   int resp_result;
   uint resp_len;
   int start_write;
   
   
   resp_len = 1 ;
   resp_result = SocketRead(socket, resp, resp_len, 5000 );
   if (resp_result <= 0 ){
      PRINT( GetLastError ());
       return ;
   }
   start_write = ArraySize (result);
   ArrayResize (result, start_write + resp_result);
   ArrayCopy (result, resp, start_write);
   
   
   resp_len = SocketIsReadable(socket);
   resp_result = SocketRead(socket, resp, resp_len, 5000 );
   if (resp_result <= 0 ){
      PRINT( GetLastError ());
       return ;
   }
   start_write = ArraySize (result);
   ArrayResize (result, start_write + resp_result);
   ArrayCopy (result, resp, start_write);
   
   
   PRINT( CharArrayToString (result));
};

Bu çok fazla kod değil mi?


4. SocketIsReadable yanlış bilgi döndürür.
İnterneti kapatın ve yukarıdaki kodu çalıştırın.
Sonuç olarak, SocketIsReadable, aklı başında bir 1 değeri döndürür. Mucizeler.


Socket* ile ilgili toplam soru ve sorunların yaklaşık üçte birini tanımlamak mümkündü.
Ne yazık ki, her şeyi kontrol etmek, tanımlamak, iki kez kontrol etmek çok zaman alıyor ... (yani devamının olmayacağı bir gerçek değil)

Genel izlenim: ya her şey büyük bir aceleyle yapıldı ya da Socket * işlevi küçük bir geliştirici tarafından hayata geçirildi.
Her durumda, mevcut çözüm çok kaba ve soket kullanımına oldukça dar bir yaklaşımı içeriyor.

 
MQL5\Include\Math\AlgLib\dataanalysis.mqh - CLinReg:: LRLine 1 milyon veya daha fazla değer için çalışmıyor mu?
 
Kuzmich :

Genelde kendi kriterlerime göre optimizasyon yapıyorum ama burada normal kriterlere göre denedim. Sonuç benzer.

OnTester 0 döndürür, bu nedenle sonuçlardaki sıfırlar anlaşılabilir. Soru, neden genel bir çalıştırmada (optimizasyon) "0" döndürüyor ve "sıfır sonuçlardan" (aynı parametrelerle) tek bir çalıştırmada normal bir sonuç, grafik vb. üretiyor mu? Onlar. "Kaba Kuvvet"te bir şey çalışmıyor ve aynı zamanda genetik iyi çalışıyor. Başka düşünce/fikir var mı?

Danışmanı (PM'de ex5) ve optimizasyon koşullarını paylaşabilir misiniz?

Bahsettiğiniz sorunu yeniden oluşturmak istiyoruz.

Araştırmadan sonra uzman kalıcı olarak silinecek

 
Slava :

Danışmanı (PM'de ex5) ve optimizasyon koşullarını paylaşabilir misiniz?

Bahsettiğiniz sorunu yeniden oluşturmak istiyoruz.

Araştırmadan sonra uzman kalıcı olarak silinecek

Ve danışmanım bak? Benim de benzer bir sorunum var - kâr düşünülmüyor, bu nedenle optimizasyon çalışmıyor.
 
Slava :

Danışmanı (PM'de ex5) ve optimizasyon koşullarını paylaşabilir misiniz?

Bahsettiğiniz sorunu yeniden oluşturmak istiyoruz.

Araştırmadan sonra uzman kalıcı olarak silinecek

Özelden cevaplandı.

 
Sergey Dzyublik :
Socket* işleviyle tanışmamızın bir parçası olarak, mevcut uygulamayla ilgili bir dizi soru ortaya çıktı.
Amaç yapılanları mümkün olduğunca iyileştirmek, geliştiricilerin olası eleştirilerden rahatsız olmamalarını rica ediyorum.



1. Soket Okuma işlevleri için "arayüzlerde" bu kadar güçlü farklılıkların nedenleri açık değildir:
a) Şifreli bir bağlantı için, okuma için iki fonksiyon ve şifrelenmemiş bir bağlantı için bir fonksiyon vardır.
b) SocketRead'de timeout_ms'yi açıkça belirtmelisiniz, ancak SocketTlsRead ve SocketTlsReadAvailable'da böyle bir parametre yoktur (ayrı bir SocketTimeouts işlevi tarafından ayarlanır).


2. SocketIsReadable işlevinin adının, gerçekte ne yaptığıyla hiçbir ilgisi yoktur:

Aslında SocketIsReadable, Ws2_32.dll'deki FIONREAD bayrağıyla ioctlsocket() işlevinin eşdeğeridir.


3. Şifrelenmemiş bir bağlantı üzerinden Socket* işlevini kullanan bir kullanıcı, veri aktarımından sonra sunucu bağlantıyı kesmezse, sunucudan minimum gecikmeyle nasıl yanıt alabilir?

- SocketIsReadable işlevi, açıkça zaman gecikmesi kullanmadan (örn. Uyku olmadan) 0 döndürür.
- SocketRead işlevi ne kadar okuyacağını bilmiyor, buffer_maxlen değerini bir kenar boşluğu ile belirteceksiniz - timeout_ms kadar zaman aşımını beklemeniz gerekecek

Evet, şu şekilde yapılır:

- SocketRead'de 1 bayt veri bekliyoruz;
- daha sonra SocketIsReadable kullanarak tüm yanıtın boyutunu öğrenin;
- SocketRead'de eksik uzunluğu okuyun;
- dizileri kopyalayarak elde edilen sonuçları tek bir bütün halinde birleştirmek:

Bu çok fazla kod değil mi?


4. SocketIsReadable yanlış bilgi döndürür.
İnterneti kapatın ve yukarıdaki kodu çalıştırın.
Sonuç olarak, SocketIsReadable, aklı başında bir 1 değeri döndürür. Mucizeler.


Socket* ile ilgili toplam soru ve sorunların yaklaşık üçte birini tanımlamak mümkündü.
Ne yazık ki, her şeyi kontrol etmek, tanımlamak, iki kez kontrol etmek çok zaman alıyor ... (yani devamının olmayacağı bir gerçek değil)

Genel izlenim, ya her şeyin büyük bir aceleyle yapıldığı ya da Socket* işlevselliğinin küçük bir geliştirici tarafından uygulandığı yönündedir.
Her durumda, mevcut çözüm çok kaba ve soket kullanımına oldukça dar bir yaklaşımı içeriyor.

1. Bu arayüz.

TLS işlevleri, karmaşık durumları desteklemek için yardımcıdır. SocketTimeouts'u ayarlamakta sorun yok - bunlar kullanılacak en iyileri.


2. İşlevini doğru bir şekilde yerine getirir.

Görünüşe göre, TCP bağlantı kopması algılama sorunlarının farkında değilsiniz. Bağlantının doğru bir şekilde sonlandırılacağının garanti edildiğini tespit etmek oldukça zordur (ek çağrılar nedeniyle yoğun kaynak gerektirir). Tüm ağ uygulamaları bu sorundan muzdariptir.

SocketIsReadible uygulamamız, bağlantı kesme algılamasına sahip olacak kadar akıllıdır. Temiz bir 0 bayt ile karşılaştığında, soketin tamamlandığını kontrol etmek için fazladan bir iş yapar: 

   //+------------------------------------------------------------------+
   //| Доступно для чтения?                                             |
   //+------------------------------------------------------------------+
   UINT32 IsReadible( void )
     {
       unsigned long size= 1 ;     // специально, чтобы убиться при попытке чтения, если сокет мертв
       //--- проверка
       if (m_socket!=INVALID_SOCKET)
        {
         //--- считаем количество доступных для чтения байт
         if (ioctlsocket(m_socket,FIONREAD,&size)!= 0 )
           {
             Close ();
             return ( 1 );         // вернем 1, чтобы убиться при попытке чтения
           }
         //--- если нет данных, проверим сокет на завершенность
         if (size== 0 )
           {
            timeval wait_time;
            fd_set  fd;
             //--- ждём
            FD_ZERO(&fd);
            FD_SET(m_socket,&fd);

            wait_time.tv_sec = 0 ;           // секунды
            wait_time.tv_usec= 1000 ;       // микросекунды
             //--- ждём
             if (select( 0 ,&fd, NULL , NULL ,&wait_time)> 0 )
               return ( 1 );                 // вернем 1, чтобы убиться при попытке чтения
           }
        }
       //--- размер
       return (size);
     }

Bitmiş bayrak olmadan bayt sayısını döndürdüğünden, sonraki/yaklaşan SocketRead okuma girişiminin normal olarak başarısız olması için 1 bayt döndürür.

Neden doğru? Çünkü programcılar tarafından yazılan kodların çoğu alına şu şekilde yazılır:

 if (SocketIsReadible(...)> 0 )
  {
   if (SocketRead( )< 1 )
     return ( false );
   ...
  }
... уходим на следующий круг ожидания

aslında, işlemin sonucu doğrudan okuma girişiminde kontrol edilir.


3. Okunan verinin tam boyutunu bilmiyorsanız, gerçekten okumadan önce SocketIsReadible() yapmanız gerekir.

SocketisReadible / SocketRead bağlaması, programınızın yürütme akışı üzerinde kontrolü kaybetmeme (kontrol kaybını neredeyse sıfıra indirmek için) size fırsat verir. Bu, ağ zaman aşımlarına çarpmayı önler.

Evet, birkaç kod satırı daha, ancak (kabaca) bir milisaniye için kontrolü kaybetmezsiniz. Ağ verilerinin yokluğunda ne yapacağınıza siz karar verirsiniz.


4. İkinci paragrafta açıklanmıştır.

Okumayı teşvik etmek ve okuma hatası olarak çıkmak için 1 yayınlama.



Sonuçlarınız yanlış.

Hiçbir garantinin olmadığı TCP/IP aktarımının doğası budur. Orada, TCP sinyalinin hiçbir parçası olmadığında filtreler / güvenlik duvarları üzerindeki ağ kara deliklerine uçabilirsiniz. Zaman aşımlarının ve veri akışının ham kontrolü, bunları algılamanıza ve bağımsız olarak bağlantıları kesmenize olanak tanır.

TLS uygulamaları dahil olmak üzere ağ işlevlerine erişmek için ham/doğrudan bir arabirim verdik. Bunları kullanırsanız, ham işlevleri koruyucu / kontrollü bir SocketIsReadible / SocketRead işleyicisine doğru şekilde sarmanız gereken kişi sizsiniz.

Küçük şeyleri düşünmek zorunda kalmadan üst düzey isteklerde bulunmak istiyorsanız, WebRequest işlevleri vardır. Tüm korumalar yerleşiktir.

1...237023712372237323742375237623772378237923802381238223832384...3184
Yeni yorum