Errores, fallos, preguntas - página 673
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
Renat, cero - ¡muchas gracias por su atención al tema y su respuesta constructiva!
Siguiente.
1. sobre x64
Renat:
La opción más correcta es actualizar a x64.
...
Por supuesto, si alguien va a llamar a cientos de indicadores en el modo de exploración del mercado sin su descarga, debe ir directamente a la versión de 64 bits + instalar memoria adicional.
Es extraño estar haciendo pruebas masivas sentado en x32 en este momento. Cualquier ordenador x64 decente con 16 GB de memoria (sin ser fanático de las tarjetas gráficas y los monitores) puede comprarse por 15.000 rublos.
Pasar a x64 es, sin duda, lo más adecuado. Pero. Una cosa no excluye la otra. Incluso mis 16gigs (los tengo) no quiero malgastarlos en algunos datos innecesarios. Tengo otras cosas en las que trabajar en paralelo: MSVS, Matlab, etc., en las que también quiero calcular tareas voluminosas. Me alegro de que lo entiendas y estés dispuesto a buscar formas de ahorrar dinero.
2. sobre un inicio fijo de la historia:
Renat:
Nosotros mismos queremos reducir el consumo de recursos. Tal vez la solución podría ser alguna función IndicatorMaxDepth(uint len), que actuará sólo en los indicadores creados en este EA.
Pero el problema es que durante las pruebas los búferes de los indicadores en modo de acumulación crecerán junto con el historial y no se podrá guardar.
Completamente (casi) de acuerdo. Descargo de responsabilidad: En muchos casos la optimización se hace sobre un pequeño trozo de la última historia. En este caso, el ahorro puede ser muy importante. Aun así, considero que la opción es relativamente operativa, sobre todo si tienes un buen trabajo o estimaciones sobre la aplicación. A mí, por ejemplo, la opción no me parece del todo completa: mucho trabajo, y el resultado no es radical. Es una solución a medias.
3. ¡aquí hay una idea! :
Renat:
Recortar el historial del indicador en rltime, manteniendo la profundidad establecida , está plagado de bonitos fallos y dejará directamente fuera de juego a los programadores que calculan/acostumbran al sincronismo de barras del gráfico y del buffer del indicador.
¡No! no está cargado - si las barras del gráfico se comportan de la misma manera - sincrónicamente. En otras palabras, si los búferes de los anillos (aunque sean de diferente tamaño) siempre (forzosamente) usar la bandera AsSeries - no se espera ningún problema masivo para el usuario.
// En este caso, sería conveniente hacer que todos los buffers de historia que se presentan al usuario sean - indicadores (es decir, circulares, con AsSeries=true).
En esta variante:
(1) existe una representación interna de las matrices de indicadores y precios (en su lado) : indexación de izquierda a derecha (AsSeries==false), los tamaños no conciernen al usuario, y de hecho"la entrada está prohibida".
Y (2) hay un lado del usuario - todos los buffers son circulares (en la implementación. el usuario ve un array lineal virtual), la indexación es de derecha a izquierda (AsSeries==true) y el tamaño lo establece el usuario.
¿Cuál es el techo del usuario aquí? Ninguno. Cuando está fuera de rango - respuesta estándar Array fuera de rango.
Sólo usted tiene dificultades (no pequeñas, para ser honesto). Pero! Teniendo en cuenta la universalidad del esquema - usted tiene que esforzarse sólo una vez. Y para cortar de raíz todos los "bonitos fallos", en la depuración beta. Después de eso - la felicidad universal y la construcción muy económica .
Vamos a realizar la revisión del indicador de caché, que ahora utiliza el principio de máxima eficiencia frente al principio de ahorro de memoria. Los indicadores rechazados se descargarán inmediatamente, en lugar de mantenerlos en memoria durante algún tiempo, como se hace ahora. Esto permitirá llamar a cientos de indicadores seguidos con una descarga directa a través de IndicatorRelease.
3. ¡Aquí viene el yazel! :
¡No! No lo hará -si las barras del gráfico se comportan de la misma manera- de forma sincronizada. En otras palabras, si los búferes de los anillos (aunque sean de diferente tamaño) siempre (forzosamente) usar la bandera AsSeries - no se espera que el usuario tenga problemas masivos.
// En este caso, sería conveniente hacer que todos los búferes históricos proporcionados al usuario sean indicativos (es decir, circulares, con AsSeries=true).
En esta variante:
(1) existe una representación interna de las matrices de indicadores y precios (en su lado) : indexación de izquierda a derecha (AsSeries==false), los tamaños no conciernen al usuario, y de hecho"la entrada está prohibida".
Y (2) hay un lado del usuario - todos los buffers son circulares (en la implementación. el usuario ve un array lineal virtual), la indexación es de derecha a izquierda (AsSeries==true) y el tamaño lo establece el usuario.
¿Cuál es el techo del usuario aquí? Ninguno. Cuando el usuario sale del alcance - reacción estándar Array fuera del alcance.
Sólo usted tiene dificultades (no pequeñas, para ser honesto). Pero! Teniendo en cuenta la universalidad del esquema - usted tiene que esforzarse sólo una vez. Y todos los "bonitos fallos" tienen que ser cortados de raíz durante la depuración de la beta. Después todo el mundo está contento y la construcción es muy económica .
Buena idea, estoy a favor. Pero no anula la aplicación del esquema de anillos, sino que lo complementa muy bien.Permítanme describir las condiciones de la prueba:
Como resultado de la subcotización automática del indicador
Describiré las condiciones de la prueba:
Como resultado de la subcotización automática del indicador que:
1.
Sí, es tolerable. Difícilmente provocará el descontento de las masas, al contrario, la economía será muy atractiva. Nadie prohíbe malgastar la memoria instalando una enorme MaxBar.
// ¡Pero los indicadores fallan debido a la omisión de barras! ¡Ahí es donde se justifica el descontento!
// Así que toleras incluso eso... :) Bueno, tenemos que... :(
2.
Pues no y no! El esquema circular es justamente lo que permite un gran ahorro en la copia en los turnos de historia. En realidad, al desplazar una barra (N barras), tenemos que copiar exactamente un valor (N valores). Los costes(de usuario) de la virtualización de índices son insignificantes. De hecho, son incluso difíciles de detectar en las pruebas de estrés( elresto de la división es calculado por el procesador durante un ciclo de reloj + el desplazamiento del inicio del buffer virtual en cada cambio a través de la historia toma otro par de ciclos de reloj). Por lo tanto, casi no hay pérdida de velocidad. Es imposible detectar esta ralentización, es tan pequeña. Y en un contexto de gran ahorro de memoria, estas pérdidas son inconmensurables con la ganancia.
3.
Ehhh, una cara...
Por alguna razón, hay mucho baile y gritos sobre los indicadores que se ahogan en las barras ilimitadas, pero ni una palabra sobre los objetos gráficos que bailan. Trate de construir, por ejemplo, super grande Pitchfork de Andrews en ilimitado (en MN1, por ejemplo), a continuación, limitar el número de barras en la configuración de la terminal, ir a los marcos de tiempo bajos y rebobinar a los puntos de anclaje. Algunos de ellos estarán en un tremendo desfase con respecto a los extremos (esto es así mientras las horquillas de los tres puntos se sitúan exclusivamente en la zona de las barras M1 reales, ¡sin sobrepasar el límite de las falsas de los marcos temporales superiores!) ¿Y por qué? Aparentemente, porque no teníamos suficientes datos históricos sobre M1 para calcular el valor M1 exacto de algunos puntos de autoenlace. Pero, ¿qué tienen que ver los datos históricos? Bueno, tal vez eran suficientes, pero las barras expuestas en el escaparate no lo eran, de ahí los turnos. Es decir, algunos puntos "no saben realmente dónde están".
Me gustaría que alguien lo comprobara por sí mismo, o quizás soy el único que tiene semejante lío...
Me he dado cuenta de una rareza.
En el momento de formarse una nueva barra si se leen los valores de Apertura y Cierre de las barras anteriores (por ejemplo 10 barras anteriores) y luego 5 segundos después se obtienen de nuevo, entonces algunos de estos valores son diferentes y luego si se obtienen mientras se está formando una nueva barra entonces todo está bien, pero en los primeros segundos por alguna razón estos valores son diferentes.
Espero haberlo explicado claramente.
¿Puede decirme si antes de leer los valores de las barras de apertura y cierre desde el comienzo de una nueva barra debe haber un retraso de más de 5 segundos?
He aquí un ejemplo de funcionamiento:
Arriba se activa correctamente después de un retardo, abajo justo después de una nueva barra con un error, y a la derecha la referencia de la 6ª línea.
Tal vez el problema sea la falta de sincronización, una nueva barra debería ser rastreada preferentemente por todas las herramientas en uso.
Sí, resultó tener razón, ¡gracias!
Del mismo modo, la ópera.