Errores, fallos, preguntas - página 2573

 

Sí, entonces no tienes que preocuparte por la sobrecarga del disco.
Lo que me sorprende es el uso de variables globales de terminal (si es que se trata de eso) para guardar grandes conjuntos de datos.
Es una muleta espeluznante, ¿no?

De acuerdo, las variables en sí, pero hay sus nombres de cadena, que también debe ser almacenado y todavía hacer cada vez que una búsqueda de la cadena para el acceso a esta variable, por no hablar de la única de tipo doble, que puede ser almacenado. Claro que puedes usar la unión, pero usarla no es gratis.

Es mucho más correcto implementar el guardado de forma independiente a través de los recursos de cualquier matriz de datos con autoguardado en disco o cuando se produce el evento deinit

 
Nikolai Semko:

Las variables en sí están bien, pero hay nombres de cadena, que también deben ser almacenados y todavía hacer cada vez que una búsqueda de la cadena para acceder a esta variable, por no hablar de la única clase de doble, que puede ser almacenado. Está claro que podemos utilizar la unión, pero su uso tampoco es gratuito.

Tenía la idea y el deseo de usar variables globales, pero decidí guardarlas en el disco de la manera antigua, especialmente ahora que empecé a escribir código correctamente - los datos se almacenan en estructuras, y puedes volcar las estructuras al disco en un solo clic - FileWriteStruct().



y la suma de comprobación en doble con Base64 - todo está listo en CryptEncode(), e idealmente debería ser Base85 ( Ascii85 ) o visto en algún lugar el código fuente en el githab Base128

y si no me equivoco, el nombre de la variable global en el terminal es de 256 caracteres... la eficiencia de Base64 es ligeramente superior al 60% (tamaño), otros métodos de codificación tienen mayor eficiencia - se pueden almacenar 160-180 bytes en una variable global

Aunque tendrá que determinar los datos utilizando el prefijo, pero en general, funcionará - tanto más cuanto que las variables globales se utilizan raramente - todos los nombres son esencialmente libres

 
Igor Makanu:

Tuve la idea y el deseo de usar variables globales, pero decidí guardarlas en el disco a la antigua usanza, especialmente ahora que he empezado a escribir códigos lo más correctamente posible - almaceno los datos en estructuras, y puedo volcar las estructuras al disco en un solo clic - FileWriteStruct().



y la suma de comprobación en doble con Base64 - todo está listo en CryptEncode(), e idealmente debería ser Base85 ( Ascii85 ) o visto en algún lugar el código fuente en el githab Base128

y si no me equivoco, el nombre de la variable global en el terminal es de 256 caracteres... la eficiencia de Base64 es ligeramente superior al 60% (tamaño), otros métodos de codificación tienen mayor eficiencia - se pueden almacenar 160-180 bytes en una variable global

Aunque tendrás que determinar los datos usando el prefijo, pero en general todo funcionará - cuanto más que las variables globales se usan raramente - todos los nombres son esencialmente libres

Aun así, para llegar a una variable, hay que recorrer las sumas de comprobación hasta encontrar la correcta. ¿Y si hay muchas variables?
O puede seguir la secuencia de variables y asignarles índices. Pero esto es absolutamente inútil, porque es más fácil escribir una clase para guardar datos
 
Nikolai Semko:
es más fácil escribir una clase de ahorro de datos

La clase está dispuesta, incluyendo ejemplos. Los desarrolladores introducirán una nueva funcionalidad que permite, ya sin escribir envoltorios alrededor de los recursos, transferir datos.

Lasvariables globales se utilizan para las banderas. También es conveniente ver siempre sus valores - F3.

 
fxsaber:

La clase está dispuesta, incluyendo ejemplos. Los desarrolladores introducirán una nueva funcionalidad que permite, ya sin escribir envoltorios alrededor de los recursos, transferir datos.

Lasvariables globales se utilizan para las banderas. También es conveniente ver siempre sus valores - F3.

Sí, lo hice. Por eso me sorprendió.
Para el control del valor estoy de acuerdo, entonces justificado.
 
Georgiy Merts:

Encontré que en mi modo de prueba visual SymbolInfoTick() devuelve un valor pero la serie de tiempo Close[0] tiene un valor diferente.

¿Es un error mío? ¿Estoy haciendo algo mal?

Parece que deberían ser los mismos valores:

Normalmente la diferencia es de 1-2 puntos, pero en los movimientos bruscos puede ser mayor.

¿Sólo soy yo?

Por ahora he tomado las series temporales como "más correctas". Si resulta que SymbolInfoTick() da un valor diferente al de Close[0], entonces asumo que el valor correcto es Close[0] y dejo un spread tal y como lo devolvió SymbolInfoTick().

Pero, es interesante entender, qué precio es correcto, qué precio es "buscado" por DC - SymbolInfoTick() o Close[0].

¿Cuál es el número de construcción?

La compilación 2155 ya debería estar arreglada: este error se solucionó la semana pasada

 
Slava:

¿Cuál es el número de construcción?

La compilación 2155 ya debería estar solucionada, ya que la semana pasada solucionaron ese error

Sí. Y tengo 2085.

Entendido, actualización.

P.D. Sí, los valores son los mismos ahora.
 
Slava:

¿Cuál es el número de construcción?

La compilación 2155 ya debería estar arreglada: este error se solucionó la semana pasada

¿Sabe algo al respecto?
https://www.mql5.com/ru/forum/1111/page2571#comment_13285021
 
Aleksei Beliakov:
¿Sabe algo al respecto?
https://www.mql5.com/ru/forum/1111/page2571#comment_13285021

No has dado ningún detalle para reproducir

 
Slava:

No ha dado ningún detalle para reproducir

Banal si imprime los resultados de estas funciones en ontick, es para el tiempo 1970.01.01 para el precio 0
Antes era la hora del bar o del precio.
Así que ahora sí.
iHigh(NULL,PERIOD_W1,0) в журнале будет 0
iTime(NULL,PERIOD_W1,0) в журнале будет 1970.01.01