Comparación de la media móvil (y cualquier otro indicador) y el error - página 2
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
En principio, esto no tiene nada que ver con mql. Tomemos un lenguaje de programación abstracto. En este ejemplo concreto que he puesto, el principal problema es que los valores de la diferencia de muwings en una misma barra no son iguales (2e-16 en el primer cálculo y exactamente 0 en el segundo). En este caso, esta intersección no puede determinarse de ninguna manera. Si volvemos a mql, la normalización implica redondear el número(o más bien, simplemente dejar caer todos los números después de un determinado signo, como en la función Sish floor, pero hasta un determinado decimal). Entonces, ¿cómo sé a qué dígito debo normalizar? Si se elige un dígito incorrecto, todos los valores pueden redondearse SIEMPRE a exactamente 0. Por lo tanto, la normalización es peligrosa en este caso y generalmente no resuelve el problema.
En cuanto a lo que escribió Alexey Lebedev. Sí, estaba pensando en esta dirección. Pero si comparamos ambas diferencias por más o igual a 0, existe la probabilidad de obtener una señal falsa (por ejemplo, la situación teóricamente posible cuando los muwings entre barras vecinas tienen exactamente los mismos valores). Entonces su diferencia no cambia el signo (no hay cruce), pero la señal de cruce se determinará programáticamente. Podrías poner sólo una comparación en más o en igual, como has sugerido. Pero entonces el problema es que en el cálculo en esta situación primero no será igual a 0 (2e-16), y en la siguiente barra será exactamente 0 pero será una comparación estricta.
Es importante entender por qué la misma diferencia, cuando se calcula en diferentes barras, NO produce el mismo resultado. Si el resultado fuera el mismo, el problema se resolvería siempre introduciendo una comparación no estricta.
Al normalizar, sí, hay un redondeo a un decimal determinado. No se descartan todos los números a partir de un determinado signo, sino que se redondean.
Si te entiendo exactamente en ese contexto (cojo tanto tu primer post con la captura de pantalla como el segundo), varios experimentos con dicho método, incluyendo tener en cuenta DoubleToString al imprimir, supongo que todavía te pueden ayudar. Rosomah lo mencionó antes que yo a ti.
Incluyendo, ayudar a determinar por sí mismo a qué figura para normalizar en cualquier tarea, o si en algunos casos la normalización es necesaria (en los casos de dudas, la aplicación o no en el conjunto de factores relacionados, incluyendo que el programa entonces se puede aplicar en diferentes DC y, en consecuencia, los valores calculados pueden ser diferentes).
Desde mi punto de vista, el peligro de obtener señales que puedan considerarse falsas, dependiendo de la tarea que se realice, puede ser justo cuando no se aplica la normalización (o cuando no hay comparación en la primera forma debido a algún valor pequeño) donde no sería un problema.
Además, si no se aplica DoubleToString en la impresión, puede haber simplemente una idea errónea de que la misma diferencia o los mismos valores no son el mismo resultado.
/* Por si acaso, me gustaría mencionar de nuevo que cuando se imprimen números de tipo doble, es necesario utilizar DoubleToString, porque la salida convierte un valor numérico en un valor de texto. En consecuencia, si no se utiliza esta función, es posible que aparezcan errores que no existen en realidad.
El número de decimales en esta función, por supuesto, con no menos número de decimales que los valores normalizados. Y para los valores no normalizados, el número de decimales es mayor.
Lo más probable es que el cálculo de la función iMA esté optimizado. Primer valor = suma(cierre)/N, segundo = valor anterior de MA+(nuevo cierre-viejo cierre)/N.
Entonces, ¿los iMAs en general para la misma barra pueden dar diferentes valores de los dos muwings en diferentes tiempos de llamada?
Al normalizar, sí, se redondea al decimal especificado. Se trata de redondear, no de descartar todos los números a partir de un determinado decimal.
Si te entiendo exactamente en ese contexto, al que te refieres (tengo en cuenta tanto tu primer post con la captura de pantalla como el segundo post), entonces varios experimentos con dicho método, incluyendo tener en cuenta DoubleToString al imprimir, creo que aún pueden ayudarte.
Incluyendo, ayudar a definir por sí mismo a qué figura para normalizar en cualquier tarea, o si la normalización es necesaria en algunos casos (en casos de duda, utilizar o no utilizar en conjunto de factores de acompañamiento, incluyendo que el programa entonces se puede aplicar en diferentes DC y, respectivamente, los valores de cálculo obtenidos pueden ser diferentes).
Desde mi punto de vista, el peligro de obtener señales que podrían ser consideradas como falsas, dependiendo de la tarea en cuestión, puede ser justo cuando no se aplica la normalización (o cuando no se compara el primer método debido a algún valor pequeño) donde no haría daño.
Además, si no se aplica DoubleToString en la impresión, puede haber simplemente una idea errónea de que la misma diferencia o los mismos valores no son el mismo resultado.
/* Por si acaso, me gustaría mencionar de nuevo que cuando se imprimen números de tipo doble, es necesario utilizar DoubleToString, porque la salida convierte un valor numérico en un valor de texto. En consecuencia, cuando no se utiliza esta función, pueden producirse los siguientes errores
El número de decimales en esta función, por supuesto, con no menos número de decimales que los valores normalizados. Y para los valores no normalizados, el número de decimales es mayor.
Está claro que el último dígito significativo se redondea. Pero si, por ejemplo, se ponen 5 cifras significativas para el número 0,000016, será 0,00002, y si hay menos cifras significativas, siempre será 0. Por lo tanto, el redondeo a un dígito específico no siempre es posible. Los valores de la MA no sólo dependerán del marco temporal, sino también de las propias barras. Por lo tanto, no está claro cómo establecer el número de dígitos significativos durante la normalización en el caso general.
Lo que no puedo entender del valor infinitesimal es cómo aplicarlo. Infinitesimal (error) se utiliza para comparar un número real con 0. Yo, en cambio, necesito comparar la diferencia. La situación aquí puede ser aún peor. Por ejemplo, he puesto un poco de épsilon. Cuando la diferencia es mayor que epsilon, la considero positiva. Cuando es menos que el épsilon, es negativo. Cuando está dentro de los límites es 0. Pero entonces, ¿cómo se determina el cambio de signo de la diferencia? Por ejemplo, la diferencia de muvings en dos barras está dentro de epsilon. Pero en el primer caso es positivo, en el segundo es negativo (es decir, el cruce YA ocurrió). Y yo, teniendo en cuenta la introducción del error, consideraré que la diferencia es 0. Entonces habrá que cambiar la condición de cambio de signo. Condicionalmente, la señal de dos MA que se cruzan de arriba a abajo en este caso será tanto una simple comparación de <0 (fue) y >0 (se convirtió), como de =0 (fue) y >0 (se convirtió). Y lo más importante, en el caso descrito (cuando los valores en un mismo punto son diferentes para distintas llamadas) introducir este error no ayuda. Esta diferencia siempre puede ser tal que, sea cual sea el épsilon que elijas, no obtendrás señal.
Está claro que el último dígito significativo se redondea. Pero si, por ejemplo, para un número 0,000016 se pone la normalización con 5 dígitos, será el número 0,00002, y si son menos dígitos, siempre será 0. Por lo tanto, el redondeo a un dígito específico no siempre es posible. Los valores de la MA no sólo dependerán del marco temporal, sino también de las propias barras. Por lo tanto, no está claro cómo establecer el número de dígitos significativos durante la normalización en el caso general.
Lo que no puedo entender del valor infinitesimal es cómo aplicarlo. Infinitesimal (error) se utiliza para comparar un número real con 0. Yo, en cambio, necesito comparar la diferencia. La situación aquí puede ser aún peor. Por ejemplo, he puesto un poco de épsilon. Cuando la diferencia es mayor que epsilon, la considero positiva. Cuando es menos que el épsilon, es negativo. Cuando está dentro de los límites es 0. Pero entonces, ¿cómo se determina el cambio de signo de la diferencia? Por ejemplo, la diferencia de muvings en dos barras está dentro de epsilon. Pero en el primer caso es positivo, en el segundo es negativo (es decir, el cruce YA ocurrió). Y yo, teniendo en cuenta la introducción del error, consideraré que la diferencia es 0. Entonces habrá que cambiar la condición de cambio de signo. Condicionalmente, la señal de dos MA que se cruzan de arriba a abajo en este caso será tanto una simple comparación de <0 (fue) y >0 (se convirtió), como de =0 (fue) y >0 (se convirtió). Y lo más importante, en el caso descrito (cuando los valores en un mismo punto son diferentes para distintas llamadas) introducir este error no ayuda. Esta diferencia puede ser siempre tal, que sea cual sea el épsilon que elijas, no obtendrás señal.
Creo que a la hora de resolver cualquier problema concreto, también se puede confiar en la precisión de las cifras significativas decimales. Al doble son 15 dígitos significativos, según la Documentación. El formato de la precisión de la normalización, de 0 a 8, según la Documentación. DoubleToString tiene sus propias peculiaridades de formatos de precisión.
Además, iMA es, desde mi punto de vista, una función que tiene en cuenta que los valores derivados con ella se aplicarán en diferentes situaciones y para resolver diferentes problemas. En consecuencia, los valores que emite pueden ser procesados de forma diferente, también con respecto a tareas específicas.
Además, el cálculo de las medias es un cálculo matemático. Por ejemplo: (1.20525 + 1.20598 + 1.2081)/3 = 1.2064433333... En consecuencia, los valores calculados con redondeos pequeños o ampliados aumentan las opciones de aplicación de los cálculos.
Por si acaso, quiero mencionar que en lugar de iMA, puede utilizar las funciones de la biblioteca MovingAverages, que se incluye en el paquete estándar de la terminal. O puede utilizar sus propias funciones basadas en las de esta biblioteca.
/* En los cálculos matemáticos, puede haberpeculiaridades de trabajar con números de tipo double */.
Sobre los épsilon, en cambio, paso.
P./S.: Entonces, creo que los experimentos pueden ayudarte. El razonamiento teórico sin experimentos prácticos (sobre una gran cantidad de datos) para tareas específicas, entre otras, puede confundir y alejar de soluciones aceptables.
Dina Paches:
...
Qué lío. Llevamos 300 días comparando MAs... Normaliza a los dígitos y no te molestes...
Puede normalizar los valores directamente (la diferencia - no hay manera). Pero, de nuevo, hay que cambiar el código de referencia dado para la comparación de MA y hay que introducir una desigualdad no estricta de todos modos. Además, la cuestión de los diferentes valores de MA en una misma barra cuando se calculan en momentos diferentes sigue abierta. Si se repite más adelante, no es seguro que incluso la normalización y la introducción de una desigualdad no estricta resuelvan el problema por completo. Además el caso cuando los muwings dentro de una barra se cruzan dos veces, no se puede coger, si se analiza no por ticks, sino por la apertura de una nueva barra. Quizá puedas compartir tu experiencia, ¿cómo actúas en esta situación?
Bien, en primer lugar, la diferencia de dos valores normalizados dará finalmente un valor no normalizado. Hay que comprobar la diferencia normalizada.
En segundo lugar, si quiere capturar cruces dentro de una barra, tome los valores de todos los ticks en el cero y en la primera barra - capturará muchos ... ...sólo ten cuidado...
Si usted hace la prueba por la apertura de una barra, entonces el Asesor Experto debe monitorear claramente la apertura de una nueva barra, y después del hecho, comprobar los cruces.
Primero decida usted mismo - operar en la apertura de la barra o en cada tick, y luego escriba su código. Y, en consecuencia, probarlo de la misma manera.
Dina, me asombra tu paciencia angelical...
Gracias, Artem, pero desgraciadamente resulta que también puede tener límites.