Indicadores de élite :) - página 248

 

Gracias

Gracias Mladen:)

 

Mladen,

Nunca dejas de sorprenderme.

Gracias por compartirlo.

Salud,

 

Algunos indicadores divertidos (parece que hay algunas matemáticas avanzadas y la codificación en ellos) que he recogido de los foros rusos.

Archivos adjuntos:
 

biddick

Sobre uno de los indicadores adjuntos : el M_qwma

________________________

Tiene algunos errores de codificación en él. Uno de los errores hace que no muestre el valor en absoluto para cada nueva barra. Algunos otros no son tan pesados pero debían ser corregidos. También una limitación que tenía con la longitud máxima de cálculo se elimina en este. Así que publicando una limpiada y simplificada aquí

Y de paso, ya que tuvieron una disputa bastante flamígera en ese hilo (el referenciado en el código : Диалог автора. Александр Смирнов. - MQL4 форум ) hizo el "MA de regresión cuadrática" como se define allí por "mathemat" (qwma es una parte de "MA de regresión cuadrática")

Así que aquí hay 2 : qwma (una variación de la media móvil ponderada lineal (diferentes coeficientes de peso) - violeta) y qrma (media móvil de regresión cuadrática - azul)
Archivos adjuntos:
qrma.mq4  3 kb
qwma.mq4  2 kb
qwma_-_qrma.gif  30 kb
 

Muchas gracias Mladen, es difícil de entender la disputa entre ellos con el traductor de google.Mladen es posible añadir la función de desplazamiento?

En segundo lugar, FIR MA tiene este retraso de 10 bares FIR MA - MQL4 Code Base, ¿es posible rellenar esos 10 bares con su nonlagMA? He visto una idea similar con HP, eliminando el recálculo con HMA: geHMA_HP - MQL4 Code Base

Archivos adjuntos:
 

Ahhhh, el eterno problema del lag

La solución perfecta existe, pero... como siempre, siempre hay un pero _____________________

Permítanme empezar de esta manera
:Lo que qpwr hizo allí es en realidad el centrado - si uno lo hace por el desplazamiento de los valores de resultado o el uso de los valores ya desplazados en el cálculo, no importa. El resultado es el mismo : deja una porción de valores "desconocidos". Y entonces hay que "inventarlos" - por extrapolación o de cualquier otra manera. Se puede añadir un ma no lag o cualquier otro ma (como en el filtro Hodrick/Prescott) pero entonces se obtiene una especie de Frankenstein del cálculo. Cualquiera que sea la forma que se utilice, es un tema de cambio y va a cambiar (esos son 2 cálculos diferentes - casco no es y no puede ser HP), por lo tanto, no creo que sea una forma lógica de hacerlo (se está rompiendo la lógica del indicador - parcheando 2 en 1)

Ahora, el centrado es una de las maneras que la gente está tratando de eliminar el lag .

.. _____________________

La otra forma es "la forma perfecta"...

La idea es de lo más sencilla. Cuando calculas una media, un filtro, lo que sea "de izquierda a derecha" estás sumando desfase. Por qué no calcular el resultado que obtienes una vez más pero ahora de "derecha a izquierda" y añadir lag negativo en ese caso, y obtener como resultado, ningún lag. No hay "lag cero" en los nombres, nada tan rebuscado, pero esa media simplemente no tiene lag. Independientemente del periodo de cálculo, independientemente del método de cálculo...

Como ejemplo: aquí hay una media móvil ponderada lineal "perfecta" sin lag en absoluto (violeta) en comparación con la LWMA regular (negro). No sólo no hay retardo, sino que es mucho más suave también (simplemente porque es 2 veces suavizado) El período de cálculo de la LWMA regular es 2 veces el período de cálculo de la "sin retardo en absoluto" (aunque no es una comparación completamente justa con respecto a la "sin retardo en absoluto" en este caso, pero no importa ahora)
Y ahora viene el "pero" : repinta las barras del último periodo de cálculo igual que cualquier otro método centrado y extrapolado, centrado y parcheado, o cualquier otro que intente eliminar el lag. Pero hay que admitirlo : se ve muy bien
biddick:
Muchas gracias Mladen,es dificil entender la disputa entre ellos con el traductor de google.Mladen ¿es posible añadir la función de desplazamiento? Lo segundo es que FIR MA tiene este lag de 10 bares FIR MA - MQL4 Code Base,¿es posible rellenar esos 10 bares con tu nonlagMA ? he visto una idea similar con HP , eliminando el recálculo con HMA : geHMA_HP - MQL4 Code Base
Archivos adjuntos:
 

Puedes identificar y enviarme la pagina wed de los indicayores que estan "On chart"

Puedes identificar y enviarme los indicayores o la pagina wed de los indicayores que estan "On chart"

Archivos adjuntos:
 

Alerta sobre DTosc_Smoothed

Mladen,

Por favor, ¿serías tan amable de añadir una alerta audible en el "#DTosc & Arrows - smoothed" para mí?

Similar a "#DTosc - flechas y alertas" que muy amablemente hiciste para mí hace un tiempo.

Agradeciéndole muy sinceramente.

Archivos adjuntos:
 

Shi trend Silver

mladen,

muchas gracias por corregir el Shi trend Silver

 

Tradefx1

Que yo recuerde no he hecho nada de eso

La razón : como expliqué en ese post (este post : https://www.mql5.com/en/forum/general ) la dirección de cálculo de la misma es "de izquierda a derecha". Si se cambia y si se cambia todo el resto de cosas de codificación que hay que cambiar, no se va a conseguir nada parecido a la plata de la tendencia SHI. Es un caso muy similar al de los cruces de 3 ema que cuando se invierte la dirección se convierte en efecto en una especie de MACD.

Creí que el post que puse era explicativo Si echas un vistazo a las señales verás que son casi todas erróneas si el cálculo se hace de derecha a izquierda (si uno tomara las señales que dan los puntos grandes, limpiaría la cuenta en un santiamén). Puedo corregir cuando algo tiene en error, pero no puedo transformar algo para que sea correcto y dé las mismas señales que el repintado y codificado erróneamente. No hay un indicador de señales de tendencia SHI "correcto", cuando todo está "corregido" lo que se obtiene es lo que se muestra en esa imagen

saludos

Mladen

Tradefx1:
mladen, muchas gracias por corregir el Shi trend silver