Aprendizaje automático en el trading: teoría, práctica, operaciones y más - página 2367

[Aleksey Vyazmikin]

mytarmailS:

Largo suspiro... olvidado, cansado)

¿384 GB DE RAM?

No necesito tanto - 64 vale la pena.

[mytarmailS]

Aleksey Vyazmikin:

No necesito tanto - cuesta 64.

Ok, bueno, veamos, todavía estoy ordenando el código yo mismo, cómo hacer mejor lo que se puede optimizar, creo, estoy probando opciones, no quiero molestarte por nada también, tendré en cuenta a koroch...

[mytarmailS]

Aleksey Nikolayev:

Algunas cosas que te gustan mucho después te parecen desagradables al principio: el café, el caviar, el wasabi, la música rock, etc.)

es cierto, yo también no entendía algunas de las estructuras de p-ka al principio, pensaba que eran tonterías

Yo también estuve trasteando con algunas estructuras en p-ka al principio, pensaba que era una tontería, por ejemplo usaba bucles para escribir todo y no entendía la familia "apply", pero luego resultó que ganaba en legibilidad y velocidad y podía escribir 6 líneas de código y hacer una línea de código

[Vladimir Perervenko]

mytarmailS:

Al principio tampoco entendía algunas de las estructuras de p-ka, pensaba que eran tonterías.

Solía escribir todo en un bucle y no entendía la familia "apply", pero luego resultó que podía conseguir más legibilidad y velocidad y podía escribir 6 líneas de código y hacer una

No sólo se aplican. A menudo utilizo foreach ya que se puede paralelizar sin alterar el código... A veces el iterador es útil, pruébalo

library(coro)
abc <- generate_abc()
loop(for (x in abc) print(x))

Buena suerte

[mytarmailS]

Vladimir Perervenko:

No sólo se aplica. Yo uso foreach más a menudo, puedes paralelizarlo sin rehacer el código... A veces el iterador es útil, pruébalo

Buena suerte

Gracias.

[mytarmailS]

mytarmailS:

Gracias.

¿Qué es generate_abc? Sigo sin entenderlo porque el ejemplo da error

library(coro)
> abc <- generate_abc()
Error in generate_abc() : could not find function "generate_abc"

[[Eliminado]]

Todas estas operaciones están en python

print([x for x in range(50)])

[Aleksey Nikolayev]

Todo esto comenzó en lisp y se desarrolla especialmente en la programación funcional, cuyos elementos se encuentran tanto en R como en Python.

[Vladimir Perervenko]

Por casualidad, leí un artículo con una afirmación que me sorprendió:Predictores, respuestas y residuos: ¿Qué es lo que realmente debe distribuirse normalmente?

Algunas citas:

"A muchos científicos les preocupa la normalidad o no normalidad de las variables en el análisis estadístico. A menudo se expresan, publican o enseñan las siguientes opiniones y otras similares:

• " Si quieres hacer estadística, todo tiene que tener una distribución normal .
• " Hemos normalizado nuestros datos para que se ajusten al supuesto de normalidad .
• " Convertimos nuestros datos en un registro ya que tenían una distribución muy sesgada" .
• "Después de ajustar el modelo, comprobamos la homocedasticidad de los residuos .
• " Utilizamos una prueba no paramétrica porque nuestros datos no se ajustaban al supuesto de normalidad" .

Y así sucesivamente. Sé que es más complicado que eso, pero sigue pareciendo que la distribución normal es lo que la gente quiere ver en todas partes, y que la distribución normal de las cosas abre la puerta a estadísticas limpias y convincentes y a resultados sólidos. Muchas personas que conozco comprueban regularmente si sus datos se distribuyen normalmente antes de analizarlos, y luego intentan "normalizarlos", por ejemplo, utilizando una transformación logarítmica, o ajustan el método estadístico en función de la distribución de frecuencias de sus datos. Aquí exploro esto más de cerca y muestro que puede haber menos suposiciones sobre la normalidad de lo que uno podría pensar".

Justificación adicional del pensamiento y la conclusión:

" ¿Por qué la gente sigue normalizando los datos?

Otro problema desconcertante es por qué la gente todavía tiende a "normalizar" sus variables (tanto los predictores como las respuestas) antes de ajustar un modelo. ¿Por qué ha surgido y se ha generalizado esta práctica, aunque no existan supuestos que la provoquen? Tengo varias teorías al respecto: la ignorancia, la tendencia a seguir libros de cocina estadísticos, la propagación de errores, etc. D.
Dos explicaciones parecen más plausibles: en primer lugar, la gente normaliza los datos para linealizar las relaciones. Por ejemplo, se puede utilizar una transformación logarítmica del predictor para ajustar una función exponencial mediante el mecanismo habitual de mínimos cuadrados. Esto puede parecer normal, pero entonces ¿por qué no especificar la relación no lineal directamente en el modelo (por ejemplo, utilizando una función de referencia adecuada)? Además, la práctica de la transformación logarítmica de la respuesta puede dar lugar a graves artefactos, por ejemplo en el caso de los datos de recuento con recuentos nulos (O'Hara y Kotze 2010).
Una segunda razón plausible para la "normalización" de la práctica fue sugerida por mi colega Catherine Mertes-Schwartz: puede deberse a que los investigadores están tratando de resolver un problema y sus datos han sido recogidos de forma muy escurridiza y desigual. En otras palabras, muy a menudo se trabaja con datos que tienen un gran número de observaciones agregadas en una determinada parte del gradiente, mientras que la otra parte del gradiente está relativamente poco representada. Esto conduce a distribuciones distorsionadas. La transformación de estas distribuciones conduce a una distribución aparentemente regular de las observaciones a lo largo del gradiente y a la eliminación de los valores atípicos. De hecho, esto puede hacerse de buena fe. Sin embargo, esto también es fundamentalmente erróneo".

Para mí esta afirmación es (¿chocante?) , no encuentro la palabra adecuada para describirla. Pero lo tendré en cuenta en el futuro.

[Vladimir Perervenko]

Maxim Dmitrievsky:

Todas estas operaciones están en python.

No se trata de imprimir, sino de generadores e iteradores.