Aprendizaje automático en el trading: teoría, práctica, operaciones y más - página 1196
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
¡Bonito!
Pregunta como especialista en Python, dame algo en Python para experimentar, casi he descubierto Sharp, se enlaza con MT5 sin ningún problema, se supone que C# y Python son compatibles, entonces puedo pasarme a Python también ;)
Python no tiene NADA que ver con nuestro problema. Python es un montón de todo y cualquier cosa que pueda sernos útil, una subtrama palurda con versiones oscuras que no son compatibles de arriba a abajo. El soporte de Python es puramente rústico, en los entusiastas. Las rúbricas de paquetes aceptables en Python no existen como tales. Todo lo que hay que encontrar en Python es una búsqueda en el foro, por parte de los entusiastas.
Esto es especialmente claro cuando se compara Python con R. No hay ningún problema para encontrar las herramientas que necesita. Cada paquete está bien documentado: descripciones de las llamadas a las funciones, enlaces a los algoritmos que las implementan, ejemplos, enlaces a artículos relacionados con el paquete... R puede utilizarse como libro de texto sobre cualquier problema. Y todo el material es absolutamente concreto, respaldado por el código correspondiente.
Python no tiene ni puede tener ventaja sobre R porque todo lo que nos interesa está escrito en Cp, mientras que Python o R son los shells de estos paquetes. A veces Python se adelanta a la aparición de nuevos paquetes debido a la completa falta de requisitos en el diseño de los paquetes y su posterior soporte. Todo lo que aparece en los espejos de R se modera y se filtra la basura.
La otra cara de R es Srr, el propio R está escrito en Srr, tiene una interfaz perfectamente documentada entre R y Srr. Por lo tanto, siempre es posible abandonar el shell de R y utilizar directamente la propia herramienta, escrita en Srr, desde los programas en MCL.
Una última cosa. Por lo que tengo entendido, todavía no hay un puente entre Python y ACM. Pero ese puente entre R y ambas ACM existe desde hace muchos años, está disponible gratuitamente en kodobase, y no hay quejas - todo funciona de forma estable, el probador funciona y aún no he visto ninguna queja sobre la velocidad: los datos se envían en memoria.
Python no tiene NADA que ver con nuestros problemas. Python es un cúmulo de todo y cualquier cosa útil para nosotros, una subtrama de paletos con versiones incomprensibles que no son compatibles de arriba a abajo. El soporte de Python es puramente rústico, en los entusiastas. Las rúbricas de paquetes aceptables en Python no existen como tales. Todo lo que hay que encontrar en Python es una búsqueda en el foro, por parte de los entusiastas.
Esto es especialmente claro cuando se compara Python con R. No hay ningún problema para encontrar las herramientas que necesitas. Cada paquete está bien documentado: descripciones de las llamadas a las funciones, enlaces a los algoritmos que las implementan, ejemplos, enlaces a artículos relacionados con el paquete... R puede utilizarse como libro de texto sobre cualquier problema. Y todo el material es absolutamente concreto, respaldado por el código correspondiente.
Python no tiene ni puede tener ventaja sobre R porque todo lo que nos interesa está escrito en Cp, mientras que Python o R son los shells de estos paquetes. A veces Python se adelanta al nuevo paquete, debido a la ausencia total de requisitos de diseño y mantenimiento del paquete. Todo lo que aparece en los espejos de R se modera y se filtra la basura.
La otra cara de R es Srr, el propio R está escrito en Srr, tiene una interfaz perfectamente documentada entre R y Srr. Por lo tanto, siempre es posible abandonar el shell de R y utilizar directamente la propia herramienta, escrita en Srr, desde los programas en MCL.
Una última cosa. Por lo que tengo entendido, todavía no hay un puente entre Python y ACM. Pero ese puente entre R y ambas ACM existe desde hace muchos años, está disponible de forma gratuita en kodobase y no hay quejas - todo funciona de forma estable, el probador funciona y aún no he visto ninguna queja sobre la velocidad: los datos se envían en memoria.
Yo también prefiero R, pero creo que el futuro en nuestro campo está en python. Se puede construir un sistema completo de bucle cerrado con él, desde el análisis hasta el comercio. Un ejemplo de ello es el quanto. Eso no funcionará para R.
Yo también prefiero R, pero creo que el futuro en nuestro campo está en python. Puede utilizarse para crear un sistema completamente cerrado, desde el análisis hasta la negociación. Un ejemplo de ello es el quanto. No podrás hacerlo con R.
¿Por qué no funciona? Me parece que ya lo ha hecho durante muchos años. Existe un terminal propio de IBrokers que tiene una API para el mismo broker que quantopian.
Una vez más, Python es el mismo shell que R. Sólo R es un desarrollo serio, mientras que Python es un "dodgem", hay un montón de usuarios que no son core para nosotros y crean ruido.
La otra cara de R es Srr, el propio R está escrito en Srr, tiene una interfaz perfectamente documentada entre R y Srr. Por lo tanto, siempre es posible abandonar el shell en R y utilizar directamente la propia herramienta, escrita en Srr, desde los programas en MKL.
Probablemente por eso el puente para R está escrito en pascal.
Serías un buen vendedor, enhorabuena.
Serías un buen vendedor, enhorabuena.
Nombra al menos un paquete de aprendizaje automático en R ampliamente conocido y popular (no para ti, sino para la comunidad mundial).
¿Hay otros? ¿No en R? Sólo en caret shell hay casi 200 y no todos, como el propio keras. ¿Quiere que recoja estadísticas sobre su uso en la comunidad mundial?
Todo es palabrería como cualquier conversación sobre la selección del lenguaje de programación. No soy fan de los podlouches. Y para mí ese es el criterio decisivo. A cada uno lo suyo.
¿Hay otros? ¿No está en R? Hay casi 200 de ellos sólo en la cáscara de caret y no todos, como el propio keras. ¿Quiere que recoja estadísticas sobre su uso en la comunidad mundial?
Todo es palabrería como cualquier conversación sobre la selección del lenguaje de programación. No soy fan de los podlouches. Y para mí ese es el criterio decisivo. Y allá cada cual con lo suyo.
Bueno, veo que están empezando a añadir R, como TFlow y MXnet, antes sólo era python.
Debe ser por eso que el puente para R está escrito en Pascal.
¿Qué más da en qué esté escrito?
El puente se escribió hace 10 años, cuando se utilizaba para enseñar programación a los estudiantes. Entonces Pascal murió repentinamente.
Pero la principal ventaja del puente - la primitividad, que no requiere tiempo para dominar.
Incluso he abierto una sucursal aquí, agitada para escribir algo más decente, incluso formulado los TdR, pero nadie lo quiere, así que lo que tenemos, lo tenemos. Python tampoco tiene eso.
Ok, veo que empezaron a agregar R, como TFlow y MXnet, antes era solo python
He escrito en el foro: no veo ninguna ventaja en sustituir un paquete por otro. Todo el problema son los predictores y su capacidad de predicción para un determinado profesor. Si se soluciona este problema, a costa del paquete se puede eliminar un poco de error, pero no vale la pena.