O "New Neural" é um projecto de motor de rede neural Open Source para a plataforma MetaTrader 5. - página 63
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
...
A propósito, 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.
O que você vê como a dificuldade de verificar na representação binária dos links?
Dá-me um exemplo de quando é difícil.
ZZZ não só não consigo pensar num exemplo, como nem sequer consigo imaginar que tipo de topologia é, que ao representar links por uma tabela binária, é difícil verificar a validade de qualquer link.
Dá-me um exemplo de quando é difícil.
Olha. Você mudou um pouco o formato de armazenamento ou os dados ficaram confusos e digamos que em vez de um tamanho de matriz você obtém a parte de baixo do duble, ou seja, uma matriz de tamanho enorme.
E no xml você tem o tamanho embrulhado em uma etiqueta
1. Porque não.
Porque não há uma base universal. São apenas as três grelhas que me lembrei.
Olha. Você mudou um pouco o formato de armazenamento ou os dados ficaram confusos e digamos que em vez de um tamanho de matriz você obtém o fundo do dubble, ou seja, uma matriz de tamanho enorme.
E no xml você tem o tamanho embrulhado em uma etiqueta
"Mudou um pouco o formato de armazenamento" soa como mudar xml para avi e não reparar nele.
Qualquer mudança de formato é tratada por alguém bem versado em ambos os formatos, + quando a mudança de formato de depuração e teste é inevitável.
Portanto, uma pequena mudança no formato de armazenamento não pode ser considerada um argumento.
Sobre dados extraviados (bem, armazenar os dubles e sunlongs juntos eu desencorajei e corrigi), para evitar o extraviamento escreva hash sum para verificar a correção do arquivo lido, outras opções quando os dados podem se desviar não prevêem.
por isso temos um formato para armazenar uma matriz flutuante com informação de grelha:
[soma de hash] [número de camadas]
[tipo de camada] [número de neurónios]
[tipo de camada] [número de neurónios]
[tipo de camada] [número de neurónios]
[tipo de camada] [número de neurónios]
[tipo de camada] [número de neurónios]até o final do arquivo ulong's que definem a tabela binária.
Como converter ulong para [64] boolean character array Eu tenho uma função pronta.
Porque não há uma base universal. São apenas as três grelhas que me lembrei.
Não concordo, mas não vou discutir agora, responderei mais tarde (um ou dois dias) quando tiver os factos em mãos.
você vai tentar bombardear a minha teoria ao mesmo tempo :)
Merda... Talvez eu não entenda. Porque é que tens de compensar a tua própria dor de cabeça?
Você não é o único que não entende :)
Imho, o formato binário é uma manilha, prendendo os dados à implementação, algo de que você deve se livrar o mais rápido possível em um design competente. O formato binário é bom para embalar dados. Por exemplo, os dados MT4 armazenados dessa forma. Mas foi razoavelmente feito lá para reduzir a carga na rede, e o escritor/leitor é um desenvolvimento interno.
Mas por que se preocupar com tal elaboração? Para escrever o seu próprio editor para este formato e ter mais problemas com ele? xml, json, ou mesmo ini seria melhor
Você não é o único no meio do mal-entendido :)
Imho, o formato binário é uma manilha, encadeando os dados à implementação, algo que precisa ser livrado o mais rápido possível em um design competente. O formato binário é bom para embalar dados. por exemplo, no MT4 os dados eram armazenados assim. Mas é razoavelmente feito lá para reduzir a carga na rede, e o escritor/leitor é um desenvolvimento interno.
E por que se preocupar com tal elaboração? Para escrever o seu próprio editor para este formato e ter mais problemas com ele? xml, json, ou mesmo ini será melhor.
Sugira outra implementação, não sou contra, vamos discutir, comparar e decidir o que é melhor.
Até agora eu vi uma proposta na linha (minha), as outras apenas dizem "vamos fazer xml, json, ini", mas ninguém disse como o carregamento da grade será implementado a partir de tudo isso.
A tabela de links binários é bastante simples de entender, indo por colunas que você recebe quem enviar, indo por linhas que você recebe para quem enviar (ou vice-versa, já que a tabela é quadrada, você só precisa concordar como levá-la).
E como será implementado em outros formatos, ninguém diz nada.
Fala mais alto.
A este ritmo os seus filhos vão concordar e parar em xml , os netos vão começar a implementar .
Vote ou escolha um ancião.
A este ritmo os seus filhos vão concordar e parar em xml , os netos vão começar a implementar .
Vote ou escolha um ancião .
O que votar se não for proposta alternativa, tenho uma descrição da ideia geral do algoritmo de carregamento da grelha, o melhor formato para armazenar este algoritmo no caixote do lixo.
Outras sugestões de algoritmos de carregamento nevidal, visto apenas propostas de formato de armazenamento, mas o próprio formato de armazenamento deve ser escolhido com base no algoritmo a carregar, para um algoritmo um formato é melhor para outro.
Haverá sugestões de algoritmos, haverá também uma discussão substantiva sobre o que é melhor e em que formato é melhor armazenar.