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
72 estojos, 24 novos estojos para fins especiais, sistema de escrita não linear, gramática matricial, morfose, boustrophedon e fonética especial - exatamente o que as seitas mais legais precisam (para que os Chekists e Maçons não possam roubar o Graal).
Sim, devemos traduzir definitivamente a frase "cruzar duas médias móveis" para Ifkuil)
Devido ao fato de que o tema deste tópico é em grande parte filosófico e não se encaixa apenas nos limites do algotrading, mas também (em alguns lugares) da programação em geral, decidi completar a série de partes do conceito com uma teoria final de "algoritmo de complicação", delineando sua compreensão e respondendo à pergunta - tal algoritmo pode existir, em princípio?
Como planejado, consideraremoso "mecanismo de complicação" no exemplo de um simples marcador retangular na tela de pixels, desenhado chamando uma função gráfica que consiste em dois laços aninhados (altura e largura) e usando 5 parâmetros básicos - x, y, largura, altura, cor.
Chamaremos a função de desenho de "construtor" e seu parâmetro define o Objeto. Deve-se notar que, até onde a maioria das pessoas pensa,um Objeto é um "subconjunto" de pixels dentro do conjunto de pixels da tela, marcados por cores e montados em forma geométrica, mas para o programador, um Objeto não é apenas uma forma externa, percebida pelos olhos, mas também criando o próprio mecanismo. Uma etiqueta, como sabemos, é "construída" em dois ciclos pela função de desenho, o que significa que a função com seus parâmetros é também uma "etiqueta". Não um retângulo colorido, mas o algoritmo com parâmetros que o desenha. Este ponto é difícil de perceber, pois a pessoa está acostumada à percepção visual de uma concha de objeto e considera o código que está por trás dela como algo rebuscado e secundário, no entanto - é o próprio Objeto, afinal, no caso de qualquer mudança de implementação da função inicial ou valores de seus parâmetros, a mudança externa de uma concha inevitavelmente segue.
Acho mais fácil separar o conjunto de parâmetros de uma função de sua implementação interna e tratá-la como o Objeto principal, embora, é claro, isto não seja verdade, porque a implementação interna da função do construtor e seu conjunto de parâmetros estão inextricavelmente ligados. Entretanto, a implementação interna muda muito menos frequentemente e estas mudanças são mais fundamentais do que, digamos, mudanças nos valores do conjunto paramétrico, que são fáceis de trabalhar e de experimentar. Se o método de implementação da função construtora mudar, surge um novo conjunto paramétrico, e isto implica em mudanças em todos os "proto-blocos" construídos com base no antigo conjunto paramétrico da função construtora. Isto ése inicialmente construímos um estado alternativo da Etiqueta com 5 parâmetros:x, y, largura, altura, cor com valores diferentes e depois "habilitá-lo" em algum evento, então uma mudança inesperada do método de implementação do construtor de funções, que reduz o número de parâmetros, digamos, para 3, mudará a estrutura do conjunto paramétrico primário (do qual outros estados, eventos ou processos provavelmente já foram criados) e a construção anterior do estado alternativo da Etiqueta "colapsará", tornando-se inútil para a nova versão do construtor de funções. Aqui enfrentamos o primeiro grande obstáculo da implementação do algoritmo de complicação: o método de implementação da função-construtor estabelece limites para o potencial de complicação do Objeto. Transcender estes limites sem envolvimento humano de acordo com algum algoritmo é uma complicação automatizada.
Vamos considerar uma complicação experimental "direta" de um Rótulo sem alterar o método original de sua implementação funcional - construtor e sem entrar no sentido de complicação - vamos apenas alterar os valores de seu conjunto de parâmetros e "derivar" novos estados em sua base e ver ao que chegamos:
Conclusão:
Certamente, seria necessário escrever mais de um livro e um post não será suficiente, mas já é óbvio que se definirmos o propósito de complicação para algum programa, de modo que ele criaria modelos de Objeto com vários Estados, Eventos, reações ao ambiente, mesmo sem alterar a implementação de um design de função e contando com um conjunto paramétrico fixo, provavelmente, após a enésima quantidade de tentativas e erros, ele poderia criar um rótulo executando alguma tarefa simples, mas tal programa deveria "ser capaz" de construir "proto-blocos" - estados, eventos, Estou otimista, embora eu possa imaginar a complexidade de tal tarefa.
Olá a todos tenho um consultor especialista preciso de mais detalhes se alguém é bom nisso agora eu testei cerca de 100$ por dia em eurusd e usdchf
irá...
os objetos nela contidos são representados incorretamente :-)
PS/ falha garantida, independentemente dos objetos
Se de repente você se encontrar em um estado de espírito cognitivo, leia sobre programação genética (spoiler: você não pode passar sem Bacus-Naurus).