Representación de un objeto en la programación. - página 17

[Aleksey Nikolayev]

transcendreamer #:

72 casos, 24 nuevos casos de uso especial, sistema de escritura no lineal, gramática matricial, morfosintaxis, boustrophedon y fonética especial: justo lo que necesitan las sectas mercantiles más cool (para que los chekistas y los masones no puedan robar el Grial).

Sí, definitivamente deberíamos traducir la frase "cruzar dos medias móviles" en Ifkuil)

[Реter Konow]

Debido al hecho de que el tema de este tema es en gran medida filosófico y no encaja no sólo en los límites de algotrading, sino también (en algunos lugares) la programación en general, decidí completar la serie de partes del concepto con una teoría final de "algoritmo de complicación", esbozando su comprensión y respondiendo a la pregunta - ¿puede tal algoritmo existir en principio?

Según lo previsto, consideraremosel "mecanismo de complicación" en el ejemplo de un simple marcador rectangular en la pantalla de píxeles, dibujado llamando a una función gráfica que consiste en dos bucles anidados (altura y anchura) y utilizando 5 parámetros básicos - x, y, anchura, altura, color.

Llamaremos a la función de dibujo "constructor" y a su parámetro "Object". Hay que tener en cuenta que, en opinión de la mayoría de la gente,un objeto es un "subconjunto" de píxeles dentro del conjunto de píxeles de la pantalla, marcado por el color y ensamblado en forma geométrica, pero para el programador, un objeto no es sólo una forma externa, percibida por el ojo, pero también creando el propio mecanismo. Una etiqueta, como sabemos, es "construida" en dos ciclos por la función de dibujo, lo que significa que la función con sus parámetros es también una "etiqueta". No es un rectángulo de color, sino el algoritmo con parámetros que lo dibuja. Este punto es difícil de comprender, ya que la persona está acostumbrada a la percepción visual de una cáscara de objeto y considera el código que está detrás de ella como algo lejano y secundario, sin embargo - es el Objeto mismo, después de todo en caso de cualquier cambio de implementación de la función inicial o los valores de sus parámetros el cambio externo de una cáscara sigue inevitablemente.

Me parece más fácil separar el conjunto de parámetros de una función de su implementación interna y tratarlo como el Objeto principal, aunque por supuesto esto no es cierto, porque la implementación interna de la función constructora y su conjunto de parámetros están inextricablemente unidos. Sin embargo, la implementación interna cambia con mucha menos frecuencia y estos cambios son más fundamentales que, por ejemplo, los cambios en los valores del conjunto paramétrico, con los que es fácil trabajar y experimentar. Si el método de implementación de la función constructora cambia, entonces surge un nuevo conjunto paramétrico, y esto implica cambios en todos los "protobloques" construidos sobre la base del antiguo conjunto paramétrico de la función constructora. Es decirsi hemos construido inicialmente un estado alternativo de la Etiquetacon 5 parámetros:x, y, anchura, altura, color con diferentes valores y luego lo "habilitamos" en algún evento, entonces un cambio inesperado del método de implementación de la función-constructor, que reduce el número de parámetros, digamos, a 3, cambiará la estructura del conjunto paramétrico primario (a partir del cual probablemente ya se han creado otros estados, eventos o procesos) y la construcción anterior del estado alternativo de la Etiqueta se "colapsará", volviéndose inútil para la nueva versión de la función-constructor. Aquí nos encontramos con el primer gran obstáculo de la aplicación del algoritmo de complicación: el método de aplicación de la función-constructor establece límites al potencial de complicación del Objeto. Traspasar estos límites sin participación humana según algún algoritmo es una complicación automatizada.

Consideremos una complicación experimental "directa" de una Etiqueta sin cambiar el método original de su implementación del constructor de funciones y sin entrar en el sentido de la complicación - sólo cambiaremos los valores de su conjunto de parámetros y "derivaremos" nuevos estados sobre su base y veremos a qué llegamos:

• Elegimos un conjunto de parámetros para un nuevo estado del conjunto inicial de los parámetros del constructor de la función, inventamos nuevos valores para ellos y los escribimos en el bloque de memoria asignado.

• Dado un solo estado adicional de una Etiqueta, nos encontramos automáticamente con la necesidad de construir un Modelo de Eventos, porque si una Etiqueta tiene al menos UN otro estado, debe en algún momento cambiar a él, y por lo tanto necesitamos describir un evento asociado con el entorno u otro objeto que hará que la Etiqueta entre en un estado alternativo. Es decir, un nuevo estado añadido requiere lógicamente al menos una descripción de evento para cambiar a un estado alternativo, y (opcionalmente) una segunda descripción de evento para volver al estado inicial o a algún otro estado.

• De ahí una tesis sencilla: cada nueva adición de estado al Objeto conlleva la adición de al menos uno, y preferiblemente dos nuevos eventos, cuya descripción debe colocarse en las condiciones del Modelo de Eventos, que, como sabemos, es una especie de "mecanismo de comunicación" del Objeto y el Entorno y describe su interacción mediante su lógica. A priori, sólo la presencia de SM puede hacer que el Objeto cambie de estado. Conclusión:+ 1 Estado de Objeto = +2 Eventos de Objeto o Entorno + 2 condiciones de SM.

• La adición de estados de objeto conlleva la adición de eventos de cambio de estado de objeto y se hace necesario priorizar los nuevos eventos, y la estructura jerárquica es la más adecuada para ello. Simultáneamente con la aparición de nuevos Eventos y Estados, el árbol de condiciones crece. El comportamiento del Objeto se enriquece con una variedad de reacciones a las interacciones externas con las cosas "involucradas" en su vida y hay que decir que cuanto más avanza la complejidad, más amplio es el contacto externo. Resulta que no podemos considerar la complicación de la Etiqueta aislada de su Entorno y necesitamos el entorno de interacción, de lo contrario los nuevos estados se convertirán en "peso muerto" en la memoria y el único evento posible de su cambio será el temporizador interno.

• Hemos descubierto que no tiene sentido crear los estados del nuevo Objeto sin eventos que los vinculen inseparablemente con los objetos del entorno, al igual que no tiene sentido añadir eventos fuera del Modelo de Eventos que los vinculen con los estados y procesos del Objeto.En el proceso de complicación del Objeto, es necesario añadir todo a la vez - Estados, Eventos, condiciones del Modelo de Eventos (organizándolo en orden jerárquico simultáneamente) y crear la relación Evento->Estado o... Evento->Proceso, etc.

• Añadir un proceso de objeto no es fundamentalmente diferente de añadir un estado y la única diferencia es la cantidad de memoria que se debe asignar. El nuevo proceso, al igual que el estado, requiere la definición de eventos básicos para sí mismo, tales como: start-events, switch-events, stop-events...

Conclusión:

Ciertamente, la divulgación de este tema requeriría más de un libro y un post obviamente no es suficiente, pero ya es obvio que si definimos el objetivo de complicar algún programa, para que cree modelos de Objetos con diferentes Estados, Eventos, reacciones al entorno, incluso sin cambiar la implementación de una función constructora y confiando en un conjunto de parámetros fijos, probablemente, podría crear una etiqueta realizando alguna tarea simple a través de la enésima cantidad de prueba y error, pero tal programa debería "ser capaz" de construir "protobloques" - estados, eventos, Soy optimista, aunque puedo imaginar la complejidad de tal tarea.

[Ruslan]

Hola a todos, tengo un Asesor Experto, estoy probando unos 100 dólares al día en eurusd y usdchf

[Maxim Kuznetsov]

Ruslan #:
Hola a todos tengo un asesor experto necesito más detalles si alguien es bueno en esto ahora pruebo unos 100$ al día en eurusd y usdchf

será...

los objetos que contiene están mal representados :-)

PS/ se garantiza el fracaso, independientemente de los objetos

[saniok88]

Hola chicos, podéis arreglar esto ;las expresiones no están permitidas en un ámbito global strategy("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)

[Реter Konow]

Quiero desenmascarar mis propias ilusiones y las de los demás (si es que he contribuido a su aparición involuntariamente) en relación con el llamado "algoritmo de la complicación" y devolver a los agudos lectores a la dura realidad en la que el propio universo niega cualquier forma y variación"grial" y mostrar que mi razonamiento es producto de la mente inflamada por el amor a la filosofía y que las noches de insomnio inventando el "perpetuum mobile" o la "máquina del tiempo", sufren por la creencia en el propio genio.

El algoritmo de complicación no puede ser implementado, o más exactamente, puede ser implementada su versión "tonta", donde algún programa estampa aleatoriamente estados paramétricos, eventos, procesos y condiciones de algún objeto, luego, en la misma aleatoriedad, los compone entre sí y... los borra y comienza de nuevo. Esta extraña acción puede durar eternamente y no está en absoluto claro cuál es su objetivo. ¿Cuál es el resultado? ¿Un resultado aleatorio? ¿Y recuerdas el problema de la función constructora? ¿Cómo cambiar su aplicación? No está nada claro... El problema es que el más mínimo cambio en el método de implementación destruye por completo la "legitimidad" de todas las estructuras de proto-bloque, haciéndolas inutilizables por la función modificada. En definitiva, se trata de una tarea que llevará años, dando por hecho que será resuelta por el Instituto de Investigación o la Academia de Ciencias, y no el hecho de que al final algo funcione.

El ambiente de este foro está saturado de inspiración grial y arroja un estado de ánimo apropiado, a partir del cual éste genera parábolas asombrosas y científicas que, por desgracia, nunca conducen a nada práctico, aunque... ...aunque es energizante. :)

No juzgues con demasiada dureza, sólo estaba en una "patada filosófica"))

[[Eliminado]]

Mierda, ¿se está intensificando de nuevo? Se ha quedado en silencio.

[Aleksey Nikolayev]

Реter Konow "grial", y demostrar que mi razonamiento es producto de la mente inflamada de amor a la filosofía, que no duerme en las noches inventando el "perpetuum mobile" o la "máquina del tiempo", sufriendo la fe en el propio genio.

El algoritmo de complicación no puede ser implementado, o más exactamente, puede ser implementada su versión "tonta", donde algún programa estampa aleatoriamente estados paramétricos, eventos, procesos y condiciones de algún objeto, luego, en la misma aleatoriedad, los compone entre sí y... los borra y comienza de nuevo. Esta extraña acción puede durar eternamente y no está en absoluto claro cuál es su objetivo. ¿Cuál es el resultado? ¿Un resultado aleatorio? ¿Y recuerdas el problema de la función constructora? ¿Cómo cambiar su aplicación? No está nada claro... El problema es que el más mínimo cambio en el método de implementación destruye por completo la "legitimidad" de todas las estructuras de proto-bloque, haciéndolas inutilizables por la función modificada. En definitiva, se trata de una tarea que llevará años, dando por hecho que la resolverá el Instituto de Investigación o la Academia de Ciencias, y no el hecho de que al final algo funcione.

El ambiente de este foro está saturado de inspiración grial y arroja un estado de ánimo adecuado, a partir del cual éste genera parábolas asombrosas y científicas que, por desgracia, nunca conducen a nada práctico, aunque... ...aunque es energizante. :)

No juzgues con demasiada dureza, sólo estaba en un "golpe filosófico"))

Si de repente te encuentras en un estado de ánimo cognitivo, lee sobre la programación genética (spoiler: no puedes prescindir de Bacus-Naurus).