¿Está disponible el historial de garrapatas en el servidor? - página 2

Nuevo comentario
 
Pero, ¿por qué formar el historial no sólo por plazos, sino también por varios ticks? digamos 10, 100, 500, 1000, etc. En este caso resulta ser un gráfico de tiempo reducido a volumen. No se puede negar que el volumen es un indicador muy importante para el análisis. Será muy claro. Además, puedes formar el historial por el número de ticks o por el indicador de tiempo, según necesites. Los datos acumulados pueden compartirse en foros: quién ha recogido qué. No creo que sea difícil prever esto de forma programada. Para reponer los datos que faltan (el terminal se ha apagado), puede almacenar el historial de ticks en el servidor durante un pequeño periodo de tiempo (digamos, de 1 a 3 días).
 
No se puede negar que el volumen es un indicador muy importante para el análisis. Sería muy visual.


Al parecer, los promotores sólo tienen que clavar la página web en letras grandes y en un lugar visible: "¡No hay garrapatas y no las habrá! La discusión de las garrapatas, así como la discusión de los corredores, será eliminada de los foros" :o))). De lo contrario, todo dará vueltas cada semana. Sólo las palabras de los afectados sin ninguna prueba detallada de la necesidad de mantener las garrapatas...
 
¿Puede ser más específico sobre qué garrapatas estamos hablando?
Sería interesante ver el historial de garrapatas de las cuentas reales.
La literatura es tan apasionada sobre los gráficos que uno tiene que pensar dos veces antes de usar un EA para el comercio real.
Y no he visto en ningún sitio que el corredor haya puesto los archivos de garrapatas reales - así que empiezo a pensar, ¿tal vez realmente hay algo que ocultar?
 
Ahí es donde te pillan. Concretamente digo: demostrar que la modelización intramuros tiene serias discrepancias. Especialmente por 10 puntos. Sólo hay que tomar los datos, hacer la investigación, publicar todos los hallazgos (incluidos los archivos históricos) y clavarnos en la pared. <br / translate="no">.
Yo sostengo que el margen de error dentro de la modelización de los minutos está entre 1-2 puntos. Y este error es perfectamente aceptable y normal.

Renat,
No voy a probarlo, ya que estoy absolutamente de acuerdo con usted. Además, no voy a poner a nadie contra la pared. Lo declaro: Estoy bastante satisfecho con el modelado de garrapatas en el probador. No tengo absolutamente ninguna queja al respecto.

Al mismo tiempo lo repito una vez más:
La necesidad de una historia de garrapatas no tiene nada que ver con el modelado en el probador.

Y todo lo que podría decir para justificar su necesidad lo dije arriba.

solandr,
Si los usuarios no son proactivos y persistentes a la hora de explicar sus necesidades a los desarrolladores, tanto los usuarios como los desarrolladores se verán perjudicados.
Si los desarrolladores no muestran paciencia y comprensión, pero también un enfoque estratégico a la hora de desarrollar sus productos, tanto los usuarios como los desarrolladores se verán perjudicados.
Espero que lo entiendas.
 
...y además, estamos hablando de MT5, Renat, ¿cuándo está previsto que salga al mercado?
¿será compatible con MQL4, o será algo nuevo?
...¿Será compatible con MQL4 o será algo nuevo?
 
Ahí es donde te pillan. Digo específicamente - demostrar que el modelado intra-minuto tiene serias discrepancias ... <br / translate="no"> Yo sostengo que el margen de error dentro de la modelización de los minutos está dentro de 1-2 puntos. Y ese margen de error es perfectamente aceptable y normal.

Sigues hablando del aspecto del precio del mercado. En este caso ha acertado sin duda y el error en la modelización del PRECIO es insignificante.
Sin embargo, el flujo de cotizaciones tiene otros parámetros que son totalmente destruidos por la modelización, especialmente durante los períodos de movimientos de noticias.
En mi opinión, se necesita SOLO el historial de ticks del que se puede obtener CUALQUIER marco temporal y no solo marcos temporales, sino también tickframes (en una vela, por ejemplo, 10 ticks) y gráficos cagi y cruces y ceros.
Es decir, se eliminan TODAS las restricciones artificiales relacionadas con los plazos.
 
En mi opinión, necesitamos SÓLO el historial de ticks del que podemos obtener CUALQUIER marco temporal y no sólo los marcos temporales, sino también los marcos de ticks (en una vela, por ejemplo, 10 ticks) y los gráficos de jaula y tic-tac-toe. <br / translate="no"> Es decir, se eliminan TODAS las restricciones artificiales relacionadas con los plazos.



Absolutamente de acuerdo con eso. ¿Es necesario que los desarrolladores demuestren que los marcos de tiempo tienen el mismo derecho a existir que los marcos de tiempo? Si hay dificultades para almacenar SOLO el historial de ticks debido a una gran cantidad de datos para cualquier marco de tiempo significativo, entonces puede al menos almacenar marcos de ticks fijos, como se hace ahora con los marcos de tiempo. Este es mi deseo y no tiene nada que ver con probadores, asesores expertos y otras tonterías. Llevo cerca de un año operando en una cuenta real y sólo lo hago de forma manual. Si hay algún tipo de movimiento en el precio es elemental para operar con beneficio, pero si el precio está simplemente a la deriva en un lugar, ningún asesor experto ayudará. Y dejar que el ordenador tome la decisión por sí mismo - Dios no lo quiera.
Por lo tanto, creo que los tick-frames son un reflejo mucho más preciso del movimiento de los precios, y personalmente me sentiría más cómodo con ellos. ¿Qué tan difícil puede ser?
 
Me parece que la mejor forma de almacenar la historia es hacerlo en minutos de calidad.
Se puede construir cualquier marco a partir de ellos (incluso marcos de tiempo, incluso tic-tac-toe, incluso
para ser doblado de acuerdo con algunas otras características).
Lo que es realmente importante es la uniformidad de los ejes de los gráficos principales de MT4,
que se basan en datos recogidos en intervalos de tiempo constantes...

Pero puede ser decidido
sólo en la próxima versión de MT ... Entonces usted puede ver el cuadro al menos de una vez
en las ondas (no escribo Eliot, porque hay ondas, pero su estructura es muy cuestionable ...).
En general, estoy a favor de una historia básica de minutos de CALIDAD.
 
Creo que nadie discutirá que el tiempo no es la mejor variable para fijar el precio, el precio depende más del número y volumen de operaciones, y el volumen de ticks es función de estos parámetros (o algo parecido). Por eso, para los investigadores, los marcos de tics serían más interesantes que los marcos de tiempo.
En cualquier caso, si se hace una simple estimación sobre los que se han expresado en esta rama, hay una mayoría absoluta de los que les gustaría.
 
Si yo hiciera mi propio terminal =))), haría esto:
En el servidor sólo almacenaría los ticks, y sólo permitiría su descarga.
En el cliente haría todos los TimeFrames (y TickFrames) necesarios a partir de ticks.

Así, para obtener un gráfico de cualquier (cualquier) TF durante un año, necesitaríamos 35,7 Mb de tráfico (cálculos de Yurixx).
Ahora, MT4 necesitará unos 20,763 Mb de historial para todos los TFs del mismo periodo (15,71 + 3,142 + 1,047 + 0,524 + 0,262 + 0,065 + 0,011 + 0,002).

En resumen, las ventajas de la historia de las garrapatas:
- El usuario decide por sí mismo qué TFs quiere y siempre puede construirlos él mismo.
Contras del historial de garrapatas:
- la cantidad de tráfico consumido aumenta 1,7 veces (en comparación con la descarga de todos los TF);
- aumenta la carga del procesador (por la construcción constante de los TFs necesarios).


Si yo hiciera mi propio terminal, me lo pensaría bien primero ....
1234567
Nuevo comentario
Razón de la queja: