"New Neural" è un progetto di motore di rete neurale Open Source per la piattaforma MetaTrader 5. - pagina 62
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
Che è più veloce è chiaro. Ma quante volte in tutto l'allenamento dovrete scrivere sul file? - Una volta?
Pertanto, la velocità non è critica, ma il controllo visivo è semplificato.
Non direi che un file xml sarebbe facile da controllare visivamente.
Posso ancora usare una specie di modello come un file xml, ma visualizzare una griglia con 1500 neuroni in uno strato sarebbe una rottura di scatole, quindi si ha il fastidio di creare un file xml e non si ottiene comunque una buona visualizzazione. Anche se non lo rifiuto, quando lo salvi, puoi duplicarlo anche in xml.
Cosa intendo per inizializzazione? Se il caricamento dei pesi è una cosa. Se configurare la griglia + caricare i pesi è un'altra cosa.
--
Giusto. Canterò.
Ci sono due modi per mappare la configurazione della rete intermedia (struttura, tipo) nel codice mql5.
Il primo: configurazione dinamica della rete durante l'inizializzazione da classi di libreria. Una tale rete abbonda di array dinamici e di collegamenti tramite puntatori. Questo approccio ha implicitamente dominato finora.
Ma c'è un secondo modo: generare una maglia rigida (con array statici e accessi diretti agli indirizzi desiderati (indici)) dopo la preconfigurazione e la mappatura in xml.
Tale motore può essere molto più attraente per gli utenti, a causa della maggiore velocità (significativamente) della griglia generata. Ma è più complicato da implementare. Infatti, bisognerebbe fare un compilatore xml2mql.
Io, infatti, per il secondo modo. Spero che le meta-citazioni aiutino, se ci si blocca.
Primo modo.
La seconda alternativa è stata scartata (non ricordo esattamente, ma nelle prime pagine), perché in futuro nella categoria di "utente" saranno incluse persone che non sanno cosa sia F7.
Inoltre, il motore è pensato per essere facilmente espandibile, e chiunque conosca lo scopo di F7 può aggiungere un altro tipo di griglia o inventarne una propria.
ZY capisco il tuo attaccamento alla codifica dei template, ma sono d'accordo che nel secondo modo avremo grossi problemi con l'implementazione sia degli algoritmi di apprendimento che dell'estensione dei tipi di neuroni, in più questo dovrà ancora essere ottimizzato per la GPU. Ci sono seri problemi con la prima variante, le cose più semplici che tutti sono in grado di fare, e solo per descrivere il progetto di motore universale mi fa friggere il cervello.
Domani copierò il mio lavoro sulla memorizzazione dei prototipi di rete, l'impostazione dei compiti di formazione, la memorizzazione delle soluzioni trovate qui dal mio computer di lavoro.
Tutto in xml
Penso che l'intensità di risorse dell'analisi dei file xml sia troppo esagerata
Non dimenticate che si tratta di una procedura unica.
Inoltre, scrivere un parser nativo di file xml per MQL5 è un compito banale rispetto alla complessità di un progetto di rete neurale
Il primo modo.
La seconda alternativa è stata scartata (non ricordo esattamente, ma nelle prime pagine), perché in futuro, le persone che non sanno cosa sia F7 saranno arruolate nella categoria "utente".
Inoltre, si suppone che questo motore sia facilmente estendibile, e chiunque conosca lo scopo di F7, può aggiungere altre mesh per se stesso o inventarne di proprie.
Ho solo una domanda a causa della mia mancanza di competenza nei tipi di mesh.
Un tipo di mesh può essere definito in modo univoco da una tabella di lookup, cioè possiamo creare una mesh astratta universale che segue semplicemente una data tabella di lookup? In altre parole, una rete veramente universale ?
Se la risposta è sì, allora il tipo di griglia è definito dall'editor di configurazione della griglia PRIMA che la vista intermedia sia creata, e non è necessaria alcuna modifica della libreria universale. Voglio dire che non sarà mai necessario (se non è glitchato), qualunque sia la struttura della griglia. L'unica cosa che si può fare è ottimizzarla, espandere la libreria di convertitori non lineari, metodi di formazione e così via.
Se "no", sentitevi liberi di colpirmi con qualche link per le eccezioni che non rientrano in questo modo.
--
Se la rappresentazione xml della descrizione della rete è pensata a fondo e completamente astratta dall'implementazione mql (che è corretta), allora le alternative non sembrano contraddittorie. Non solo possono essere implementati entrambi, ma le alternative possono anche essere incrociate.
...
La risposta non è binaria,
Da un lato la risposta è negativa, la stessa tabella delle relazioni non specifica la tipologia dei neuroni.
D'altra parte la risposta è positiva, è possibile specificare i tipi in forma numerica (si crea un oggetto di un tipo particolare ereditato da un antenato comune tramite lo switch).
Quindi, in aggregato, un array parametrico e una tabella di relazione vanno bene.
Ma d'altra parte, anche l'editor di configurazione ha dei parametri (numero di strati, numero di neuroni in ogni strato, tipi di neuroni nello strato) e questo prima di creare collegamenti.
In altre parole, una rete veramente universale ?
Dal feed-forward, sì. Per gli altri, bisogna guardare la topologia.
La topologia è impostata dalla tabella dei collegamenti....
?
La topologia è impostata dalla tabella dei collegamenti ....
E la funzionalità delle parti da collegare.
Ok, entriamo un po' più nel dettaglio.
Questa funzionalità può essere data da una tabella finita (piccola)? Qual è la differenza tra neuroni di tipo diverso (a parte le funzioni di attivazione)?
Ok, entriamo un po' più nel dettaglio.
Questa funzionalità può essere data da una tabella finita (piccola)? Qual è la differenza tra neuroni di tipo diverso (a parte le funzioni di attivazione)?
In senso stretto, no.
Prima un caso semplice. Diciamo che abbiamo neuroni lineari, sigmoidi e tangenti. Se vogliamo aggiungere un nuovo tipo di attivazione, dobbiamo espandere l'enumerazione dei tipi di attivazione.
Fondamentalmente, quindi al diavolo. Ma prima, perché, per esempio nella rete Kohonen, lo strato di output avrebbe bisogno di un segno di alcune=alcune funzioni di attivazione? Questa è un'informazione superflua e ridondante.
In secondo luogo, questa lista è teoricamente illimitata.
In terzo luogo, ogni rete può avere delle particolarità nel suo funzionamento e nella sua disposizione. Per esempio, una rete di Kohonen (SOM) può avere un'impostazione della funzione dei vicini e una bandiera che indica se emettere i risultati come output o solo il leader (azzerando tutti i non leader)
Nei modelli logici, per esempio, i parametri configurabili sono nella funzione di attivazione. Questo è anche nel modello generale?
Nello strato MLP potrebbe essere una bandiera di presenza di un singolo neurone.
____________________________
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.
1. strettamente parlando, no.
Prima un caso semplice. Diciamo che abbiamo neuroni lineari, sigmoidi e tangenti. Se vogliamo aggiungere un nuovo tipo di attivazione, dobbiamo espandere l'enumerazione dei tipi di attivazione.
Fondamentalmente, quindi al diavolo. Ma prima, perché, per esempio nella rete Kohonen, lo strato di output avrebbe bisogno di un segno di alcune=alcune funzioni di attivazione? Questa è un'informazione inutile e superflua.
In secondo luogo, questa lista è teoricamente illimitata.
In terzo luogo, ogni rete può avere le sue peculiarità nel funzionamento e nella struttura. Per esempio, una rete di Kohonen (SOM) può avere un'impostazione della funzione dei vicini e una bandiera che indica se emettere i risultati come output o solo il leader (azzerando tutti i non leader).
Nei modelli logici, per esempio, i parametri configurabili sono nella funzione di attivazione. Questo è anche nel modello generale?
Nel livello MLP potrebbe essere una bandiera per avere un singolo neurone.
____________________________
2. A proposito, xml è molto più facile da controllare per la validità rispetto alla rappresentazione binaria. E il salvataggio del recupero non è essenzialmente critico in termini di tempo.
1. Perché no. La mia idea è qualcosa del genere - creare una "base di elementi" universale da cui si possono "saldare" reti neurali di qualsiasi tipo (può anche essere estensibile). Gli elementi di questa base sono definiti da definizioni esatte e non ambigue - formule. Se necessario con l'applicazione dello pseudocodice. Ma non sotto forma di codice mql, per fornire il distacco dalle implementazioni - possono essere migliorate con il tempo. Dopo che la base astratta degli elementi è stata creata (se possibile), è possibile formattare il file xml, in grado di descrivere tutte le connessioni tra gli elementi. Dopo che la descrizione xml è approvata, il progetto può essere facilmente messo in parallelo: scrivere separatamente
1) Implementazioni di componenti. => l'output è una libreria di componenti.
2) configuratore di tipo/struttura di rete => output - grafico, passo dopo passo o qualsiasi altro configuratore, salvando la configurazione in un file xml.
3) traduttore/i in codice mql. => l'output è o (1) una super-duper auto-configurante rete neurale mql, prendendo un file xml come parametro, o (2) un compilatore per una particolare rete rigida basata su mql.
Qualcosa del genere. Sembra avere senso.
2. Sì.