Comparación de la media móvil (y cualquier otro indicador) y el error - página 4
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
Gracias por el consejo, por supuesto, pero puedo leer la Ayuda por mí mismo. Y repito que las matemáticas computacionales no están ligadas a un lenguaje de programación concreto. Son sólo los errores de cálculo con los que tengo que lidiar, con los que tú pasarás.
Si no sólo puede leer la Ayuda, sino también entenderla, entonces está haciendo demagogia deliberada, al seguir hablando obstinadamente de la normalización y sus posibles aplicaciones con un espíritu de menosprecio. Incluyendo la demagogia deliberada sobre los peligros de su aplicación.
Y no me estoy haciendo el listo, sino dando contraejemplos (incluso para tu querida normalización).
La demagogia estaba ahí. No hubo contraejemplos sobre la normalización.
Aparte del hecho de que alguien puede aplicarlo mal.
Así que los épsilones pueden aplicarse incorrectamente. Sí, y ya se ha mencionado la demagogia.
P./S.: El post trata de la normalización, por lo que no menciono las medias móviles.
Y creo que Artem puede ayudarte mejor con los EAs que utilizan MAs que yo con esos difíciles.
Busque los cruces en cada tic. ¿Cuál es el problema?
Nunca es necesario normalizar nada cuando se comparan dos números reales.
Si los números son realmente iguales, se almacenan en la memoria por igual. En realidad, es precisamente gracias a esta propiedad que pueden existir las máquinas de computación.
Por lo tanto, las comparaciones de la forma if(a<b) o if(a==b) son correctas en cualquier caso y no se requiere ninguna normalización.
Si la mente inquisitiva de un investigador encuentra una contradicción con esta regla, significa que, o bien su máquina está averiada, o bien su mente. Uno de los dos.
La ayuda y la documentación, por supuesto, deben ser leídas al menos en ocasiones (también fueron escritas por humanoides como nosotros), pero es necesario tener un razonamiento propio y sensato.
Si no sólo puede leer la Ayuda, sino también entenderla, entonces está haciendo demagogia deliberada, al seguir hablando obstinadamente de la normalización y sus posibles aplicaciones con un espíritu de menosprecio. Incluyendo la demagogia deliberada sobre los peligros de su aplicación.
La demagogia estaba ahí. No hubo contraejemplos sobre la normalización.
Sin incluir el hecho de que alguien pueda no utilizarlo correctamente.
Por lo tanto, los épsilones pueden aplicarse de forma incorrecta. Y la demagogia ya ha sido mencionada.
Ha habido contraejemplos (al menos en lo que respecta a la normalización también de la diferencia, como se expresa aquí). Lo vuelvo a repetir: la normalización es el camino más fácil para los que no quieren profundizar en los entresijos. Ha leído la documentación y se lo cree todo piadosamente. De nuevo, repito que el lenguaje de programación dentro de la matemática computacional es irrelevante. Si está escrito así en la ayuda, no significa que sea cierto (si no, no habría problemas de matemáticas computacionales y épsilon que tanto te disgustan). También hay mucho escrito en la valla, pero eso no significa que sea la verdad en última instancia. Estás contento con la opción Halp, tienes todo el derecho a estarlo. Pero es tu elección personal. Y no significa que resuelva todos los problemas que he intentado aclarar aquí. Y considerar como demagogia algo que simplemente no quieres entender (de nuevo, estás en tu derecho), no significa que sea demagogia en sí. No estoy haciendo preguntas retóricas sobre el sentido de la vida (cuyas respuestas no son más que demagogia), sólo trato de abordar algo con lo que aún no me he encontrado. De nuevo, digamos que los valores son siempre los mismos cada vez que los calculas. Allí se podría obtener algo de la misma matemática computacional. Pero cuando los valores también son diferentes, no podrás dar con un algoritmo universal, aunque seas un megagurú.
Además, sólo quiero asegurarme de que mi entendimiento de que si un robot no trabaja por ticks, conseguir múltiples intersecciones dentro de una barra es básicamente imposible. Ya se puede atribuir puramente a los entresijos de mql.
P.D. No estoy tratando de discutir con alguien sin fundamento, no creo que sea un genio correcto todo el tiempo. Es que no me gusta cuando la gente intenta hacerse la lista y escribir algo sin siquiera leerlo. Esto no tiene nada que ver contigo personalmente. Gracias por su ayuda y sus ideas sobre el tema. Pero aún así, en mi opinión, es un error escribir algo sobre la paciencia cuando se insiste en un solo punto de vista en la documentación (en el que se cree de todo corazón y no se aceptan puntos de vista y ejemplos alternativos), y los epsilones no son de su agrado. Espero que Artyom entienda lo que escribí en el post script antes de eso también. Gracias a todos por vuestras respuestas y perdonadme si me he puesto un poco pesado en alguna parte.
P.P.S. La normalización a un determinado decimal es, de hecho, análoga a la introducción del épsilon sólo por el orden del mismo signo.
P.P.P.S. Si tenemos una discusión tan acalorada, estaría muy agradecido si compartes tus experiencias en este tema, porque las respuestas adecuadas (especialmente en los puntos 2 y 3 que me molestan), de hecho, no las obtuve. Aunque recorriendo muchos foros, casi llegué a la conclusión de que, sí, 2 puntos es imposible. Los desarrolladores de mql podrían pensar en esto, y proporcionar más flexibilidad, porque es muy inconveniente (en cualquier otro lenguaje de programación tiene la capacidad de cambiar dinámicamente la interfaz del programa, y aquí resulta que no hay ninguno ((()))
Ha habido contraejemplos (al menos en cuanto a la normalización también de la diferencia, como se ha expresado aquí). Lo vuelvo a repetir: la normalización es el camino más fácil para los que no quieren profundizar en los entresijos. Ha leído la documentación y se lo cree todo piadosamente. De nuevo, repito que el lenguaje de programación dentro de la matemática computacional es irrelevante. Si está escrito así en la ayuda, no significa que sea cierto (si no, no habría problemas de matemáticas computacionales y épsilon que tanto te disgustan). También hay mucho escrito en la valla, pero eso no significa que sea la verdad en última instancia. Estás contento con la opción Halp, tienes todo el derecho a estarlo. Pero es tu elección personal. Y no significa que resuelva todos los problemas que he intentado aclarar aquí. Y considerar como demagogia algo que simplemente no quieres entender (de nuevo, estás en tu derecho), no significa que sea demagogia en sí. No estoy haciendo preguntas retóricas sobre el sentido de la vida (cuyas respuestas no son más que demagogia), sólo trato de entender algo que aún no he encontrado. De nuevo, digamos que los valores son siempre los mismos cada vez que los calculas. Allí se podría obtener algo de la misma matemática computacional. Pero cuando los valores también son diferentes, no podrás dar con un algoritmo universal, aunque seas un megagurú.
Además, sólo quiero asegurarme de que mi entendimiento de que si un robot no trabaja por ticks, conseguir múltiples intersecciones dentro de una barra es básicamente imposible. Ya se puede atribuir puramente a los entresijos de mql.
P.D. No estoy tratando de discutir con alguien sin fundamento, no creo que sea un genio correcto todo el tiempo. Es que no me gusta cuando la gente intenta hacerse la lista y escribir algo sin siquiera leerlo. No tiene nada que ver contigo personalmente. Gracias por su ayuda y sus ideas sobre el tema. Pero aún así, en mi opinión, es un error escribir algo sobre la paciencia cuando se insiste en un solo punto de vista en la documentación (en el que se cree de todo corazón y no se aceptan puntos de vista y ejemplos alternativos), y los epsilones no son de su agrado. Espero que Artyom entienda también lo que escribí en el postcriptum anterior. Gracias a todos por vuestras respuestas y perdonadme si me he puesto un poco pesado en alguna parte.
P.P.S. La normalización a un determinado decimal es, de hecho, análoga a la introducción del épsilon sólo por el orden del mismo signo.
P.P.P.S. Si tenemos una discusión tan acalorada, estaría muy agradecido si compartes tus experiencias en este tema, porque las respuestas adecuadas (especialmente en los puntos 2 y 3 que me molestan), de hecho, no las obtuve. Aunque recorriendo muchos foros, casi llegué a la conclusión de que, sí, 2 puntos es imposible. Aquí los desarrolladores de mql podrían pensar en ello, y proporcionar más flexibilidad, porque es muy incómodo (en cualquier otro lenguaje de programación tiene la capacidad de cambiar dinámicamente la interfaz del programa, y aquí resulta que no hay ninguno ((()))
Para mí el uso de la conversión de datos mediante la función NormalizeDouble al comparar dobles es una de las dos formas, estipuladas en la Documentación, de conseguir que las condiciones del programa funcionen exactamente donde y como se pretendía al escribir condiciones específicas en el código. A eso me refería antes. En consecuencia, no se trata sólo de la eliminación de cualquier error. También son varias las formas de transformar los datos para cumplir cualquier condición.
Te lo he contado y te lo cuento, basándome en mi experiencia práctica personal en el lenguaje de programación que estás empezando a aprender. Por esta razón, y sugerido en repetidas ocasiones en este hilo, para utilizar una forma tan práctica.
Por cierto, diré, en parte, coincidiendo contigo, que no voy a discutir que la normalización con esta función puede ser la forma más fácil para cualquier tarea en cuanto a transformación de datos de tipo real
Pero cada uno debe decidir cuál de los dos métodos recomendados en la Documentación debe utilizar cuando convierta datos de tipos reales.
Y la elección de cualquiera de estas formas no es determinante para saber si uno es el tipo de persona que intenta averiguar las sutilezas necesarias o no.
Que no me gusten las épsilon no fue una palabra mía. No aplicar ningún método no es necesariamente amor/desamor. Tampoco he insistido en aplicar sólo la segunda vía de las dos.
Mis palabras literales en cuanto a la aplicación práctica de las peculiaridades de trabajar con números de tipo doble, eso:
P./S.: Resulta que el primer método de la Documentación me resultó menos cómodo de utilizar, incluso, a base de tareas, que, por regla general, resuelvo yo mismo. En consecuencia, no tengo mucha experiencia con la primera forma.
Pero al aplicar la segunda forma (es decir, comparando la diferencia normalizada de dos números reales con valor cero en la expresión del operador condicional), no surgió ningún problema de forma inequívoca.
Pero si hice una comparación de números no normalizados (aquí me refiero, sin usar la primera forma también), entonces sí, fue que encontré condiciones incorrectas en base a comparaciones de números de tipo double.
Además, también he dado una aclaración de este tipo:
P./S.: Dicho esto, por si acaso, voy a aclarar una vez más, que la comparación de números reales por el primer método de los dos enumerados aquí , mediante lacomparación de la diferencia de los números con algún valor pequeño, no puedo llamar peor que el uso de la normalización, cuando se necesita para ajustar el nivel de comparación (incl., ya que para mí el segundo método era más conveniente, no consideré para mí más detallada para la aplicación práctica).
Es decir, en cuanto a la normalización al convertir datos de tipo doble, simplemente no necesitaba la primera forma. En particular, debido a la conveniencia para mí en el uso de la función NormalizeDouble en la solución de diversos problemas (y no sólo en las comparaciones).
Este sitio tiene una enorme base de conocimientos acumulados.
La gente ha resuelto y está resolviendo todo tipo de tareas de diferente complejidad utilizando MQL4.
Tras el acercamiento de MQL4 a MQL5, las posibilidades del primero han aumentado aún más.
Creo que deberías familiarizarte mejor con este lenguaje de programación y no ignorar la base de conocimientos acumulada en los sitios de aquí. Adquirir experiencia práctica en su uso. Y sólo entonces se puede decir algo con confianza en términos de cualquier aplicación en este lenguaje de programación y sus capacidades.
Tengo un TdR diferente) Y de nuevo, ya he escrito sobre los problemas con las garrapatas. No hay manera de explicar al cliente por qué el robot entró en la operación si no ve el cruce en el gráfico
Tome los valores de la MA en la barra cero y en la primera barra en cada tick - entonces y sólo entonces puede encontrar cruces de MAs en la barra cero. Los toma de la primera barra en el momento de la apertura de la barra cero - y allí los valores de la MA son los que estaban presentes cuando se cerró la primera barra, no cuando se formó. Simplemente se leen los valores de МАšek tarde y por lo tanto no se ven cruzar. La normalización no tiene nada que ver. Y por cierto, si las MAs muestran los valores de los precios, entonces los valores deberían ser normalizados a _Dígitos, en lugar de adivinar a qué valor es necesaria la normalización...
Estimados participantes del foro. Por favor, no establezcan disputas en el foro. Sólo en el tema del hilo.
Creo que se puede cerrar el tema. Los autores (no el tema) de las declaraciones no llegaron a un consenso. Hubo momentos aislados de chovinismo, que no son bienvenidos.
Pero ni unos ni otros han podido probar su caso. Por eso cierro el hilo. La discusión posterior puede ser castigada (prohibición máxima diaria).
Aunque si se dan pruebas normales, son bienvenidas.
Los jueces seremos yo y Volodya.
Esto no se discute.
No he visto todo eso aquí, así que no sé qué argumentos se han dado dentro del tema. Pero como supongo que se trata de demostrar mi postura, que es similar a la de Artem en este post (y anteriormente aquí en el hilo), voy a poner uno de los ejemplos a continuación, en relación a si se debe aplicar la normalización de una manera u otra cuando se trabaja con números de tipo real.
Con capturas de pantalla y una variante del código de prueba.
Artyom escribió en el post anterior:
И, кстати, раз МА показывают значения цены, то и нормализовать значения нужно до _Digits, а не гадать до какого же значения нормализация нужна...
Y como yo también creo (como creo que muchos otros) que esta es una forma sencilla y eficaz en las direcciones más comunes de los problemas, sólo haré esta pequeña adición de mi parte:
con cuántos decimales se concibe la visualización de la línea MA, o simplemente se realizan cálculos basados en cualquier número de decimales (la misma comparación), con tantos decimales y normalización (redondeo a un determinado decimal).
/*Para algunas tareas individuales, puede haber "excepciones", y se puede variar para obtener el resultado deseado, por ejemplo, comparando un valor con un decimal más bajo, con un valor con un decimal más alto. Pero si esto es necesario para la tarea en cuestión, entonces en mi opinión puede ser bien aconsejado, si es necesario, como con el método anterior, imprimir los valores obtenidos y comparar los valores obtenidos con la representación visual en el gráfico.
Si necesitamos dar salida a valores de tipo doble como texto (a través de Print, Comment, OBJ_LABEL etc.), entonces debemos utilizar DoubleToString ya que queremos convertir el número en texto.
Ahora, de la explicación introductoria a la claridad:
En las capturas de pantalla:
Los datos del script de prueba son valores MA obtenidos mediante la función iMA (con y sin transformaciones utilizando las funciones descritas para trabajar con tipos reales en la Documentación).
Puede ver en la ventana de datos y en el gráfico que las líneas con un decimal más bajo se han igualado en valores en la tercera barra, sin contar la actual, del gráfico. También se puede ver que los valores MA del conjunto estándar al terminal, dibujados en los decimales del gráfico, no son iguales y visualmente se han igualado en el gráfico un poco antes.
Es decir, si amplía las capturas de pantalla o realiza sus propios experimentos utilizando el script de prueba adjunto o sus propios códigos, verá que las líneas MA, con el número de decimales como en el gráfico, se cruzan un poco antes.
Y eso es comprensible. Por analogía, las líneas con decimales son una menos que las líneas trazadas con citas de dos dígitos en un gráfico de tres dígitos. Permite verlas en puntos "antiguos" de la época en que las cotizaciones de tres o cinco dígitos en los terminales no están muy extendidas y, al mismo tiempo, tienen las ventajas de las cotizaciones decimales extendidas para la negociación (incluidos los diferenciales más estrechos).
Es decir, las líneas basadas en valores con menos decimales tienen menos "ruido".
Pero si no se aplicara el redondeo (en este caso, utilizando la función de normalización), un número claramente limitado a un decimal concreto sería más problemático.
O, si sólo en números:
123.4561 y 123.4556 no son iguales. Y su diferencia no es nula.
Sin embargo, si los redondeas, tanto el primer número como el segundo, serán iguales y equivaldrán a 123,456. En consecuencia, la diferencia entre ellos será 0.
El redondeo de los valores resultantes depende de las tareas a realizar.
En las capturas de pantalla del diario "Expertos", se pueden ver los valores de MA emitidos mediante iMA con las conversiones descritas en la Documentación, y sin conversiones de los valores resultantes. Los ajustes de MA en el script de prueba son iguales a los de los indicadores en el gráfico.
En la segunda captura de pantalla, puede ver los deltas entre dos valores de MA con y sin transformaciones.A continuación, como he mencionado, hay un pequeño código de prueba. No está optimizado, pero permite hacer varios experimentos con valores de MA, incluyendo el cambio de algunos parámetros.
En esta línea se establece el número de barras que contiene:
P./S.: He sustituido el script de prueba adjunto. Me equivoqué de variante en mi post. No es así. Lo siento.
Las capturas de pantalla adjuntas anteriormente no son necesarias, así que las dejo igual.