Discusión sobre el artículo "Programación basada en autómatas como nuevo enfoque en la creación de sistemas de trading automatizados" - página 4

 
Integer: Pero al menos tenemos algo tan universal y rápidamente reprogramable. Todo un tema para un artículo.
¿Por qué no escribes un artículo? Creo que a mucha gente le interesaría leerlo.
 
Integer:

El artículo no trata el tema en absoluto, salvo que existe un interruptor. No importa si existe o no, se puede conmutar por if's.

Una vez estaba escribiendo un EA, había un sistema muy complejo con órdenes. Tuve que analizarlo seriamente y hacer una lista de estados: sin órdenes, una pendiente, una orden de mercado, dos órdenes pendientes, una pendiente y una orden de mercado, etc. Sólo así conseguí superarlo. Pero resultó ser algo tan universal y rápidamente reprogramable. Todo un tema para un artículo.

También prefiero utilizar el habitual si. En general, hay dos enfoques: con la ayuda de if y con la ayuda de funciones especiales que son llamados por el interruptor de estado del interruptor. La cuestión es qué enfoque es mejor / más simple.
 
Rosh:
Entonces, ¿podrías escribir un artículo? Creo que mucha gente estaría interesada en leerlo.

Vale, lo haré.

 
C-4:
Yo también prefiero utilizar un if normal. En general, hay dos enfoques: con la ayuda de if y con la ayuda de funciones especiales que son llamados por el interruptor de estado del interruptor. La cuestión es qué enfoque es mejor / más simple.

Es necesario mirar el tema, el contador es más rápido en la elección de una solución, pero if es más fácil de llamar.

Si hay muchos contadores anidados, entonces if funcionará más rápido, porque una llamada a if es más barata que una llamada a switch.

Pero si hay múltiples soluciones en cada nivel, switch es más apropiado.

 
abolk:

Esto es algo nuevo. CUALQUIER TS (sin excepción) se basa en el análisis y la comprensión clara de los estados de la TS. Los estados más simples: el procesamiento de señales para abrir/cerrar/modificar una orden, etc. etc.

Si "el estado actual del Asesor Experto no se conoce claramente", entonces definitivamente no es un Asesor Experto, y definitivamente no es un programa, y la palabra "algoritmo" en relación a un Asesor Experto debería ser tachada y olvidada para siempre.

La información del mercado llega tarde, puede haber (y probablemente hay) errores en el software en el servidor y en el ordenador, las órdenes pueden no ejecutarse debido a un millón de razones, la red - conexión con el proveedor puede parpadear, la electricidad puede cortarse en cualquier momento (recuerde fallos y reinicios en el campeonato). Hay factores de incertidumbre más que suficientes. Y un Asesor Experto o un algoritmo debe tenerlo todo en cuenta. Es imposible contar con el perfecto funcionamiento del servidor, software, comunicación, mercado, operador, electricidad.

Así que el estado actual de las órdenes, el mercado, la comunicación, la electricidad nunca es conocido por el Asesor Experto, y el Asesor Experto o algoritmo debe seguir funcionando correctamente en condiciones difusas.

 
Virty:

la información del mercado llega tarde, puede haber (y probablemente haya) errores en el software del servidor y en el ordenador, las órdenes pueden no ejecutarse por un millón de razones, la red -la conexión con el proveedor- puede parpadear, la electricidad puede cortarse en cualquier momento (recuerde los fallos y reinicios en el campeonato). Hay factores de incertidumbre más que suficientes. Y un Asesor Experto o un algoritmo debe tenerlo todo en cuenta. Es imposible contar con el perfecto funcionamiento del servidor, software, comunicación, mercado, operador, electricidad.

Así que el estado actual de las órdenes, el mercado, la comunicación, la electricidad nunca es conocido por el Asesor Experto, y el Asesor Experto o algoritmo debe seguir funcionando correctamente en condiciones difusas.

Tonterías. Mezclar todo en un gran montón.

- comprobación de posibles retrasos en la cotización; - negativa del broker a ejecutar una orden; - reinicio anormal del EA - son estados claros y definidos del EA - como resultado de la identificación de cada uno de tales estados - cumplimiento de la función correspondiente

- si alguna función no se proporciona en respuesta a algún estado posible - no significa "condición de trabajo difusa" - simplemente el EA no analiza (de acuerdo con su algoritmo claro e inequívoco) este estado.

Cualquier programa (incluyendo un Asesor Experto) funciona de acuerdo a un algoritmo predeterminado claro. Y no hay acciones difusas e indefinidas en el trabajo de cualquier programa. De lo contrario, será un estado de "congelación". Y la "congelación" de un programa es, como sabemos, un error de algoritmo, no una consecuencia de la vaguedad etérea.

 
Virty:
Para los Asesores Expertos reales es imposible definir el Estado sin ambigüedades. El estado interno se determina sin ambigüedades, pero el estado de las posiciones en el servidor puede ser desconocido, conocido con un retraso, estar en un estado poco claro (algunas órdenes y peticiones se ejecutan, y otras no, y el infierno sabe por qué).
Virty:
Hay factores de incertidumbre más que suficientes. Y un Asesor Experto o un algoritmo debe tenerlo todo en cuenta. Es imposible contar con un trabajo perfecto del servidor, software, comunicación, mercado, operador, electricidad. Por lo tanto, el estado actual de las órdenes, el mercado, la comunicación, la electricidad nunca es conocido por el Asesor Experto en general.

No hay incertidumbres. Hay errores de un programador que no tuvo en cuenta algo.

"No se sabe", "en un estado poco claro" son estados de pleno derecho como todos los demás. Por supuesto, hay que tenerlos en cuenta, si no, no hay otro remedio.

Si escribes la línea "c = a + b", se trata de programación teórica, que sólo es aceptable en las clases de la escuela. Pero cuando se programa una planta industrial real, una operación útil como "c = a + b" requiere 100500 operaciones de comprobación para confirmar que una entrada es realmente "a", otra entrada es realmente "b", y también hay que asegurarse de que "a" y "b" no han cambiado durante la suma, y si de repente "c" no llegara a la salida, la operación debería reconocerse como incorrecta y todo debería retrocederse, etc.etc. Bienvenido al mundo real ))))

 
bas:

No hay incertidumbres. Hay errores de un programador que no tuvo en cuenta algo.

"No se sabe", "en estado poco claro" - son Estados de pleno derecho como todos los demás. Por supuesto, hay que tenerlos en cuenta, si no, no hay otro remedio.

Si escribes la línea "c = a + b", se trata de programación teórica, aceptable sólo en las clases de la escuela. Pero cuando se programa una planta industrial real, una operación útil como "c = a + b" requiere 100500 operaciones de comprobación para confirmar que una entrada es realmente "a", otra entrada es realmente "b", y también hay que asegurarse de que "a" y "b" no han cambiado durante la suma, y si de repente "c" no llegara a la salida, la operación debería reconocerse como incorrecta y todo debería retrocederse, etc.etc. Bienvenido al mundo real )))).

Es una buena analogía. )) Pero dicho esto, hay que recordar que sigue siendo imposible tenerlo todo en cuenta. Incluso la naturaleza comete errores y se equivoca en forma de mutaciones. Pero es necesario luchar por la perfección, por supuesto. ))
 
tol64:
Es una buena analogía. )) Pero con todo esto, no hay que olvidar que de todos modos es imposible dar cuenta de todo. Incluso la naturaleza comete errores y se equivoca en forma de mutaciones. Pero hay que aspirar a la perfección, por supuesto. ))

La naturaleza no comete errores porque le importa un bledo. Somos nosotros los que elaboramos teorías justificativas.

Y la naturaleza es algo inconsciente, y por tanto no sigue quién tiene razón y quién es culpable.

 
Urain:

...

Y la naturaleza es inconsciente y por lo tanto ...

Bueno, eso también es una teoría y no lo sabemos con certeza. )))