"New Neural" è un progetto di motore di rete neurale Open Source per la piattaforma MetaTrader 5. - pagina 63
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
...
A proposito, xml è molto più facile da controllare per la validità rispetto alla rappresentazione binaria. E il salvataggio/ripristino non è essenzialmente critico in termini di tempo.
Qual è, secondo voi, la difficoltà di controllo nella rappresentazione binaria dei link?
Fammi un esempio di quando è difficile.
ZZZ non solo non mi viene in mente un esempio, ma non riesco nemmeno a immaginare che tipo di topologia sia, che quando si rappresentano i collegamenti con una tabella binaria, è difficile controllare la validità di qualsiasi collegamento.
Fammi un esempio di quando è difficile.
Guarda. Hai cambiato un po' il formato di memorizzazione o i dati si sono confusi e diciamo che invece di una dimensione dell'array ottieni la parte inferiore del duble, cioè un array di dimensioni enormi.
E nell'xml hai le dimensioni avvolte in un tag
1. perché no.
Perché non c'è una base universale. Queste sono solo le tre griglie che ricordavo.
Guarda. Hai cambiato un po' il formato di memorizzazione o i dati si sono confusi e diciamo che invece di una dimensione dell'array ottieni il fondo del dubble, cioè un array di dimensioni enormi.
E nell'xml hai la dimensione avvolta in un tag
"Ha cambiato un po' il formato di memorizzazione" suona come cambiare xml in avi e non accorgersene.
Qualsiasi cambio di formato è gestito da qualcuno che conosce bene entrambi i formati, + quando si cambia il formato il debugging e i test sono inevitabili.
Quindi un piccolo cambiamento nel formato di memorizzazione non può essere considerato un argomento.
A proposito di dati fuori posto (bene, memorizzare dubles e sunlongs insieme ho scoraggiato e corretto), per evitare il misplacement scrivere somma hash per verificare la correttezza del file letto, altre opzioni quando i dati possono andare fuori strada non prevedono.
quindi abbiamo un formato per memorizzare un array fluttuante con informazioni sulla griglia:
[somma di hash] [numero di strati]
[tipo di strato] [numero di neuroni]
[tipo di strato] [numero di neuroni]
[tipo di strato] [numero di neuroni]
[tipo di strato] [numero di neuroni]
[tipo di strato] [numero di neuroni]ulteriormente alla fine del file ulong's che definiscono la tabella binaria.
Come convertire ulong in [64] array di caratteri booleani Ho una funzione pronta.
Perché non c'è una base universale. Queste sono solo le tre griglie che ricordavo.
Non sono d'accordo, ma non voglio discutere ora, risponderò più tardi (un giorno o due) quando avrò i fatti in mano.
cercherai di bombardare la mia teoria allo stesso tempo :)
Merda... Forse non capisco. Perché devi inventarti la tua rottura di scatole?
Non sei l'unico che non capisce :)
Imho, il formato binario è una catenella, che incatena i dati all'implementazione, qualcosa di cui ci si dovrebbe liberare il prima possibile in un design competente. Il formato binario è buono per impacchettare i dati. per esempio, in MT4 i dati erano memorizzati così. Ma è stato ragionevolmente fatto lì per ridurre il carico sulla rete, e lo scrittore/lettore è uno sviluppo interno.
Ma perché preoccuparsi di una tale elaborazione? Per scrivere il proprio editor per questo formato e avere più problemi con esso? xml, json, o anche ini sarebbe più corretto
Non sei l'unico tra i malintesi :)
Imho, il formato binario è una catena, che incatena i dati all'implementazione, qualcosa di cui bisogna sbarazzarsi al più presto in un design competente. Il formato binario è buono per impacchettare i dati. per esempio, in MT4 i dati erano memorizzati così. Ma è ragionevolmente fatto lì per ridurre il carico sulla rete, e lo scrittore/lettore è uno sviluppo interno.
E perché preoccuparsi di una tale elaborazione? Per scrivere il proprio editor per questo formato e avere più problemi con esso? xml, json, o anche ini sarà meglio.
Suggerisci un'altra implementazione, non sono contrario, discutiamo, confrontiamo, decidiamo cosa è meglio.
Finora ho visto una proposta nel thread (la mia), gli altri dicono solo "facciamo xml, json, ini", ma nessuno ha detto come sarà implementato il caricamento della griglia in tutto questo.
La tabella dei link binari è abbastanza semplice da capire, andando per colonne si ottiene chi mandare, andando per righe si ottiene chi mandare a (o viceversa, dato che la tabella è quadrata, bisogna solo mettersi d'accordo su come prenderla).
E come sarà implementato in altri formati nessuno dice nulla.
Parlate.
Di questo passo i tuoi figli saranno d'accordo e si fermeranno a xml, i nipoti inizieranno ad implementare.
Vota o scegli un anziano.
Di questo passo i tuoi figli saranno d'accordo e si fermeranno a xml, i nipoti inizieranno a implementare.
Vota o scegli un anziano.
Cosa votare se non viene proposta alcuna alternativa, ho una descrizione dell'idea generale dell'algoritmo di caricamento della griglia, il miglior formato per memorizzare questo algoritmo in bin.
Altri suggerimenti per il caricamento degli algoritmi nevidal, visto solo proposte per il formato di archiviazione, ma il formato di archiviazione stesso dovrebbe essere scelto in base all'algoritmo da caricare, per un algoritmo un formato è meglio per un altro.
Ci saranno suggerimenti per gli algoritmi, ci sarà anche una discussione sostanziale su cosa è meglio e in quale formato è meglio conservare.