Pregunta a los maestros del MQL4. De nuevo sobre la doble comparación. - página 9

 
SK. писал (а):

Lo he dicho en el sentido de una comparación más o menos:

if (NormalizeDouble(x,Digits) > NormalizeDouble(y,Digits))

lo que significa que las construcciones de vista no siempre funcionan:

double a = NormalizeDouble(x,Digits);
double b = NormalizeDouble(y,Digits);
 
if (a > b)
  {
  ...
  }
Creo que la primera y la segunda tienen el mismo resultado.
Los resultados asignados a las variables a y b se normalizan y luego se pueden comparar, no les pasará nada.
Renat escribió sobre otra cosa, porque en ese ejemplo el resultado de la resta de valores normalizados, a su vez, no está normalizado.
Si se normaliza el resultado final de una operación, se puede asignar a una variable y manipularlo posteriormente. Lo principal es que la propia variable no debe cambiar su valor más adelante.
 
gravity001:
No he comprobado ni más ni menos, pero sí la igualdad.
He tenido errores de comparación cuando he utilizado esta construcción:

if (NormalizeDouble(x, digits) == NormalizeDouble(y, digits))
{
    ...
}
¿Por qué, no lo sabes?

¿Qué tipo de errores?
 
Simca:
Y para mí el primero y el segundo en cuanto al resultado UNO Y UNO.

Esto funciona en algunos casos, pero no siempre. Este "no siempre" viene dictado por la peculiar forma en que se almacenan los valores en la memoria del ordenador. Eso es todo.

Los resultados asignados a las variables a y b están normalizados y pueden ser comparados posteriormente, no les pasará nada.
No se puede. Es decir, puede hacer lo que quiera, pero para obtener un resultado garantizado, debe aplicar NormalizeDouble() directamente en la expresión que contiene la operación de comparación.

Renat escribió sobre otra cosa, porque en su ejemplo el resultado de la resta de valores normalizados no está normalizado.
Sí, pero eso no significa que sus afirmaciones anteriores sean correctas.

Si se normaliza el resultado final de una operación, se puede asignar a una variable y manipularlo posteriormente. Lo principal es que la propia variable no debe cambiar su valor más adelante.
Puede cambiar su valor en el último dígito debido a la tecnología informática específica en uso. Esto puede ocurrir, y de hecho ocurre, sin que el usuario se dé cuenta. Esa es la cuestión. En algunos casos funcionará (por ejemplo, durante la depuración de un programa), pero al utilizar este programa a menudo funcionará como esperaba el desventurado programador y a veces no funcionará.

 

Mi más sincero pésame a los desarrolladores que tienen que explicar lo mismo 1000 veces a cada nuevo usuario.

 
SK. писал (а):
gravedad001:
No he comprobado esta construcción para más o menos, pero sí para la igualdad.
Tuve errores de comparación cuando utilicé esta construcción:

if (NormalizeDouble(x, digits) == NormalizeDouble(y, digits))
{
    ...
}
¿Por qué, no lo sabes?

¿Qué tipo de errores?
¿No se cumple la condición, es decir, no se cumple la igualdad?
Además, ¿por qué crees que el error se produce al almacenar o leer variables dobles de la memoria? ¿Tal vez un error en las operaciones aritméticas?

¿Cree que no puede haber error en un caso así?

double a = 4.0;
double b = 2.0;

double c = a / b; // думаете, здесь в опрерации "деления" не может быть ошибки
                     (т.е. появление цифр отличных от нуля после точки)?
 
gravity001 писал (а):
На больше или меньше я не проверял эту конструкцию, а вот на равенство проверял.
У меня были ошибки при сравнении, когда я использовал такую конструкцию:

if (NormalizeDouble(x, digits) == NormalizeDouble(y, digits))
{
    ...
}
Почему, не знаете?

¡¡¡¡Por favor, demuestre este error!!!!
 
gravity001:
¿No se cumple la condición, es decir, no se cumple la igualdad?
Además, ¿por qué crees que el error se produce al almacenar o leer variables dobles de la memoria? ¿Tal vez un error en las operaciones aritméticas?

¿Crees que no puede haber un error en ese caso?

double a = 4.0;
double b = 2.0;

double c = a / b; // думаете, здесь в опрерации "деления" не может быть ошибки
                     (т.е. появление цифр отличных от нуля после точки)?

Creo que la operación de división en sí se ejecuta correctamente.

La cuestión que se discute no es cómo obtener el valor de alguna variable (ya sea el valor obtenido como resultado de los cálculos o por la inicialización de la variable), sino sobre el destino del valor de esa variable durante la ejecución del programa e incluso el simple funcionamiento del ordenador. Y su destino es imprevisible. Por lo tanto, cuando se programen operaciones lógicas, se debe utilizar la funciónNormalizeDouble() de color rojo.

Aplicarlo es bueno. Aplicarlo correctamente es muy bueno.

No usarlo es malo. Uso incorrecto - malo.

---

De vacaciones quiero...

 
SK. писал (а):
En algunos casos funciona, pero no siempre. Este "no siempre" viene dictado por las peculiares formas de almacenar valores en la memoria del ordenador. Eso es todo.
Conozco las formas de almacenar valores en la memoria del ordenador. :) Tengo unos 20 años de experiencia en programación. En el pasado, incluso enseñé programación a estudiantes universitarios.

Los resultados asignados a las variables a y b están normalizados y pueden ser comparados posteriormente, no les pasará nada.
No se puede. Por lo tanto, puede hacer lo que quiera, pero para obtener un resultado garantizado, debe aplicar NormalizeDouble() justo en la expresión que contiene la operación de comparación.

Naturalmente, antes de poder comparar el resultado del cálculo de una expresión con algo, hay que normalizarlo. ¿Quién puede discutirlo? Pero es irrelevante para nuestro argumento. Me refería a la identidad del código. La diferencia es que en el segundo caso, los resultados de la normalización se almacenan en variables. ¡Y ESO ES TODO!

Es decir, afirmas que la función NormalizarDoble tiene un resultado con un tamaño de bit superior a double (el resultado de esta función ocupa al menos un bit de memoria). Sólo así puedo explicar cualquier pérdida (o cambio) al almacenar el resultado de la función en una variable. O, al asignar, se realiza alguna operación complicada, no la simple duplicación byte a byte de los datos de una posición de memoria a otra.

Una vez más, no estoy discutiendo la corrección de las normalizaciones separadas de los operandos derecho e izquierdo de la operación de comparación o cualquier otra cosa. Sólo estoy cuestionando si los resultados de los dos fragmentos de código anteriores son idénticos.

Si se normaliza el resultado de una operación, se puede asignar a una variable y seguir operando con ella. Lo principal es que la variable en sí no debe cambiar su valor más adelante.
Puede cambiar su valor en el último dígito debido a la tecnología informática específica utilizada. Esto puede ocurrir, y de hecho ocurre, sin que el usuario se dé cuenta. Esa es la cuestión. En algunos casos funcionará (por ejemplo, durante la depuración de un programa), y al utilizar este programa a menudo funcionará como esperaba el desventurado programador, y a veces no funcionará.

¡WOW! ¿Y a qué tipo de "tecnología informática específica" se refiere? Muchas cosas "pasan desapercibidas" para el usuario, pero al fin y al cabo somosprogramadores. :) Nada debe pasar desapercibido para nosotros, de lo contrario no será un ordenador sino un generador de resultados imprevisibles. :) ¿O tal vez nuestro ordenador ya tiene algunos bits errantes? Pueden leer de una manera u otra... ¡Una vez más! En las operaciones aritméticas con números reales el resultadono es absolutamente exacto (tiene que ver con la forma de representar los números reales). Pero esto no se aplica a las operaciones de asignación. Una vez que la función NormalizeDouble ha funcionado y ha devuelto un resultado de tipo double, este resultado se coloca en una variable simplemente copiando el valor (todos los bytes coincidirán). Además, mientras el valor de la variable no se modifica (es decir, sólo se puede leer, pero no se escribe nada en ella), se conserva en su forma original y no hay signos que floten en ningún sitio. Léalo y obtendrá lo mismo. Pero si sólo lo multiplicas por 1 y escribes el resultado, nada está garantizado.

 
SK. писал (а):

Mi más sincero pésame a los desarrolladores que tienen queexplicar lo mismo 1000 veces a cada nuevo usuario.

Es un ataque descarado, creo que lo ignoraré. :)
 
gravity001:

Crees que no puede haber un error en un caso así:

double a = 4.0;
double b = 2.0;

double c = a / b; // думаете, здесь в опрерации "деления" не может быть ошибки
                     (т.е. появление цифр отличных от нуля после точки)?

En este caso, el resultado de la operación sería APLICABLE 2.0
Un error en dígitos muy lejanos puede deberse a la forma de representar los números reales.
Razón de la queja: