Reunir un equipo para desarrollar una OI (árbol/bosque de decisiones) en relación con las estrategias de tendencia - página 18
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Así que el equipo se cancela. )
Y habrá un grupo administrado. )
La administración de un equipo ya establecido tiene un 95% de posibilidades de acabar con el resultado.
Y para administrar algo que no existe, hay que tener una baza muy poderosa. ))
Es hora de mostrar algunos triunfos.
Hay una oferta, pero no hay expresión de la demanda en ninguna forma.
Si en esta fase los posibles miembros del equipo no están dispuestos a ser proactivos, no estoy seguro de su motivación.
Es muy lamentable.
Sin administración no se puede avanzar - he propuesto un esquema en el que los propios participantes eligen la dirección de la marcha, es difícil imaginar las condiciones más cómodas.
De esa lista, ni siquiera los republicanos de GitLab se registraron...
El equipo debería haber sido construido bajo la licencia Apache 2.0 de inmediato, y usted quería obligar a los extraños a cumplir con la ética cooperativa.
Bueno, el jefe no sabe nada de desarrollo de software.
El registro es cuestión de minutos, es una mera formalidad.
El equipo debe trabajar en beneficio de sí mismo y de todos los miembros del equipo, y no hurgar en el estado de ánimo.
Desarrollar ideas y codificarlas son cosas diferentes.
El registro es cuestión de minutos; es una mera formalidad.
El equipo debe trabajar en beneficio de sí mismo y de todos los miembros del equipo, y no tocarse las narices cuando le apetezca.
Desarrollar ideas y codificarlas son cosas diferentes.
Si es un "trabajo de minutos", ¿por qué no se hace? No hay espacio de trabajo porque no hay equipo. No hay equipo porque no hay espacio de trabajo...
Y en este ámbito, la idea debería aplicarse inmediatamente, al menos en pseudocódigo.
Si es un "asunto de minutos", ¿por qué no se hace? No hay espacio de trabajo porque no hay equipo. No hay equipo porque no hay espacio de trabajo...
Y en este ámbito, la idea tiene que aplicarse inmediatamente, al menos en pseudocódigo.
El equipo no existe porque la gente no quiera trabajar junta; todos (la mayoría) están interesados en escuchar las ideas de los demás, y el formato propuesto por Maxim -la sala de chat- es el adecuado para ello.
Tal vez en la etapa actual de desconfianza y miedo a revelar sus propias ideas es una variante de la comunicación de interés.
Antes de hacer algo, hay que entender cómo será al final: debe haber un plano; sugerí que la gente expresara sus opiniones sobre la organización del proceso de trabajo: cómo lo quieren, cómo lo ven, y luego organizar el espacio de trabajo teniendo en cuenta estos deseos.
Ciudadanos: ¡todo está en nuestras manos!
El mercado no es un lugar para resolver problemas psicológicos personales, sino un campo para generar ingresos.
No puedes mover esta cosa por tu cuenta.
Entonces, todo está mezclado: ¿el motor del foro es multifuncional? He leído sobre REST, pero es una arquitectura desnuda, ¿debo buscar el código fuente del foro para ello?
¿Qué quieres decir con que puedes reproducir otros guiones, dónde puedes reproducirlos? Imagínate que quieres vender el producto a un usuario normal y corriente y explicarle a un humano lo que da y con qué va, por favor. Creo que es necesario e importante, pero no veo por qué, gracias.
Lo que hay que explicar, arriba te mostré un ejemplo de cómo acceder desde el script MQL a Python instalado en el ordenador local, entrenar el modelo de red neuronal, guardarlo en un archivo, cargarlo y trabajar con él llamando al método Predict.
https://www.mql5.com/ru/forum/261479/page16#comment_8011085
Puedes utilizar el mismo patrón para crear cualquiera de los cientos de modelos IO disponibles en las bibliotecas de python y entrenarlo con tus datos. Utilizando el mismo ejemplo, puede crear una parte cliente en un EA o indicador, que cargará el archivo del modelo durante la inicialización y luego lo sondeará llamando al método Predict con sus propios datos actuales.
La compatibilidad con los protocolos NamedPipes y REST permite que los scripts especificados, los Asesores Expertos o los indicadores funcionen sin DLL con los modelos de MO, tanto en el ordenador local como de forma remota en la red.
A diferencia de NamedPipes cuando se utiliza el texto del script REST no debe enviarse a través de FileWriteString, sino a través de WebRequest a una URL pública, por ejemplo en el VPS donde se ejecuta el motor, por lo demás es lo mismo.
Lo que hay que explicar, arriba te mostré un ejemplo de cómo llamar desde el script MQL a Python instalado en el ordenador local, entrenar el modelo de red neuronal, guardarlo en un archivo, cargarlo y trabajar con él llamando al método Predict.
https://www.mql5.com/ru/forum/261479/page16#comment_8011085
Usando el mismo patrón puedes crear cualquiera de los cientos de modelos disponibles en las librerías MO de Python y entrenarlos con tus datos. Utilizando el mismo patrón se puede crear una parte cliente en un Asesor Experto o indicador, que cargará el archivo del modelo durante la inicialización, y luego lo sondeará llamando al método Predict con sus propios datos actuales.
La compatibilidad con los protocolos NamedPipes y REST permite que los scripts especificados, los Asesores Expertos o los indicadores funcionen sin DLL con los modelos de MO, tanto en el ordenador local como de forma remota en la red.
A diferencia de NamedPipes cuando se utiliza el texto del script REST no debe enviarse a través de FileWriteString, sino a través de WebRequest a una URL pública, por ejemplo en el VPS donde se ejecuta el motor, por lo demás es lo mismo.
En general es claro, una herramienta para activar un modelo calculado.
Pero todavía no entiendo cómo tratar con el optimizador de estrategias...
Dejaré mis reflexiones sobre los árboles, por si resultan útiles.
Foro sobre comercio, sistemas de comercio automatizados y prueba de estrategias de comercio
Aprendizaje automático en el trading: teoría y práctica (Trading and Beyond)
Aleksey Vyazmikin, 2018.07.10 14:18
Ayer se me ocurrió una idea, ¿por qué buscamos árboles de decisión, es decir, un modelo que describa una entidad? Es decir, ¿para qué necesitamos describir toda la entidad, tal vez deberíamos limitarnos a buscar las partes de esa entidad que sean más comprensibles y predecibles? Pensé que, puesto que estoy recogiendo hojas de árboles, tal vez debería utilizar un método para encontrar dichas hojas sin construir un árbol de decisión completo, lo que debería, según tengo entendido, proporcionar un aumento de la calidad por la misma cantidad de tiempo computacional empleado.
He buscado en Internet y no veo ese método en ningún sitio. ¿Quizás alguien sepa de estos desarrollos?
Mientras elaboro el algoritmo, creo que en primer lugar tengo que seleccionar los predictores, que muestran la capacidad de predicción de una de las clases, en eso los predictores deben ser binarios (para eso tengo que formar mi propia muestra para cada predictor o formar márgenes de exclusión de la muestra general (¿qué es más razonable?)). A continuación, ya utilizar los predictores seleccionados (y sus combinaciones) para construir stubs para una clase particular (en mi caso 3 clases), y luego utilizar estos stubs para construir los predictores restantes. Al mismo tiempo, también podemos comprobar si tienen preferencia por una determinada clase. A continuación, según la idea, encontraremos las zonas más aptas para la clasificación de las clases objetivo específicas. Y el área restante será sólo un campo de inactividad/expectativa.
Por supuesto, podemos ver entonces dónde se superponen las hojas y hacer un resultado medio en estos casos. Y podemos construir un árbol así, pero con elementos de votación debido a la densidad en diferentes áreas de diferentes objetivos.
¿Qué le parece esta idea?
Dejaré mis reflexiones sobre los árboles por si resultan útiles.
Muchos expresan aquí pensamientos - ideas, algunos ofrecen mecanismos - algoritmos e incluso a veces llegan a la realización - programas listos, pero lamentablemente no hay progreso, no hay resultados prácticos, básicamente todo termina con inundaciones y declaraciones sin fundamento.
Tal vez sea porque no tenemos una presentación unificada de las herramientas de la OI de comercio: el formato de los datos, los modelos y la evaluación objetiva de los resultados, lo que no nos permite comunicarnos entre nosotros de forma constructiva, compartir los resultados de los experimentos y sacar conclusiones razonables.
Y qué sentido tiene esta situación si no disponemos de métodos de evaluación objetiva incluso de un actor individual, un desarrollador).
Tal vez deberíamos empezar por crear y acordar dichos métodos. Se intentó plantear esta cuestión en el hilo de MdD, pero hasta ahora no ha habido entendimiento mutuo; tal vez tú, como entusiasta de este tema, puedas hacer algo.
Muchas personas expresan aquí sus pensamientos - ideas, algunos ofrecen mecanismos - algoritmos y a veces incluso llegan a la aplicación - programas ya hechos, pero desgraciadamente no hay progreso, no hay resultados prácticos, básicamente todo termina con inundaciones y declaraciones infundadas.
Tal vez sea porque no tenemos una presentación unificada de las herramientas de la OI de comercio: el formato de los datos, los modelos y la evaluación objetiva de los resultados, lo que no nos permite comunicarnos entre nosotros de forma constructiva, compartir los resultados de los experimentos y sacar conclusiones razonables.
¿Y qué sentido tiene esta situación si no disponemos de métodos de evaluación objetiva ni siquiera de un ejecutante individual, un desarrollador)?
Tal vez deberíamos empezar por crear y acordar tales métodos; hubo un intento de plantear esta cuestión en el hilo de MdD, pero hasta ahora no ha habido entendimiento mutuo; ¿quizás tú, como entusiasta de este tema, puedas hacer algo?
Estoy de acuerdo en que las valoraciones estándar no son adecuadas, ya he escrito sobre esto antes. Esto es especialmente obvio si hablamos de una estrategia de tendencia. Es mejor buscar los criterios de evaluación óptimos en una estrategia básica, y luego trasladarla a otras estrategias. Tal y como yo lo veo, la rama de MO intenta principalmente predecir cómo cerrará el bar en su apertura. Y la métrica de conjetura/no conjetura puede seguir siendo apropiada en este caso, pero incluso ahí, por no hablar de las estrategias de tendencia, los puntos también deberían tenerse en cuenta en la estimación.
Aquí en la imagen de abajo, los puntos de entrada en el cuadrado 1 serán mucho mejores (traerán más beneficios) que en el cuadrado 2 donde habrá beneficios, mientras que en el cuadrado 3 cerraremos con pérdidas cuando se venda el activo, pero no traerá beneficios cuando se compre el activo hasta que se forme el precio mínimo.
Así, se puede ver que el porcentaje de aciertos de entrada puede ser grande, pero si este valor grande está más concentrado en la segunda plaza que en la primera, entonces el valor más pequeño de los errores puede anular todo el beneficio.
Por eso ahora quiero tener en cuenta en la evaluación de mi modelo la concentración de señales, en qué zona dan más beneficios o pérdidas y tenerlo en cuenta a la hora de construir el árbol de decisión.