![MQL5 - Lenguaje de estrategias comerciales para el terminal de cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Hay una pregunta de los colegas:
¿no sería más lógico que trasladáramos los cálculos a la historia de los minutos? Es decir, nos interesan sobre todo las previsiones anteriores a M5, para mí siempre ha sido interesante en 5 y 15 min...
lo que hay que hacer - cuando se cambia a un TF más alto, cambiar el suavizado (filtrado) para los valores diminutos de velocidad y aceleración ... Dado que la formación de las barras en el marco de tiempo más antiguo se hace por OHLC, el filtrado (suavizado) al obtener un punto calculado de las barras anteriores para la comparación, parece ser demasiado áspero ... En realidad mirando las previsiones de todos los TFs disponibles llegué a la conclusión de que los ajustes de un TF no son apropiados para los otros, según entiendo todo es causado por una estructura de barra gruesa ... Creo que es más lógico utilizar la unidad de historia más pequeña - la barra M1 y sin cambiar a TFs más antiguos (sobre M30) construir las previsiones sobre la base de barras de minutos utilizando sólo el filtrado más duro.
De hecho la propia gradación M1, M5, M15 ... es inverosímil... Al menos la distorsión de las previsiones debido a la simplicidad de un filtro como BAR en mi opinión es evidente.
En mi opinión, nen, por eso tomó como base la ZZ multitemporal. En su puesto :
Indicador http://www.onix-trade.net/forum/index.php?showtopic=85972&view=findpost&p=386627
Todos los gráficos son de 1 minuto, es decir, la aceleración se cuenta por minutos, pero la ZZ puede tomarse de cualquier marco temporal principal.
Por lo tanto, si nen hace posible ver todas las situaciones que cumplen las condiciones en la historia, incluso cuando la rodilla ZZ fue re-dibujado (si había condiciones para la construcción de Fiba), entonces será posible ver el TF óptima para determinar la aceleración y hacer conclusiones definitivas sobre la viabilidad de este enfoque. Personalmente no dudo de la solidez de la idea, es sólo que algo no se ha sentido aún y si no caemos en burbujas y puntos entonces todo estará bien.
...
Personalmente, no dudo de la solidez de la idea, es que todavía no se ha hecho algo a tientas y si no volvemos a caer en las machas y en los puntos, entonces todo estará a punto.
¡¡¡Estoy de acuerdo!!! >> Seguiré investigando el producto.
Boris te sigo pidiendo que no dejes de perfeccionar tu indicador...
Encontrado el indicador KvantLevels de Integer ... Es una alternativa divertida a los KvantLevels.
KvantLevels como alternativa a Accelerator
¿Puedo obtener un enlace al indicador?)
http://dmffx.com/index.php?page=2&subpage=3
Versión 2
minSize_0_100_fibo - distancia mínima entre los niveles 0 y 100 de Fibo en puntos. 0 - cualquier distancia.
CalculationVariant - variante del cálculo de la velocidad. 0 - la velocidad se calcula entre las barras situadas a una distancia especificada por el parámetro Barra.
1 - la velocidad se calcula en relación con la barra donde se encuentra el extremo del zigzag.
Parece que el "Acelerador" debe ser tratado por separado ...
1. ¿Por qué " CalculationVariant = 1" tiene el efecto de cambiar el parámetro "Bar" ...? es decir, el valor de Bar= ... ... ¡no debería afectar a los cálculos!
2. El "acelerador" debe modificarse por separado para poder ver el gráfico ...
Parece que el "Acelerador" debe ser tratado por separado ...
1. ¿Por qué " CalculationVariant = 1" tiene el efecto de cambiar el parámetro "Bar" ...? es decir, el valor de Bar= ... ¡no debería afectar al cálculo !
Porque sí:
Ahora vamos al grano.
Velocidad = Distancia / tiempo y calcularlo a partir de ZZ (como has sugerido) es bastante lógico :
Distancia = Valor(LowestZZ o HighestZZ) - Valor(barra calculada);
tiempo = NoBar(LowestZZZ o HighestZZZ) - NoBar(barra de diseño)
y la aceleración ya se contaría correctamente como :
Aceleración = Velocidad(Barra estimada) - Velocidad(Barra estimada+1).
Entonces, ¿la velocidad debe calcularse con respecto al extremo del zigzag y la aceleración con respecto a la barra adyacente? ¿Verdad?
Así que
La velocidad cuenta en relación con la ruptura del zigzag, y la aceleración cuenta igual que antes
.Para esta variante sólo hay que poner Bar=1
===========
La versión donde Bar = 1 para CalculationVariant = 1 está codificada. No hay posibilidad de elegir.