O "New Neural" é um projecto de motor de rede neural Open Source para a plataforma MetaTrader 5. - página 62
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
O que é mais rápido é claro. Mas quantas vezes em todo o treinamento você vai ter que escrever para o arquivo? - Uma vez?
Portanto, a velocidade não é crítica, mas o controle visual é simplificado.
Eu não diria que um arquivo xml- seria fácil de controlar visualmente.
Eu ainda posso usar algum tipo de template como um arquivo xml-, mas visualizar uma grade com 1500 neurônios em uma camada seria uma chatice, então você tem o incômodo de criar um arquivo xml- e você não terá uma boa visualização de qualquer maneira. Embora eu não o rejeite, quando você o guarda, você pode duplicá-lo em xml também.
O que quero dizer com inicialização? Se carregar pesos, é uma coisa. Se configurar a grelha + pesos de carga é outra coisa.
--
Certo. Eu vou cantar.
Há duas formas de mapear a configuração da rede intermediária (estrutura, tipo) para o código mql5.
A primeira: configuração dinâmica da rede durante a inicialização a partir das aulas da biblioteca. Tal rede é abundante com matrizes dinâmicas e ligações através de apontadores. Esta abordagem tem dominado implicitamente até agora.
Mas há uma segunda maneira: Gerar uma malha rígida (com matrizes estáticas e acessos diretos aos endereços desejados (índices)) após pré-configuração e mapeamento para xml.
Tal motor pode ser muito mais atractivo para os utilizadores, devido à maior (significativa) velocidade da rede gerada. Mas mais complicado de implementar. Na verdade, você precisaria fazer um compilador xml2mql.
Eu, na verdade, pela segunda via. Espero que as meta-cotações ajudem, se ficarmos presos.
Primeira maneira.
A segunda alternativa foi descartada (não me lembro exactamente, mas nas primeiras páginas), porque no futuro na categoria de "utilizador" incluirão pessoas que não sabem o que é F7.
Além disso, o motor destina-se a ser facilmente expansível, e qualquer pessoa que conheça o propósito de F7 pode adicionar outro tipo de grelha ou inventar a sua própria.
A ZY entende o seu anexo à codificação de modelos, mas concorda que da segunda forma teremos grandes problemas com a implementação de algoritmos de aprendizagem e extensão de tipos de neurônios, além disso, isso ainda precisará ser otimizado para a GPU. Há problemas sérios com a primeira variante, as coisas mais simples que todos são capazes de fazer, e apenas para descrever o projeto do motor universal faz meu cérebro fritar.
Amanhã vou copiar o meu trabalho de armazenamento de protótipos de rede, criar tarefas de formação, armazenamento de soluções encontradas aqui a partir do meu computador de trabalho.
Tudo em xml
Acho que a intensidade de recursos dos ficheiros xml de análise é demasiado exagerada.
Não se esqueça que este é um procedimento único.
Além disso, escrever um analisador de arquivos xml nativo para MQL5 é uma tarefa trivial em comparação com a complexidade de um projeto de rede neural.
A primeira maneira.
A segunda alternativa foi descartada (não me lembro exactamente, mas nas primeiras páginas), porque no futuro, as pessoas que não souberem o que é a F7 serão alistadas na categoria "utilizador".
Além disso, este motor é suposto ser facilmente extensível, e quem conhece o propósito de F7, pode adicionar mais algumas malhas para si próprio ou inventar a sua própria.
Tenho apenas uma pergunta, devido à minha falta de competência em tipos de malha.
Um tipo de malha pode ser definido exclusivamente por uma tabela de pesquisa, ou seja, podemos criar uma malha abstrata universal que apenas segue uma determinada tabela de pesquisa? Em outras palavras, uma rede verdadeiramente universal ?
Se a resposta for sim, então o tipo de grade é definido pelo editor de configuração de grade ANTES da criação da visão intermediária, e nenhuma modificação da biblioteca universal é necessária. A única coisa que você pode fazer é otimizá-la, expandir a biblioteca de conversores não lineares, métodos de treinamento, etc.
Se "não", sinta-se à vontade para me bater com alguns links para exceções que não se encaixam desta forma.
--
Se a representação xml-representação da descrição da rede é cuidadosamente pensada e completamente abstraída da mql-implementação (que é correta), então as alternativas não parecem contraditórias. Não só ambas podem ser implementadas, como também as alternativas podem ser entrecruzadas.
...
A resposta não é binária,
Por um lado a resposta é negativa, a própria tabela de relacionamentos não especifica a digitação de neurônios.
Por outro lado, a resposta é positiva, é possível especificar tipos em forma numérica (cria-se um objecto de um determinado tipo herdado de um antepassado comum pelo interruptor).
Portanto, no agregado, uma matriz paramétrica e uma tabela de relações estão bem.
Mas por outro lado, mesmo o editor de configuração tem parâmetros (número de camadas, número de neurônios em cada camada, tipos de neurônios na camada) e isso antes de criar links.
Em outras palavras - uma rede verdadeiramente universal ?
Da alimentação para a frente, sim. Para os outros, você tem que olhar para a topologia.
A topologia é definida pela tabela de ligação....
?
A topologia é definida pela tabela de ligação ....
E a funcionalidade das peças a serem ligadas.
OK, vamos entrar em mais detalhes aqui.
Esta funcionalidade pode ser dada por uma tabela finita (pequena)? Qual é a diferença entre neurônios de diferentes tipos (além das funções de ativação)?
OK, vamos entrar em mais detalhes aqui.
Esta funcionalidade pode ser dada por uma tabela finita (pequena)? Qual é a diferença entre neurônios de diferentes tipos (além das funções de ativação)?
Estritamente falando, não.
Primeiro um caso simples. Digamos que temos neurónios lineares, sigmóides e tangentes. Se quisermos adicionar um novo tipo de activação, temos de expandir a enumeração dos tipos de activação.
Basicamente, então que se lixe. Mas primeiro, porque é que, por exemplo na rede Kohonen, a camada de saída precisaria de um sinal de algumas=algumas funções de activação? Esta é uma informação supérflua e redundante.
Em segundo lugar, esta lista é teoricamente ilimitada.
Em terceiro lugar, cada rede pode ter peculiaridades no seu funcionamento e arranjo. Por exemplo, uma rede Kohonen (SOM) pode ter uma configuração de função vizinha e uma bandeira para indicar se a saída é uma saída ou apenas o líder (zerando todos os não-líderes)
Em modelos lógicos, por exemplo, os parâmetros configuráveis estão na função de ativação. Isto também está no modelo geral?
Na camada MLP pode ser uma única bandeira de presença de neurónios.
____________________________
A propósito, o xml é muito mais fácil de verificar a validade do que a representação binária. E poupar/restaurar não é essencialmente uma questão de tempo crítico.
1. A rigor, não.
Primeiro um caso simples. Digamos que temos neurónios lineares, sigmóides e tangentes. Se quisermos adicionar um novo tipo de activação, temos de expandir a enumeração dos tipos de activação.
Basicamente, então que se lixe. Mas primeiro, porque é que, por exemplo na rede Kohonen, a camada de saída precisaria de um sinal de algumas=algumas funções de activação? Esta é uma informação desnecessária e supérflua.
Em segundo lugar, esta lista é teoricamente ilimitada.
Em terceiro lugar, cada rede pode ter as suas próprias peculiaridades de funcionamento e estrutura. Por exemplo, uma rede Kohonen (SOM) pode ter uma configuração de função vizinha e uma bandeira se a saída deve resultar como saída ou apenas como líder (zerando todos os não-líderes).
Em modelos lógicos, por exemplo, os parâmetros configuráveis estão na função de ativação. Isto também está no modelo geral?
Na camada MLP pode ser uma bandeira para ter um único neurónio.
____________________________
A propósito, o xml é muito mais fácil de verificar a validade do que a representação binária. E salvar a recuperação não é essencialmente uma questão de tempo.
1. Porque não. A minha ideia é algo do género - criar uma "base de elementos" universal a partir da qual a rede neural de qualquer tipo possa ser "soldada" (pode muito bem ser extensível). Os elementos desta base são definidos por definições exactas e inequívocas - fórmulas. Se necessário, com aplicação de pseudo-código. Mas não sob a forma de código mql, para fornecer desprendimento de implementações - elas podem ser melhoradas com o tempo. Após a base de elementos abstratos ser criada (se possível), você pode formatar o arquivo xml-, capaz de descrever todas as conexões entre os elementos. Após a aprovação da descrição em xml, o projeto pode ser facilmente paralelizado: escreva separadamente
1) Implementações de componentes. => a saída é uma biblioteca de componentes.
2) tipo/estrutura de rede configurador(es) => saída - gráfica, passo-a-passo ou qualquer outro configurador(es), salvando a configuração em arquivo xml-.
3) tradutor(es) em código mql. => a saída é ou (1) uma rede mql-neural super-duper auto-configurável, tomando um arquivo xml- como parâmetro, ou (2) um compilador para uma rede rígida baseada em mql particular.
Algo parecido com isto. Parece que faz sentido.
2. Sim.