Numero magico automatico - pagina 3

Nuovo commento
 
BarrowBoy:

Se non stessi chiudendo parzialmente alcun ordine, potresti usare il commento per memorizzare le informazioni sulla coppia/timeframe di origine...?

Se ci sono due EA sullo stesso simbolo e timeframe, come fanno a sapere da quale degli ordini storici prendere i rispettivi ID?


Tutto questo dipende in parte da quali informazioni si assume che siano disponibili al riavvio. Per esempio, ci sono alcune persone su questo forum che memorizzano i dati lungo queste linee in oggetti nascosti nella finestra del grafico. Questo non è male, ma personalmente sono spaventato da qualsiasi meccanismo che l'utente può rompere - senza rendersi conto di come e perché.

 
jjc wrote >>

Se ci sono due EA sullo stesso simbolo e sullo stesso timeframe, come fanno a sapere da quale degli ordini prelevare i rispettivi ID?

Accidenti - era nello scopo del progetto :D

Credo di aver dato per scontato che l'EA (se di tipo o versione diversa) avrebbe avuto un identificatore anche nei commenti :)

-BB-

 
jjc wrote >>

Non riesco a vedere come questo sia possibile senza che MT4 o l'utente assegnino un ID ad ogni EA. O, più precisamente, non vedo nulla che non implichi qualcosa di molto brutto come generare un ID unico e poi modificare il file .chr dell'EA per memorizzare l'ID come parte dei parametri esterni dell'EA.

E, per l'intrattenimento generale, quanto segue non fa realmente avanzare la discussione in alcun modo, ma sostituisce l'input all'hash djb2 con un valore che è garantito essere unico (al costo di richiedere chiamate DLL). Non so quanto sia buono djb2 su cose come i GUID, ma ho appena provato a generare 1.000.000 di ID senza alcuna collisione. Ma ancora non risolve il problema del riavvio.

Non riesco a capire come questo sia possibile senza che MT4 o l'utente assegnino un ID ad ogni EA. O, più precisamente, non vedo nulla che non implichi qualcosa di molto brutto come generare un ID unico e poi modificare il file .chr dell'EA per memorizzare l'ID come parte dei parametri esterni dell'EA.

>>Come farebbe l'ennesima istanza dell'EA a p/u il suo file chartyy.chr?

.

supponendo che un'istanza possa effettivamente mappare il proprio file .chr:

se il sorgente EA ha: extern int myID = <someCompileTimeVal>;

allora ogni istanza che vede <someCompileTimeVal> può assumere che sia 'la prima volta' -> gen il suo id -> mod la linea myID -> crea file di recupero usando l'unicità di myID ,...

poi al riavvio del rilevamento accede al suo file .chr per p/u myID che sarebbe la chiave principale per permettere la rimappatura dei file...

.

es:

chart02.chr

<cartina>
simbolo=EURUSD
periodo=15
..

..

<expert>
nome=LMT 1.8
bandiere=343
numero_finestra=0
<input>
myID=<qualcheCompileTimeVal>

...

</inputs>
</expert>
EOF


Aiuto !!!

.

E, per l'intrattenimento generale, quanto segue non fa realmente avanzare la discussione in alcun modo, ma sostituisce l'input all'hash djb2 con un valore che è garantito essere unico (al costo di richiedere chiamate DLL). Non so quanto sia buono djb2 su cose come i GUID, ma ho appena provato a generare 1.000.000 di ID senza alcuna collisione.

Ho usato PsPad ed per aspirare il 1mil e ho fatto un sort con remove dups spuntato.

>>Ma... Come hai fatto questo rilevamento "...senza collisioni" ?

 

"E, per l'intrattenimento generale, quanto segue non fa realmente avanzare la discussione in alcun modo, ma sostituisce l'input all'hash djb2 con un valore che è garantito essere unico (al costo di richiedere chiamate DLL). Non so quanto sia buono djb2 su cose come i GUID, ma ho appena provato a generare 1.000.000 di ID senza alcuna collisione".

.

Per tua informazione, ho trovato collisioni nelle mie 1mil chiamate del codice

ordinato EOF

.

ordinato + dups rimosso EOF

 
fbj:

>>Come potrebbe l'ennesima istanza di EA p/u il suo file chartyy.chr?

.

supponendo che un'istanza possa effettivamente mappare il proprio file .chr:

se il sorgente EA ha: extern int myID = <someCompileTimeVal>;

allora ogni istanza che vede <someCompileTimeVal> può assumere che sia 'la prima volta' -> gen il suo id -> mod la linea myID -> crea file di recupero usando l'unicità di myID ,...

poi al riavvio del rilevamento accede al suo file .chr per p/u myID che sarebbe la chiave principale per permettere la rimappatura dei file...

Hai ragione. Avevo dimenticato che non c'è un modo ovvio per un EA di identificare il suo file .chr se ci sono più EA per lo stesso simbolo e timeframe. Stavo pensando che potrebbe creare un oggetto etichetta nascosto contenente qualcosa come un GUID, e poi cercare il file .chr che contiene il valore corretto. Tuttavia, sono abbastanza sicuro che il file .chr non viene aggiornato quando un nuovo oggetto viene aggiunto al grafico.


E c'è un altro problema. Sono abbastanza sicuro che MT4 tenga le informazioni sul grafico in memoria, scrive sul file .chr quando MT4 viene chiuso (o viene apportata una modifica alle proprietà dell'EA), e questo quindi sovrascriverebbe qualsiasi modifica che l'EA stesso ha fatto al file .chr mentre era in esecuzione. Se sei incredibilmente coraggioso, potresti invece provare ad impostare la proprietà extern simulando la pressione dei tasti - richiamando la finestra delle proprietà, spostandoti sull'impostazione richiesta, cambiandola, premendo Invio ecc.

 
fbj:

Per tua informazione, ho trovato collisioni nelle mie 1mil chiamate del codice

ordinato EOF

Al momento della ri-esecuzione, lo stesso vale per me: 172 collisioni in 1.000.000 di tentativi.

 
jjc wrote >>

Hai ragione. Avevo dimenticato che non c'è un modo ovvio per un EA di identificare il suo file .chr se ci sono più EA per lo stesso simbolo e timeframe. Stavo pensando che potrebbe creare un oggetto etichetta nascosto contenente qualcosa come un GUID, e poi cercare il file .chr che contiene il valore corretto. Tuttavia, sono abbastanza sicuro che il file .chr non viene aggiornato quando un nuovo oggetto viene aggiunto al grafico.

E c'è un altro problema. Sono abbastanza sicuro che MT4 tenga le informazioni sul grafico in memoria, scrive sul file .chr quando MT4 viene chiuso (o viene apportata una modifica alle proprietà dell'EA), e questo quindi sovrascriverebbe qualsiasi modifica che l'EA stesso ha fatto al file .chr mentre era in esecuzione. Se sei incredibilmente coraggioso, potresti invece provare a impostare la proprietà extern simulando la pressione dei tasti - richiamando la finestra delle proprietà, spostandoti sull'impostazione richiesta, cambiandola, premendo Invio ecc.

Ho letto sopra -> sono andato a fare qualche esercizio -> e durante la doccia le cellule grigie gridano OBJECT. Si uccide il percorso .chr ma le due parole "etichetta oggetto" hanno fatto scattare quello sfogo cerebrale :)

Allora, che ne dite? Dimenticando per un momento di ottenere un ID garantito al 100%. L'altra parte è questa memoria di stato recuperabile che contiene un ID EAs.

Bene...

1. void vArchiveID (int iID), int iRestoreID () [e int iGetNewID () si trovano in un altro post SE questo va bene :]

2. vArchiveID() crea un oggetto etichetta [nascosto?] sulla tabella della memoria di stato EAs.

Il nome dell'oggetto DEVE essere lo stesso per ogni EA chiamante... quindi .ex4 lib o .mqh lib per (1)

3. CT fallisce o EA fallisce ecc.

4. al riavvio dell'EA il primo lavoro è chiamare iRestoreID() che restituisce -1 se nessun oggetto sul grafico o l'ID archiviato dall'esecuzione precedente.

5. se nessun ID chiama iGetNewID() poi vArchiveID() e presumibilmente imposta [per la prima volta] il file di dump

6. se ID 'restaurato' allora va allegramente a recuperare l'ultimo stato tramite i file di dump...

..

Cosa ne pensate?

 
fbj:

[...]

Cosa ne pensi?

Quello che suggerisci è - credo - esattamente quello a cui alludevo nel mio post delle 14:43. L'unico pericolo di questo percorso - e l'unica ragione per scimmiottare direttamente il file .chr per impostare le proprietà esterne - è eliminare la possibilità che gli utenti cancellino accidentalmente gli oggetti dal grafico. Ma anche questo può essere ampiamente superato assicurandosi che l'obejct sia ricreato, se necessario, in deinit().


Ma BB/CB potrebbe considerare inaccettabile la dipendenza dal file .chr. Potrebbero volere qualcosa che può essere recuperato solo da dati tenuti fuori sede (cioè la lista delle transazioni tenuta dal broker).

 

Sono stato lontano da questo thread per un po'.


Sembra che stiamo aggiungendo un certo grado di complessità per permettere la recuperabilità con numeri magici automatizzati, sì? Cioè, così uno stupido pezzo di codice reincarnato può capire chi era in una vita passata quando tutto quello che sa è cosa è e dove si trova. Non è necessariamente una brutta cosa. Ma...


Mi ha fatto pensare che sarebbe utile documentare (molto concisamente):

- Criteri per decidere di implementare i numeri magici

- Criteri per decidere di usare la generazione automatica di numeri magici

- Criteri per decidere di implementare un livello di persistenza

- Criteri per decidere su globals vs. accesso a file per la persistenza


La ragione per cui suggerisco questo è per evitare che tutti pensino di dover implementare il lavandino della cucina nei loro EA.


Visualizzazioni?


CB


- Mi restano solo 8 post prima di prendermi una pausa per un po'.

 

sì, beh alla fine, il lavello della cucina è molto probabilmente su questo sito, tutto accademico. Per me, la prima preoccupazione prioritaria è quella di avere un ID esperto auto[make|acquire] garantito. Un valore che può essere utilizzato per molti scopi.

Avere un modo unico per accedere ai file di dump al riavvio è nel migliore dei casi aleatorio e, in ogni caso, richiede agli utenti di aderire a un insieme di regole di utilizzo di EA. Molte istanze ccy+periodo+EA non è un'opzione.

Ero intenzionato a fare in modo che qualsiasi istanza fosse in grado di determinare chi era io prima del riavvio e questo si dimostra impraticabile. Da parte mia, non mi fiderei di nessun utente per seguire anche le regole più elementari. Se non posso essere totalmente sicuro di un metodo automatico, non adotterei una via di mezzo che richieda l'intervento dell'utente.

.

Usando CoCreateGuid() i/f di jjc ho intenzione di generare abbastanza numeri non ripetitivi. Abbastanza è soggettivo, ma sto andando per molti... Accoppiato con un pezzo di codice di libreria come funzione del server di accesso alle risorse al file che contiene i numeri. La quantità di numeri sarà tale che almeno 2 anni possono passare senza mai riutilizzare un numero. Nel momento in cui si raggiunge EOF, si passa a BOF e si continua a servire i numeri. I miei calcoli con il dito nel cielo saranno basati su 10 richiedenti che funzionano 5 giorni alla settimana e 50 settimane all'anno dove ogni giorno un qualsiasi richiedente potrebbe richiedere 20 nuovi ID. Questo risultato viene poi raddoppiato. Una quantità assurda di numeri - praticamente 200.000. Sì, una funzionalità dell'età della pietra, ma impermeabile senza alcuna necessità di dipendere dal terminale in alcun modo oltre alla capacità di eseguire il mio codice. Naturalmente si potrebbe andare avanti per secoli sulle ramificazioni di uno, 10 o 100 file e le loro posizioni fisiche e meccanismi di accesso. Alla fine è molto meglio della mia pietosa funzione make expert id ed è impermeabile per quanto riguarda l'unicità del numero per [in realtà] più di 2 anni.

.

CB, 666 deve essere un numero fortunato per i piloti di elicotteri?

1234
Nuovo commento