Prueba de los sistemas de previsión en tiempo real - página 53
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
a Yurixx
Te sugiero que juegues a los buenos dedales, puedes usar cualquier estrategia y buscar en cualquier sitio :o) Pronóstico sobre el EURUSD M15 para 300 muestras (de lunes a miércoles incluido):
Opción 1:
Entropía del proceso: 13,84
Variante 2:
Entropía del proceso: 13,01
Opción 3:
Entropía del proceso: 14,36
¿Qué dedal vas a coger? :о)
Me inclino por la opción 1, ya que esta situación viene evolucionando desde hace mucho tiempo y sólo está esperando a ser continuada
Me inclino por la opción 1, ya que esta situación viene desarrollándose desde hace mucho tiempo y sólo está esperando a ser continuada
Es decir, ¿el precio está pasando ahora por una especie de zona de reversión? Sólo por curiosidad, si no es mucha molestia, ¿podría dar más detalles?
¿Así que el precio está pasando por una especie de zona de pivote? Sólo por curiosidad, si no es mucha molestia, por favor, explíquese.
Por el momento, existe el primer factor en base al cual podemos concluir sobre el plano lateral en el par euro-dólar -
El par ha alcanzado el nivel de la línea OP de consolidación en 1,4850. Exactamente las mismas fluctuaciones se observaron en 1,3437 y 1,3937 con un posterior retroceso, que corresponde a los niveles 0,382, 0,618 y 1,00.
la segunda figura es el mismo gráfico pero con los niveles de crecimiento calculados en relación con el mínimo - 1,4162 y el actual 1,4951 y si usted toma en la base de este gráfico de precios los niveles 1,4951 y 1,4851 se puede ver que el precio está justo en el punto de equilibrio en el nivel medio de las fluctuaciones de estos indicadores los dos últimos días ... Además, el indicador de saturación ha mostrado durante mucho tiempo el nivel de saturación en el que la inversión debe ocurrir
pero hay un par de cosas que no permiten que esto suceda :
1) el gráfico diario muestra un movimiento de crecimiento negativo (indicador inferior)
2) El gráfico diario alcanzó el nivel de consolidación de 0,382 en 1,4877 en el primer indicador
3) El gráfico diario ha alcanzado el nivel de consolidación del COP en 1,4892 en el segundo indicador
4) Hay una oposición activa al movimiento alcista en el gráfico H4
5) Presencia de dos niveles de consolidación en relación con el mínimo de la OP de finales de septiembre y el 0,236 (1,4931 y 1,4933), lo que es un fuerte indicio de la presencia de una corrección prolongada
Para continuar...
Grasn, ¿puedo hacerte una pregunta? ¿Ha intentado buscar puntos de inflexión en una serie temporal?
actualización: lo pregunto porque estoy indagando en esta dirección (y algo se ve). Este es un ejemplo de cómo es mi búsqueda de puntos críticos:
Puntos críticos
Como puedes ver, antes de que la serie cambie su comportamiento, el carácter de las oscilaciones del indicador cambia bruscamente (hay ráfagas de gran amplitud, para ser más exactos, los máximos/mínimos empiezan a ajustarse perfectamente a la gráfica de la función f(x)=a^x). Los picos se producen un poco antes (normalmente :)) que el comportamiento de los cambios de la serie. Sin embargo, hasta ahora no lo he entendido bien. Tengo que trabajar al límite de la doble precisión (los números son muy pequeños) + me faltan las predicciones direccionales.
Supongamos que existe tal construcción:
Según he entendido, aumentará dinámicamente el array memRow[] cuando se dispare alguna condición. Es decir, no conozco la longitud del array de antemano. ¿Lo he hecho bien?
1. En MKL4 no se puede operar con arrays cuyo tamaño no ha sido definido. Si no has especificado el tamaño al declarar el array, tendrás que hacerlo en init(). Además, mientras trabajas, puedes cambiar este tamaño según sea necesario.
2. 2. Los consejos de Lea son bastante prácticos, vale la pena escucharlos. En general, para que los consejos sean adecuados, será mejor que expliques claramente para qué se utiliza el array y por qué necesitas cambiar su tamaño. Es muy posible que te conformes con asignar espacio y tener una variable con el índice del último elemento. Entonces, que conozcas el número de elementos que necesitas o no, no importará realmente.
.
No juego a los dedales. Pero prefiero la variante 2. ¿O sólo quiero que el euR crezca? :-)
Pero las variantes 1 y 3 también están bien, aunque se diferencian muy poco entre sí.
1. En MKL4 no se puede operar con un array, cuyo tamaño no está establecido. Si no se especifica el tamaño del array, habrá que hacerlo en init().
1 No es obligatorio en absoluto.
Declarar un array sin definir su tamaño divide el proceso de preparación del array en tres partes:
1 declaración como tal - mediante este procedimiento, el programador indica al compilador si la matriz es global o local.
2 establecer el tamaño a través de ArrayResize() - después de este procedimiento, el array está realmente listo para trabajar.
3 Inicialización - si no se especifica, el array se queda como estaba (y almacena valores de inicios pasados), cuando se crea el array, se inicializa automáticamente a 0.
Gracias, lo intentaré, pero no puedo valorar cuál sería el óptimo. Por otro lado, para un array pequeño tampoco sabré su dimensionalidad, y además, en esta implementación necesitaré duplicar el array, primero el pequeño y luego el grande, en el que se acumulan los valores calculados. Pero tendré que experimentar, gracias por el consejo.
En mi experiencia, recomiendo definir y utilizar los arrays directamente donde se necesitan utilizar, tales arrays son en su mayoría locales, utilizan la memoria de forma dinámica, lo que es mejor en comparación con los arrays estáticos, que quieren o no el viento los mueve al archivo de intercambio, y por lo tanto su trabajo se convierten en muchas veces más lento que de la RAM, especialmente si el array es pequeño, no tiene sentido estáticamente para reservar mucho espacio para ellos. El compilador de MQL-4 está diseñado para que no sientas la diferencia entre declarar un array con un tamaño explícito y uno retrasado.
En mi experiencia recomiendo declarar y usar arrays directamente donde se necesite usar dichos arrays en su mayoría resultan ser locales los que dinámicamente usan memoria que es mejor en comparación con los arrays estáticos que quieras o no Windows los pone en archivo de intercambio y por lo tanto su trabajo se vuelve muchas veces más lento que desde la RAM, más si el array es pequeño entonces no tiene sentido que estáticamente se reserve mucho espacio.
No lo entiendo... ¿Por qué no se puede precargar una matriz local en un archivo de intercambio? En realidad, se adelanta allí cuando hay una escasez de memoria; estoy seguro de que tanto las matrices locales como las globales se adelantan exactamente de la misma manera. ¿Cuál es la diferencia?
Hay algo que no entiendo... ¿Por qué no se puede precargar una matriz local en un archivo de intercambio? Generalmente, se empuja allí cuando hay una escasez de memoria; estoy seguro de que tanto la local como la global serán empujadas exactamente de la misma manera. ¿Cuál es la diferencia?
El array estático tiene todas las posibilidades de ser creado en cada llamada del programa y de ser exprimido por los arrays recién creados en el intercambio. Aunque si hay más que suficiente memoria RAM, esto puede no ocurrir.
1 No es necesario en absoluto.
Declarar un array sin definir su tamaño divide el proceso de preparación del array en tres partes:
1 declaración como tal - mediante este procedimiento, el programador indica al compilador si la matriz es global o local.
2 establecer el tamaño a través de ArrayResize() - después de este procedimiento, el array está realmente listo para trabajar.
3 Inicialización - si no se especifica, el array se queda como estaba (y almacena los valores de inicios pasados), cuando se crea un array, se inicializa automáticamente a 0.
Si se establece el tamaño en init() con ArrayResize(), este array no tendrá ningún tamaño en start(), se debe especificar el tamaño en la función donde se utilizará el array, y lo mismo ocurre para utilizar el array en las funciones de usuario. Si el array se pasa por parámetro, su tamaño no debe especificarse en la función definida por el usuario, sino en start() (o en init() si la función es llamada por el iniciador), y luego en la función llamada. La excepción son las matrices de indicadores, cuyo tamaño se asigna igual a Bares cuando el estado del indicador se asigna al nombre de la matriz en SetIndexBuffer(), y cambia de acuerdo con el cambio de Bares.
Así que, querida, tus explicaciones no sólo son inútiles, sino que además son perjudiciales porque quitan tiempo a la gente para averiguar la verdad.
Urain, estás engañando a la gente. Las matrices MQL, incluyendo las locales, tienen persistencia - su tamaño y contenido se conservan entre las llamadas de función y los ticks. Por favor, lea la Ayuda. Las matrices globales se comportan de la misma manera, con la única diferencia de que tienen un ámbito global. Un array distribuido en una función init es legible en start y en otros lugares. Recomendaría abrir un nuevo hilo, si alguien tiene preguntas sobre algunos aspectos de la programación MQL. Me gustaría ver más conversaciones sustanciales sobre la previsión aquí. ;-)
Si tiene alguna duda, filtre la información de este foro ;-). Si describe el problema con más detalle (puede hacerlo en persona), nosotros (yo) averiguaremos cómo implementarlo mejor.