Representação de um objeto na programação. - página 17

Novo comentário
 
transcendreamer #:

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:

  • Escolhemos um conjunto de parâmetros para um novo estado a partir do conjunto inicial de parâmetros da função-construtor, inventamos novos valores para eles e os escrevemos no bloco de memória alocado.
  • Dado apenas um estado adicional de uma Etiqueta, encontramos automaticamente a necessidade de construir um Modelo de Evento, porque se uma Etiqueta tem pelo menos UM outro estado, ela deve em algum momento mudar para ele, e portanto precisamos descrever um evento associado ao ambiente ou outro objeto que fará com que a Etiqueta entre em um estado alternativo. Isto é, um estado recentemente adicionado logicamente requer pelo menos uma descrição de evento para mudar para um estado alternativo, e (opcionalmente) uma segunda descrição de evento para mudar de volta para o estado inicial ou algum outro estado.
  • Daí a tese simples: cada nova adição de estado ao Objeto implica a adição de pelo menos um, e de preferência dois novos eventos, cuja descrição deve ser colocada nas condições do Modelo de Eventos, que, como sabemos, é uma espécie de "mecanismo de comunicação" do Objeto e do Ambiente e descreve sua interação por sua lógica. A priori, somente a presença do SM pode mudar o Objeto entre estados. Conclusão:+ 1 Objeto Estado = +2 Objeto ou Eventos Ambientais + 2 Condições SM.
  • Adicionar Estados de Objeto implica em adicionar Eventos de Mudança de Estado de Objeto e torna-se necessário priorizar os novos Eventos, e a estrutura hierárquica é a mais adequada para isso. Simultaneamente com o aparecimento de novos Eventos e Estados, a árvore de condição cresce. O comportamento do Objeto é enriquecido por uma variedade de reações às interações externas com as coisas "envolvidas" em sua vida e deve ser dito que quanto mais longe a complexidade vai, mais amplo é o contato externo. Acontece que não podemos considerar a complicação do Rótulo isoladamente de seu Ambiente e precisamos do ambiente de interação, caso contrário os novos estados se tornarão "peso morto" na memória e o único evento possível de sua mudança será o temporizador interno.
  • Descobrimos que não faz sentido criar os estados do novo Objeto sem eventos que os liguem inseparavelmente aos objetos no ambiente, assim como não faz sentido adicionar eventos fora do Modelo de Eventos ligando-os aos estados e processos do Objeto.No processo de complicação do Objeto, é necessário adicionar tudo de uma só vez - Estados, Eventos, Condições do Modelo de Eventos (organizando-o em ordem hierárquica simultaneamente) e criar a relação Evento->Sate ou... Evento->Processo etc.
  • Adicionar um Processo de Objeto não é fundamentalmente diferente de adicionar um Estado e a única diferença é a quantidade de memória a ser alocada. O novo processo, assim como o estado, requer a definição de eventos básicos para si mesmo, tais como: eventos iniciais, eventos de mudança, eventos de parada...


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 especializado, precisa de mais trabalho, estou testando cerca de 100 dólares por dia em eurusd e usdchf
Arquivos anexados:
Screenshot_20220122-212031_MetaTrader_4.jpg  294 kb
 
Ruslan #:
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

 
Olá pessoal, podem por favor corrigir isto ;não são permitidas expressões em uma estratégia de escopo global("DailyCandleCross", shorttitle="DCC", overlay=true, calc_on_order_fills= true, calc_on_every_tick=true, default_qty_type=strategy.percent_of_equity, default_qty_value=75, pyramiding=0)
 
Quero expor minhas próprias ilusões e as dos outros (se contribuí para sua aparência involuntariamente) a respeito do chamado "algoritmo da complicação" e devolver aos leitores perspicazes a dura realidade onde o próprio universo nega quaisquer formas e variações"grail" e mostrar que meu raciocínio é um produto da mente inflamada pelo amor à filosofia e que as noites sem dormir inventam "perpetuum mobile" ou "máquina do tempo", sofrendo com a crença no próprio gênio.
O algoritmo de complicação não pode ser implementado, ou mais precisamente, sua versão "tola" pode ser implementada, onde alguns programas carimbam aleatoriamente estados paramétricos, eventos, processos e condições de algum objeto, então, na mesma aleatoriedade, os compõem uns com os outros e... as apaga e começa de novo. Esta estranha ação pode durar para sempre e não está absolutamente claro qual é o seu objetivo? Qual é o resultado? Um resultado aleatório? E lembra-se do problema com a função do construtor? Como mudar sua implementação? Não está nada claro... O problema é que a menor mudança no método de implementação destrói completamente a "legitimidade" de todas as estruturas proto-bloqueio, tornando-as inutilizáveis pela função modificada. Em suma, é uma tarefa que levará anos, assumindo que será resolvida pelo Instituto de Pesquisa ou pela Academia de Ciências, e não o fato de que, no final, algo vai dar certo.
A atmosfera deste fórum está saturada de inspiração graal e lança um estado de espírito apropriado, a partir do qual este último gera parábolas espantosas, semelhantes à ciência, que, infelizmente, nunca levam a nada prático... ...embora sejam energizantes para todos. :)
Não julgue muito severamente, eu estava apenas em um "chute filosófico"))))
 
Merda, está aumentando de novo? Ficou tudo em silêncio.
 
Реter Konow "graal", e mostrar que meu raciocínio é um produto da mente inflamada de amor à filosofia, aquela noite sem dormir inventando "perpetuum mobile" ou "máquina do tempo", sofrendo a fé no próprio gênio.
O algoritmo de complicação não pode ser implementado, ou mais precisamente, sua versão "tola" pode ser implementada, onde alguns programas carimbam aleatoriamente estados paramétricos, eventos, processos e condições de algum objeto, então, na mesma aleatoriedade, os compõem uns com os outros e... as apaga e começa de novo. Esta estranha ação pode durar para sempre e não está absolutamente claro qual é o seu objetivo? Qual é o resultado? Um resultado aleatório? E lembra-se do problema com a função do construtor? Como mudar sua implementação? Não está nada claro... O problema é que a menor mudança no método de implementação destrói completamente a "legitimidade" de todas as estruturas proto-bloqueio, tornando-as inutilizáveis pela função modificada. Em suma, é uma tarefa que levará anos, assumindo que será resolvida pelo Instituto de Pesquisa ou pela Academia de Ciências, e não o fato de que, no final, algo vai dar certo.
A atmosfera deste fórum está saturada de inspiração graal e lança um estado de espírito apropriado, a partir do qual este último gera parábolas espantosas, semelhantes à ciência, que, infelizmente, nunca levam a nada prático... ...embora seja energizante. :)
Não julgue muito severamente, eu estava apenas em um "soco filosófico"))))

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).

1...1011121314151617
Novo comentário