Librerie: MultiTester - pagina 15

[fxsaber]

Сергей Таболин:

È già possibile zippare o no? (E' come - se funzionasse ))))

Sì, gli zip in KB sono stati tranquillamente corretti - gli aggiornamenti arrivano lì. Le date dei file all'interno diventano uguali alla data dell'aggiornamento. Quindi in base a queste date si può capire immediatamente a che ora corrisponde il contenuto.

[Good Beer]

fxsaber:

È necessario esaminare i registri del tester.

Riavviare il terminale + attendere circa 10 minuti aiuta. Appare anche un avviso. Si dovrebbe iniziare a testare subito dopo aver aperto il terminale, senza nemmeno sfogliare le tendenze. Ma con il passare del tempo tutto può essere interrotto o mandato in loop. L'ultima volta che ho avuto un normale 172 passa. Se la situazione si ripete, invierò il log. In precedenza non ho notato alcuna deviazione dalla norma.

[fxsaber]

Good Beer:
Si dovrebbe iniziare a testare subito dopo aver aperto il terminale, senza nemmeno sfogliare le tendenze.

Questa non è una situazione normale. La norma è che tutto funzioni senza alcuna condizione.

[fxsaber]

Sulla base di MTTester è possibile confrontare l'efficienza di diverse logiche di trading.

Ad esempio, esistono TS1 e TS2. Dobbiamo capire quale sia il migliore (ovviamente in modo condizionato).

Si ottimizzano i singoli TS e poi si eseguono i passaggi migliori come singoli su diversi intervalli di OOS.

Tutto questo può essere fatto automaticamente tramite MTTester.

Confrontiamo i risultati di OOS e decidiamo quale TS è migliore.

[traveller00]

È appena apparso un registro interessante

2019.12.21 13:38:35.994 Tester  Ready to set
2019.12.21 13:38:36.617 Tester  i=100

sul codice.

  static bool ClickStart( const bool Check = true, const int Attempts = 100 )
  {
    bool Res = !Check || MTTESTER::IsReady();

    if (Res)
    {
      static const int ControlID[] = {0xE81E, 0x804E, 0x2712, 0x4196};
      GET_HANDLE

      user32::SendMessageW(Handle, BM_CLICK, 0, 0);

      Res = !Check || !MTTESTER::IsReady();

      int i = 0;
      for (i = 0; (i < Attempts) && (!Res)/* && !::IsStopped() */; i++) // Il distruttore globale può avere bisogno di
        if (Res = !Check || !MTTESTER::IsReady())
          ::Sleep(100);
      Print("i="+(string)i);
    }

    return(Res);
  }

Print("Ready to set");
MTTESTER::SetSettings2(TesterInput);
MTTESTER::ClickStart();

Idealmente a i=100 dovrebbe dormire per almeno 10 secondi. Non ho ancora capito come abbia fatto a farlo in un secondo (e in sostanza a eseguirlo in modo errato). Ma vale la pena di dire che il pulsante è stato premuto, sì. A quanto pare c'è un ritardo nell'indicazione del pulsante. Perché c'è una seconda istanza in esecuzione in parallelo sul test e sta caricando la CPU al 100%.

[traveller00]

Credo di aver capito. Le condizioni erano incasinate. Probabilmente è per questo che l'ultima volta hanno dovuto cambiare il numero di tentativi portandolo a 50. Dorme solo quando riesce, quando comunque sta per uscire. E passa in fretta quando è il momento giusto per dormire. Deve essere un insetto. E l'insetto è triste, ovviamente non si è presentato per quasi un mese, e speravo che i passaggi fossero a posto. Dovrò ricontrollare tutto. E continuavo a chiedermi perché raramente, ma a volte i passaggi non combaciano.

Immagino che debba essere

if (!(Res = !Check || !MTTESTER::IsReady()))

[fxsaber]

traveller00:

A quanto pare, dovrebbe essere

Sì, il loop stava perdendo significato a causa della mia disattenzione. Grazie per aver controllato e per aver indicato chiaramente la posizione. Lo ricaricherò se possibile.

[fxsaber]

fxsaber:

Sì, il ciclo stava perdendo significato a causa della mia disattenzione. Grazie per aver risolto il problema e per averlo indicato chiaramente. Se possibile, lo ricaricherò.

Aggiornato.

[Good Beer]

In attesa dell'aggiornamento, ho scoperto i motivi per cui l'elenco delle attività di multitester si chiudeva in loop.

Il primo è stato un task manager di terze parti "process lasso" sul mio computer. Aiuta con il mouse e la tastiera wireless, ma non ama quando un'applicazione occupa tutti i core della CPU. I processi dell'agente di test si interrompevano e i risultati andavano persi. Si otteneva un'attività incompleta, ogni volta con un nuovo risultato. Alzando la priorità del metatester si è risolto tutto.

Il secondo problema è che multitester non supporta il forward. Se il forward non è abilitato, tutto funziona bene. Ma se è abilitato, l'elenco dei task inizia a bloccarsi. Il test di avanzamento inizia quando appare il messaggio "DONE" alla fine di un passaggio. Multitester vuole scorrere l'elenco, ma si avvia l'avanzamento. Premendo il pulsante "START", viene avviato il vecchio task. Qual è il criterio del vostro algoritmo per terminare un passaggio?

Considerate l'avanzamento nelle versioni future di multitester.

[fxsaber]

Good Beer:

Si prega di prendere in considerazione l'inoltro nelle future versioni di multitestera.

Non ho mai utilizzato la modalità Forward in vita mia. Probabilmente un giorno la proverò.