Librerie: Rapporto rapido MT4Ordini - pagina 6

Nuovo commento
 
Forester #:

L'informazione sul drawdown massimo lungo è interessante. L'ho fatta per l'intero array di stringhe. Non ho ancora aggiornato il codice sul sito.
Ma non è chiaro a cosa serva la data. Se facciamo un punto di divisione in test back/forward (come ho suggerito), allora dobbiamo calcolare le statistiche su di essi separatamente in 2 tabelle (i periodi di drawdown massimo saranno anche lì).

Ho fatto un calcolo completo delle statistiche per i test back/forward
.

Il file è stato aggiornato.
 
Forester #:

Non è chiaro a cosa serva la data.

Se volete vedere dal 2020, per favore. Dal 2023, nessun problema. È solo che a volte non ci si preoccupa di cosa fosse nel 2010. E mostra che la durata più lunga è stata nel 2010.
 
fxsaber #:
Se volete guardare dal 2020, siete i benvenuti. Dal 2023, non c'è problema. È solo che a volte non ti interessa cosa c'era nel 2010. E mostra che la durata più lunga è stata quella del 2010.
Ah - ho capito il punto. Non per un tester con un esperto/strategia, ma per un conto reale in cui sono state testate diverse idee.

L'impostazione di una data di scadenza aiuterebbe a separare le statistiche.

 
Forester #:
Ah - ho capito il punto. Non per un tester con un solo esperto/strategia, ma per un conto reale in cui sono state testate diverse idee.

Io stesso lo userei solo per un tester. I drawdown reali non sono affatto interessanti.

 
Forester #:
Cosa c'è di sbagliato in questo?

Uno stile potenzialmente pericoloso. Per esempio, qualche tempo dopo si vorrà scrivere una funzione di formattazione della data personalizzata e la sua chiamata sarà scritta in una riga lunghissima, per abitudine:

Print("From " + TimeToString(From[i], TIME_DATE) + " MaxLengthDD = " + (string)(MaxLengthDD(BeginDD, EndDD, From[i]) / (25 * 3600)) + " days: " + Format(BeginDD) + " - " + Format(EndDD));

Ma non è garantito che Format-ids venga chiamato dopo MaxLengthDD, solo perché è elencato a destra tra i sommatori.

In linea di principio, un record superlungo di una riga ha dei lati negativi: è difficile da leggere e da capire (in effetti, è difficile ripetere nella propria mente il parsing di un'espressione come fa un compilatore, ma un essere umano non è un compilatore, dopotutto), è difficile fare il debug. Inoltre, un record così compatto non offre alcun guadagno in termini di prestazioni.

 

Super biblioteca! Grazie all'autore!

Suggerimenti per miglioramenti:
- nascondere il grafico interattivo (o aggiungere un altro meccanismo per questo) quando si clicca di nuovo sul grafico,
- salvare il sorgente in UTF-8, in modo che possa essere letto normalmente da GitHub (questo è un evento una tantum, che non minaccia nulla, ma aggiunge comodità)
- controllare il nome del file per i caratteri proibiti (\ / / : * ? " < > | : :), e sostituirli con qualcosa di neutro (-, per esempio)
- aggiungere un parametro per salvare i rapporti nella cartella comune dei terminali, in modo da non doverli cercare nelle cartelle degli agenti.


Grazie ancora, uno strumento molto utile!

 
Andrey Khatimlianskii cartella comune dei terminali, in modo da non cercarli nelle cartelle degli agenti


Grazie ancora, uno strumento molto utile!

Ho fatto tutto.
Aggiunti 2 nuovi parametri alla chiamata
void QuickReport(string file_name, bool is_open_file_in_browser=true, int virtual_number=0, bool hide_account_and_name=false, bool common_path=false, bool fileANSI=true){...}
common_path - salva nella cartella comune del terminale. Per evitare che i file vengano sovrascritti da un altro agente durante l'ottimizzazione, ho aggiunto il numero dell'agente (3000, 3001,...) ai nomi dei file. Quando si salva nella cartella del tester (false), i file vengono salvati nella cartella dell'agente che ha eseguito i calcoli.
fileANSI - salva in codifica ANSI o in UNICODE. Le dimensioni dei file UNICODE sono 2 volte maggiori e richiedono più tempo per l'elaborazione, quindi se si caricano molti dati, ad esempio 1 GB, è più economico usare ANSI. UNICODE è aggiunto per la compatibilità con i servizi di terze parti, se necessario.

Sono stati aggiunti anche il controllo dei caratteri e il pulsante Nascondi, ma non li ho descritti.
 
Forester #:
Aggiunti 2 nuovi parametri alla chiamata
Questo è il modo in cui verranno aggiunti nuovi parametri. Per questo motivo è meglio scrivere la firma una volta sola, dove la struttura delle condizioni è inserita. In questo modo la firma non cambierà. Questo è ciò che ho fatto in Report.
 
fxsaber #:
In questo modo verranno aggiunti nuovi parametri. Per questo motivo, è meglio scrivere la firma una volta sola, dove la struttura delle condizioni è inserita. In questo modo la firma non cambierà. È quello che ho fatto in Report.
Forse è meglio. Ma è necessario mantenere l'attuale schema di chiamate per la compatibilità con i programmi già pronti che utilizzano la libreria, in modo che qualcuno non debba modificare il codice.
 
Forester #:
Probabilmente è meglio. Ma è già necessario mantenere l'attuale schema di chiamata, per la compatibilità con i programmi già pronti che utilizzano la libreria, in modo che qualcuno non debba modificare il codice.

Il sovraccarico aiuterà.

12345678910
Nuovo commento