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
No esperaría eso de ti.
Me alegro de haberme equivocado en mis dudas.
A SK.
Tú lo sabes mejor. No considero que MQL sea un lenguaje de programación. Es un DIALECTO.
Por cierto, estoy harto de dos cosas en él:
1) no hay enumeración de operaciones, es decir, corchetes
2) volver - estás muy cansado de los paréntesis.
En definitiva, bien hecho, chicos.
Kernighan y Ritchie: un aplauso para ellos.
Retiro lo dicho.
Me alegro de haberme equivocado en mis dudas.
No tuvimos ninguna discusión :)
No considero que MQL sea un lenguaje de programación. Es un DIALECTO.
...
Tal como está, el valor inicial de la variable 123.00000000000 puede resultar ser 122.999999999999 en el momento en que se utilice en los cálculos. Y esto a pesar de que desde que se descubrió la variable, su valor nunca ha cambiado, sino que sólo ha sido solicitada por el programa para participar en otros cálculos.
De hecho, es por esto que hubo todo este alboroto. Por eso hemos decidido utilizar NormalizeDouble() lo más cerca posible del cálculo real, preferiblemente justo en la condición de las sentencias if, for, while.
Entonces tengo esta pregunta para usted
1? si el problema es recordar o leer una variable, ¿cómo puede ayudar NormalizeDouble() si el valor de retorno también se recuerda o se lee con un error?
2? ¿Por qué el esquema NormalizeDouble(value, digits) !OC! NormalizeDouble(valor, dígitos), donde !OC! - operador de comparación, ¿no funciona siempre? incluso si se inserta directamente en el if?
3? ¿Sabes cómo funciona NormalizeDouble() (algoritmo de la función)?
4? he escrito mi opinión al respecto, ¿qué te parece?
gravedad001 escribió (a):
...
Esa es la pregunta clave, ¿no? Yo también lo he pensado durante mucho tiempo: "si entras doble, recibes doble " ¿Qué podría cambiar?
No he encontrado la respuesta exacta. Pero me imagino que es así
doble a = 2.000000000000
doble b = 2.000000000001
doble c = 1,999999999999
Todas estas variables son diferentes y se almacenan en la memoria con precisión hasta el último dígito.
En este caso, nosotros mismos definimos los signos (dígitos). Todo lo que no está definido se llena de ceros.
Si hubiéramos definido el doble a = 2,0, y está almacenado en memoria como 2,0000001 o 1,9999999, está claro que NormalizeDouble() no ayudaría, ¡porque devolvería un valor inexacto!
Creo que ese error no se produce casi nunca al memorizar el valor de una variable. Además, no creo que el número 2,0 se almacene como 1,999999999999999 a propósito, ya que cada carácter (dígito o punto) se almacena con un bit específico en la cadena de bits. Por lo tanto, el número 2,0 se almacena con seguridad como 2,00000...00.
El otro caso es cuando no determinamos los signos nosotros mismos:
a = 4.0;
b = 2.0;
c = a / b // - la operación de "división" la realiza el procesador, o más bien el coprocesador, y rellena el premenente con caracteres (dígitos).
Después de la operación puede ser:
La más común:
с = 2.000...0
с= 1.99999999...
с= 2.00000001...
es decir, el resultado suele diferir del valor real en una pequeña cantidad.
Los errores grandes ocurren muy raramente:
с = 2.3
Aquí hay dos explicaciones:
1) parte de la cadena de bits se vio afectada en la memoria al llamar a o b, es decir, las variables a y b se modificaron.
2) se ha producido un error durante la operación de "división".
Creo que la 2) es la más frecuente. Por qué no lo sé. Creo que tiene que ver con el hecho de que el coprocesador está pensado para ser altamente optimizado en detrimento de la inutilidad.
Al comparar una variable con el número 2.000...00, la igualdad obviamente fallará. No todos los bits serán iguales.
Ahora, NormalizeDouble() está aquí para ayudar.
NormalizeDouble() "arreglará" este pequeño error.
Como el error suele ser muy pequeño, el redondeo con una precisión pequeña siempre dará el resultado correcto.
Míralo de esta manera:
Redondea el número a = 2,111...11 al segundo dígito.
NormalizeDouble() escribirá 2,11 en una nueva variable y rellenará los bits restantes con ceros, ¡no con unos!
Creo que se verá así:
Aquí, he intentado explicar lo mejor posible por qué se necesita NormalizeDouble().
Hasta hace poco estaba completamente satisfecho con esta explicación, pero recientemente me he convencido de que este esquema no siempre funciona
Por lo tanto, ¡estaré encantado de recibir cualquier crítica razonada y comprensible!
...
Tal como está, el valor inicial de la variable 123.00000000000 puede resultar ser 122.999999999999 en el momento en que se utilice en los cálculos. Y esto a pesar de que desde que se descubrió la variable, su valor nunca ha cambiado, sino que sólo ha sido solicitada por el programa para participar en otros cálculos.
De hecho, es por esto que hubo todo este alboroto. Por eso tuve que usar NormalizeDouble() lo más cerca posible del cálculo real, preferiblemente directamente en la condición de las sentencias if, for, while.
Estoy seguro. La fuente de sus conocimientos es su propia experiencia en la programación de MQL4 y las consultas de los desarrolladores.
NormalizeDouble() debe aplicarse inmediatamente antes de la operación de comparación. El resultado de la operación de comparación es un valor de tipo booleano, que nunca se "corrompe".
No lo he dicho. Así es exactamente como funciona y eso es lo que debes hacer.
No, no lo sé. Por favor, remítalo a los desarrolladores.
Su opinión es interesante, pero esta cuestión está resuelta desde hace tiempo. Es mejor utilizar las recomendaciones de los desarrolladores y no reinventar la rueda.
No lo he dicho. Así es exactamente como funciona y así es como debes hacerlo.
'De nuevo sobre la comparación de dos dobles', ¡1 página desde el primer puesto!
Desgraciadamente, la construcción NormalizeDouble(x-y,Digits) no es idéntica a la construcción NormalizeDouble(x,Digits) - NormalizeDouble(y,Digits)
Y no debería ser idéntico. La primera es correcta.
Creo que la construcción es
if (NormalizeDouble(x,Digits) - NormalizeDouble(y,Digits) != 0)
y la construcción
if (NormalizeDouble(x,Digits) != NormalizeDouble(y,Digits))
son idénticos.
¿Qué te parece?
Y no debe ser idéntico. La primera es correcta.
Creo que la construcción
if(NormalizeDouble(x,Digits) - NormalizeDouble(y,Digits) != 0)
y la construcción
if (NormalizeDouble(x,Digits) != NormalizeDouble(y,Digits))
son idénticos.
¿Qué te parece?
¿Y la opinión de Renat no es interesante? ¿No le interesa la opinión del director general de la empresa que desarrolla la MT?
¿O es usted como la anciana del cuento de Pushkin? ¡Sólo quiero-quiero-quiero! Recuerda cómo termina el cuento. "El pez no dijo nada. Movió la cola y se alejó nadando hacia el mar azul. Esperó mucho tiempo junto al mar para obtener una respuesta. No esperó, se volvió hacia la anciana..."
Y no debe ser idéntico. La primera es correcta.
Creo que la construcción
if(NormalizeDouble(x,Digits) - NormalizeDouble(y,Digits) != 0)
y la construcción
if (NormalizeDouble(x,Digits) != NormalizeDouble(y,Digits))
son idénticos.
¿Qué te parece?
¿Y la opinión de Renat no es interesante? ¿No le interesa la opinión del director general de la empresa que desarrolla la MT?
¿O es usted como la anciana del cuento de Pushkin? ¡Sólo quiero-quiero-quiero! Recuerda cómo termina el cuento. "El pez no dijo nada. Movió la cola y se alejó nadando hacia el mar azul. Esperó junto al mar durante mucho tiempo para obtener una respuesta. No esperó, se volvió hacia la anciana..."
Bueno, Renat dijo que la primera forma es correcta y la segunda es incorrecta, y tú dijiste que la segunda forma es correcta, ¿verdad?
No lo he dicho. Así es exactamente como funciona, y así es como debe hacerse.
Lo he dicho en el sentido de una comparación más o menos:
lo que significa que las construcciones del tipo no siempre funcionan:
Es decir, NormalizeDouble() debe insertarse justo en la cabecera del operador, lo más cerca posible de donde se calcula la operación de comparación.
En cuanto a la opinión de los desarrolladores, no pretendo discutirla.
Y entonces... ese hilo trataba de una construcción totalmente diferente:
Lo he dicho dando a entender una comparación más o menos importante:
Tuve errores de comparación cuando utilicé esta construcción:
¿Por qué, no lo sabes?