Librerie: MultiTester - pagina 26

 
traveller00:

1. Passerei da GetTickCount() a GetTickCount64() in Sleep2. Altrimenti, l'overflow minaccia una logica non del tutto corretta. E si verifica molto meno spesso nella variante a 64. Anche in altri lavori potrebbe valere la pena di cambiare.

Lì, anche teoricamente, non ci può essere una minaccia di overflow.

void OnStart()
{
  uint StartTime1 = UINT_MAX - 100;
  uint StartTime2 = UINT_MAX + 100;
  
  Print(StartTime2 - StartTime1); // 200 
}

2. Il secondo ArrayResize solleva delle domande

Molto probabilmente dovrebbe essere

No, è tutto corretto. La documentazione mente.

3. Infine, alcuni tipi diversi.

Risolto, grazie.

 
fxsaber:

Non ci può essere nemmeno una minaccia teorica di overflow.

Sì, hai ragione, sono stato disattento. In questo caso non c'è alcuna differenza.

Ma in ThirdPartyTicks -> Web.mqh sembra esserci una differenza.

    ulong StartTime = ::GetTickCount();
...
    StartTime = ::GetTickCount() - StartTime;

Ecco perché uso la variante a 64 bit ovunque, per sicurezza.


fxsaber:

No, lì è tutto corretto. La documentazione è sbagliata.

Uso il seguente codice

    ushort Shorts[];
    MTTESTER::FileLoad(FileName,Shorts);

All'interno di FileLoad ci sarà Size=1000, dimensione dell'array 500 e dopo la lettura Read=Size=1000. E poi la mia variante è corretta. In questo caso mi sono affidato a MSDN e questo comportamento concorda con esso.

 
traveller00:

Utilizzo il seguente codice

All'interno di FileLoad sarà Dimensione=1000, dimensione dell'array 500 e dopo la lettura Read=Dimensione=1000. E quindi la mia variante è corretta. Mi sono affidato a MSDN e questo comportamento concorda con esso.

Ho 500.

 
fxsaber:

Ne ho 500.

È strano, ho appena ricontrollato e corrisponde a MSDN. Ma se nessuno ha domande e tutto funziona, allora va bene, non vedo il motivo di scavare nei dettagli.

 

Se qualcuno l'ha fatto, può condividere lo schema di organizzazione del lavoro con i risultati delle ottimizzazioni precedenti mentre il collaudatore è impegnato nell'ottimizzazione attuale.


È chiaro che dobbiamo copiare i file opzionali e i simboli. Probabilmente il modo più ragionevole è tramite mklink.

 
fxsaber:

Se qualcuno l'ha fatto, può condividere lo schema di organizzazione del lavoro con i risultati delle ottimizzazioni precedenti mentre il collaudatore è impegnato nell'ottimizzazione corrente.


È chiaro che dobbiamo copiare i file opzionali e i simboli. Probabilmente il modo più ragionevole è tramite mklink.

Io uso un collegamento alla cartella della cache. Solo che non con mklink, ma con il file manager di Far Commander. Ma è lo stesso.
È possibile organizzare l'accesso ai file al di fuori della sandbox e con WinAPI, ma i collegamenti sono preferibili.
In linea di principio non ho bisogno di altro, ma se necessario devo creare collegamenti ad altre cartelle.
Per schema di organizzazione del lavoro si intende qualche altro dettaglio?
 
Edgar Akhmadeev:
Per schema di organizzazione del lavoro si intende qualche altro dettaglio?

Osservare i file opzionali ed eseguire singoli passaggi da essi.

 

Personalmente, cerco di non utilizzare più terminali in una cartella. È fatto in modo molto particolare. Se cade tranquillamente, lo si scopre una settimana dopo per caso.

E così funziona attraverso vin api.

 
Salve. È possibile modificare uno dei parametri dell'EA in modo programmatico ed eseguire un singolo test?
 
pivomoe:
Salve. È possibile modificare uno dei parametri dell'EA in modo programmatico ed eseguire un singolo test?

La libreria MTTester consente di fare assolutamente tutto ciò che un utente può fare tramite GUI.