Sistemas automaticos sí pero no autónomos

[Fibonudo]

... no se imaginar un desbordamiento de bufer porque el sistema se vuelve loco por una causa externa, que me ha ocurrido. Ahí ni funciones de control, ni ocho cuartos...

Hola Spirit,

Una solución que se me ocurre, para una contingencia como la que propones, sería que cada expert/sistema que tuvieses rulando tuviese que actualizar un flag en un servidor remoto (por ejemplo con un serialdate).

Un proceso en el servidor remoto comprobaría que se actualizasen y te avisaría en caso de problemas.

Saludos.

[Fer137]

En cuanto a lo de 'automaticos y no autonomos' no estoy de acuerdo, lo que interesa es que no haga falta estar delante de la pantalla, o lo minimo necesario, que para eso son automáticos.

Ok. ¿Tú pondrías tu sistema a funcionar el 2 de Enero y lo dejarías sin mirar hasta el 30 de Diciembre?

Lo miraría frecuentemente , pero por curiosidad de ver que tal va, y por si hay que hacer algún cambio, ajuste o lo que sea.

[zamio]

Yo aun no creo en ese tipo de sistemas, creo que y ya lo he dicho varias veces lo normal es automatizar un sistema por que no se tiene la endereza de seguir la operativa por motivos psicológicos o por que es una operativa muy densa y pesada...

Yo al menos creo que se debe de tomar como un trabajo, y si no es rentable... pues ya sabes... pero eso de dejarlo correr sin supervision, anda que no andamos listos.

Y si tu no quieres/puedes pones a otro a mirar...

Saludos.

[Fer137]

Yo aun no creo en ese tipo de sistemas, creo que y ya lo he dicho varias veces lo normal es automatizar un sistema por que no se tiene la endereza de seguir la operativa por motivos psicológicos o por que es una operativa muy densa y pesada...

No es por todo esa historia de la psicologia, es por poder dedicar el tiempo a otros asuntos.

[zamio]

Yo aun no creo en ese tipo de sistemas, creo que y ya lo he dicho varias veces lo normal es automatizar un sistema por que no se tiene la endereza de seguir la operativa por motivos psicológicos o por que es una operativa muy densa y pesada...

No es por todo esa historia de la psicologia, es por poder dedicar el tiempo a otros asuntos.

Entonces la segunda opcion es obligatoria, un sistema por muy automatico que sea no se puede quedar sin supervision tanto tiempo, requiere de ello por culpa de muchos factores, no ay nada mejor que el ojo humano.

[Gordon Geko]

La clave esta en el factor humano...........yo lo hago dividiendo el sistema en trocitos donde cada parte es ejecutada por una persona............

Esta no sabe de donde viene el imput que le obliga a tomar una decision y tampoco sabe que su output crea una orden de actuacion para otro operador.............

Con esto solucionas la imposibilidad de un algoritmo en sistemas complejos adaptativo a las condiciones de mercado............ALGO IMPOSIBLE DE PROGRAMAR...............

Tambien eliminas el factor psicologico del operador puesto que le asignas una tarea meramente funcional sin ninguna consideracion economica..........

Y por ultimo evitas lo mas importante............que nadie sepa nunca como operas y cual es el bias de tu sistema operativo...............

Por regla general esto se puede "trocear" tantas veces como el creador del sistema tome oportuno o por consideraciones de algoritmos condicionales en donde la accion del mercado de informacion suficiente para disparar una accion binaria que active a 2 personas.................

Es decir el creador esta en la cima dle triangulo y crea un algoritmo condicional que es ejecutado por operadores que no conocen el "codigo fuente" sino solo su accion en base a un imput determinado............

El numero de "trabajadores" en un algoritmo sintetico ejecutado por humanos seria de minimo 3..............donde se producen resultados muy satisfactorios...............

Cuantos mas humanos y mayor sea el troceamiento del algoritmo y tarea por humano mas eficiente sera ejecutado este....................

[Optiondreamer]

Todo dependerá de la complejidad que tengas entre manos. Si es un simple soft de trading(Ninja, Metatrader, etc..), le metes varios timer que apunten a varios procesos(recepeción/envio datos, ordenes, etc) y si éstos fallan y no estás pendiente, que te avisen, ¿cómo? via sms, e-mail, conexión directa con un smartphone, . . . hoy en día tenemos bastantes recursos en esta materia. De hecho como están hoy en día los smartphones, veo imprescindible uno con acceso remoto para cualquier contingencia que pueda surgir.
Si lo que quieres controlar es un poco más complicado que conectarte con un smartphone y tocar dos botones. Ahí pienso que deberías tener una base de datos que grabe en tiempo real todos los procesos que tienes activos, y en caso de fallo general, hacer un reset/ajuste y mediante programación de servicios, devolver todo a su estado correcto. Esto es interesante aunque estés vigilando los sistemas, porque cuando sucede ésto sueles ponerte nervioso, y si dejas en manos de un programa el restaurar todo, la recuperación del sistema es más rápida y segura.
Pienso que al ser programador, y encima tener recursos al respecto no debas tener problemas, eso sí, no es tarea fácil.

Saludos.

[cls]

Este es un caso real que me ocurrió ya hace un tiempo en Ninja con el mini-sp que por poco no se cepilló la cuenta. No tiene que ver con desconexiones o cortes de luz sino con temas de programación.

Es un sistema que opera al tick, así que con cada tick entrante se ejecuta el código de decisión.
En un instante determinado con la llegado del tick X se cumplen las condiciones de entrada. El sistema envía una orden de entrada a mercado.

POR EL MOTIVO QUE SEA EL SERVIDOR QUE RECIBE LA ORDEN NO DEVUELVE AL PROGRAMA Y AL INSTANTE EL RESULTADO DE ESA ORDEN. SUPONGAMOS UN DELAY DE 0,5s.

Al no recibir respuesta acerca de la orden sigo estando FLAT para el sistema.

Sin embargo si en ese medio segundo sigo recibiendo ticks del datafeed (que puede ser diferente al del broker o no, pero seguro que es un servidor diferente al que está enrutando la orden) la lógica de decisión seguirá enviando órdenes a mercado.
Si esto ocurre en un momento de mucha actividad de la cinta puedo encontrarme en un instante con un montón de órdenes de entrada enviadas y un probable margin call al primer tick en contra.

Esto se soluciona llevando personalmente la cuenta de las órdenes que voy enviando y pasando de las típicas variables de sistema para preguntar por tu situación en el mercado. Precisamente este problema ocurrió por confiar en esas variables de sistema ( hasta entonces lógicamente no tenía motivos para desconfiar) que informaban sobre mi posición en el mercado que me decían que estaba FLAT cuando no era así.

En cuentas demo con tr esto nunca ocurre,y obviamente en backtest tampoco.
Por fortuna el broker (Mirus Futures) se comportó excelentemente, parando todas las órdenes y no ejecutando ninguna (vieron que algo anómalo estaba ocurriendo).

Situaciones como ésta no están documentadas, y sólo te queda esperar que cuando aparezcan sobrevivas a ellas.
Desde entonces tengo claro que la operativa real tiene que ir con código propio y vía api.

S2

[Spirit]

Ya empiezo a ver que no soy el único al que le preocupan ciertos aspectos de los experts y programas. Los ejemplos últimos son muy parecidos a lo que a mi me a ocurrido. (CLS, a mi me a pasado en cuentas demo).

La vetrdad que estaría bien el que cada cual pusiera ejemp`los de fallos y bugs que ha tenido, tal y como ha hecho CLS. Da igual que los fallos sean de programación, que de ejecución, lo importante es documentarlos de forma genérica, de tal manera que los que estemos interesados en vigilar estos procesos los podamos tener en cuenta, aunque no los hayamos experimentado nunca. Sino, lo que te puedes encontrar un día es un margin-call como una catedral.

Por cierto, encomendarse a la suerte de que no te pase eso nunca, no es una solución válida para mi. Puede serlo para cuentas de chichinavo, pero no si quieres manejar una cuenta capitalizada.

Lo de los smartphone es básico, un remote en condiciones y unos servicios Web que ejecuten rutinas de emergencia son sencillos de programar.

Gordon, está bien eso de dividir el sistema en trocitos. El problema es que tú lo planteas como una forma de esconder la lógica del sistema a las partes ejecutoras. Si estas partes son programas no veo necesario esconderles nada.

[victorag]

Para sistemas swing, que hacen pocas operaciones al mes, mi objetivo de desarrollo es:

- Sistema programado desde cero, excepto el API de toma de datos (a poder ser de más de un feed) y el API de ejecución de órdenes al broker.
- Aplicaciones multihilo, autosupervisadas, tolerantes a fallos, reiniciables...
- Corriendo en dos o más servidores, en localizaciones diferentes, recibiendo datos, sincronizando información y ejecutando las mismas estrategias, todo a la vez.
- Roles de servidores, se pueden asignar uno o varios: Recopilador, Ejecutor, Estratega, Backup...
- Posibilidad de añadir, quitar, reiniciar, cambiar los roles... de los servidores en caliente. Como objetivo final, poder comprar un PC nuevo y tener todo en marcha en menos de 15 minutos.
- Control de múltiples cuentas en el broker. Posibilidad de asociar diferentes cuentas a diferentes servidores.
- Obviamente basado en servicios. Nada de tener que iniciar sesión y arrancar el software, el software arranca siempre con el encendido del servidor.
- Sistema transaccional de ejecución de órdenes. Basado en los conceptos Begin, Commit, Rollback de una base de datos.
- Comunicaciones via email, SMS... y un modo "pánico total" para que el sistema llame al broker en tu nombre y ponga en marcha una alocución para decirle que cierre todas las posiciones, pelín exagerado
- Extenso log de acciones realizadas. Absolutamente todas las acciones sobre los servidores, estrategia, cuentas, eventos, comunicaciones, errores... se graban en base de datos.

Entonces se podría intentar dormir tranquilo por las noches.

[Fer137]

Un principio basico es que cuanto mas enrevesado y mas componentes le pongas mas posibles errores puede haber. Desde la programacion a la ingenieria aeroespacial. Si para prevenir un hipotetico error abres la puerta a cien posibles errores, a partir de cierto punto todo ese trabajo puede ser contraproducente.

Por ejemplo:

- Sistema programado desde cero, excepto el API de toma de datos (a poder ser de más de un feed) y el API de ejecución de órdenes al broker.
- Aplicaciones multihilo, autosupervisadas, tolerantes a fallos, reiniciables...
- Corriendo en dos o más servidores, en localizaciones diferentes, recibiendo datos, sincronizando información y ejecutando las mismas estrategias, todo a la vez.
- Roles de servidores, se pueden asignar uno o varios: Recopilador, Ejecutor, Estratega, Backup...

Asi si por cualquier cosa falla uno tambien falla todo el conjunto.

- Comunicaciones via email, SMS... y un modo "pánico total" para que el sistema llame al broker en tu nombre y ponga en marcha una alocución para decirle que cierre todas las posiciones, pelín exagerado

Y tendrias que preparar otros sistemas para evitar los posibles imprevistos de ese. Por ejemplo con motivo o por error llama al broker y le suelta la parrafada. El empleado le saluda "Good Morning", el sistema le contesta con la clave de autentificacion o respuesta secreta, el otro dice "what do you say?", el sistema se despide cortesmente y acto seguido entra en un bucle llamando a todos los telefonos de la guia telefonica de Estados Unidos.

Entonces se podría intentar dormir tranquilo por las noches.

[zamio]

Y tan cierto lo que dices Fer, esta claro que si tanto desconfías de tu sistema, ¿ que te hace confiar en los sistemas de ayuda ?

Todo es tan susceptible de fallar, que no se puede asegurar nada, solo la "robustez" de las aplicaciones y la programación hacen que se eleve el porcentaje de fiabilidad.

Saludos.

[Fer137]

En muchos casos los errores en sistemas automaticos son neutrales. Si en un avion se apagan los motores es un problema sin duda. Si un sistema automatico se desconecta unas horas no tiene porque ser grave, a veces la desconexion producira perdidas, y en otras beneficios.

Un posible problema seria que en un sistema de scalping muy apalancado [...]

Otro posible error problematico es que abra y cierre operaciones a cada tick, fundiendose un spread [...]

[Edito y borro soluciones]

[victorag]

Un principio basico es que cuanto mas enrevesado y mas componentes le pongas mas posibles errores puede haber. Desde la programacion a la ingenieria aeroespacial. Si para prevenir un hipotetico error abres la puerta a cien posibles errores, a partir de cierto punto todo ese trabajo puede ser contraproducente.

Por ejemplo:

- Sistema programado desde cero, excepto el API de toma de datos (a poder ser de más de un feed) y el API de ejecución de órdenes al broker.
- Aplicaciones multihilo, autosupervisadas, tolerantes a fallos, reiniciables...
- Corriendo en dos o más servidores, en localizaciones diferentes, recibiendo datos, sincronizando información y ejecutando las mismas estrategias, todo a la vez.
- Roles de servidores, se pueden asignar uno o varios: Recopilador, Ejecutor, Estratega, Backup...

Asi si por cualquier cosa falla uno tambien falla todo el conjunto.

- Comunicaciones via email, SMS... y un modo "pánico total" para que el sistema llame al broker en tu nombre y ponga en marcha una alocución para decirle que cierre todas las posiciones, pelín exagerado

Y tendrias que preparar otros sistemas para evitar los posibles imprevistos de ese. Por ejemplo con motivo o por error llama al broker y le suelta la parrafada. El empleado le saluda "Good Morning", el sistema le contesta con la clave de autentificacion o respuesta secreta, el otro dice "what do you say?", el sistema se despide cortesmente y acto seguido entra en un bucle llamando a todos los telefonos de la guia telefonica de Estados Unidos.

Entonces se podría intentar dormir tranquilo por las noches.

Por esto era pelín exagerado


Sobre el primer tema, discrepo. La aplicación en sí es muy pequeña, hay pocos errores en los que pensar, comparado con un ERP cualquiera, por ejemplo.

La diferencia entre un EXE que haga todo el trabajo sin más, y añadirle unas pocas cosillas conocidas (sincronizacion, persistencia, log...), no es mucha. Es más, toda la aplicación no llevará más de 1.000 líneas de código, 20 o 30 clases, alrededor del mismo número de tablas... un mes de trabajo, sin prisa y con cuidado.

[Spirit]

Hay gente que no entiende bien el alcance que pueden tener ciertos problemas. En una ocasión tuvimos que programar una rutina para sorteos de vivienda protegida. Si a los que me contrataron les hubiera dado las respuestas que se están dando aquí les hubiera entrado la risa y por suspuesto no me hubieran contratado.

Si en uno cualquiera de los múltiples sorteos realizados con ese programa, se hubiera producido el más mínimo error y los sistemas de vigilancia no lo hubieran detectado y reparado hoy en día tendría un grave problema, los medios de comunicación la hubieran liado gorda, la oposición hubiera echado más leña al fuego y alguna cabeza gorda hubiera rodado.

Es increible con la vanalidad que hablan algunos de cuestiones que reálmente si tienen importancia. evidéntemente si un tipo opera acciones de las matildes sin palanca alguna y con operativa de tipo swing de no más de una operación al mes, todo esto le parecerá ciencia-fición.

Si planteo la pregunta o debate, es porque estoy midiendo la posibilidad de automatizar sistemas full-time que me funcionan de forma discreccional, pero son inviables e insufribles de mantener operativos sin ayudas automáticas, pero al ser full-time y correr en cuentas que permiten apalancamientos altos, aunque no se usen estos, el riesgo de ruina en caso de problemas es muy elevado. Si al final concluyo que no merece la pena tomar ese riesgo, o que no puedo minimizarlo lo suficiente, o sus costes son muy elevados, pues no lo implementaré. Pero ¿Por qué voy a desechar la idea de implementar unos sistemas que me están funcionando muy bien? Primero tendré que ver si son viables tecnológicamente hablando y luego valorar todas las posibilidades.

Por eso, me gustaría ver más respuestas del tipo de las de CLS. Es decir, no hace falta que nadie aporte soluciones, que eso es relativamente sencillo, lo jodido es conocer todos los posibles problemas que pueden aparecer. Si lo que ha dicho CLS lo paso por alto, puedo estar 3 años sin un problema, pero un día por arte de magia levantarme con la cuenta arruinada. No se si se entiende ahora mejor el planteamiento del debate que propongo.