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

Nuevo comentario
 
Una vez más.

Precios, lotes, dinero - precisión fija.
Los indicadores son flotantes.

Esta diferencia es en esencia, aunque el doble se utiliza para representar a ambos. En realidad, determina lo que se llama "estilo de programación".
De nuevo, el criterio de "corrección" de cada uno es diferente. A mi entender, por ejemplo, NormalizeDouble() es una función ridículamente ineficiente y, en consecuencia, absolutamente innecesaria.
 
komposter:
//--- Если value1 равняется value2 до precision знака после запятой, возвращает true, иначе - false.
bool equal( double value1, double value2, int precision = 8 )
{
    return( nd( abs( nd( value1, precision ) - nd( value2, precision ) ), precision ) < nd( MathPow( 0.1, precision ), precision ) );
}
El código es claro, y tu ejemplo es muy ilustrativo. Y este es un punto de inflexión.
nd( MathPow( 0.1, precision ), precision )
¿no sería mejor sustituirlo por
//--- Если value1 равняется value2 до precision знака после запятой, возвращает true, иначе - false.
bool equal( double value1, double value2, int precision = 8 )
{
    return( nd(nd( abs( nd( value1, precision ) - nd( value2, precision ) ), precision )), precision ) == 0.0 );
}
¿O está mal?
 
Irtron:
El problema de la comparación de números con doble precisión es exagerado y proviene de la ignorancia básica de las matemáticas.
Pero con una persistencia envidiable aparece en el foro.
O bien da instrucciones claras sobre cómo resolver este "problema", o una de las dos =)

Irtron:
Pero habrá problemas de rendimiento.
¿Alguna sugerencia (a nivel de usuario, no a nivel de desarrollador de MT)?
 
komposter:
¿Alguna sugerencia (a nivel de usuario, no a nivel de desarrollador de MT)?
Por ejemplo, el precio. Ofertas, ahí, preguntas, paradas:
int ComparePrice(double a, double b)
{
    a -= b;
    b = Point / 2.;
    if (a > b)
        return (1);
    if (a < -b)
        return (-1);
    return (0);
}
A menudo es mejor hacer todos los cálculos de lotes y niveles en números enteros. Muchas veces más rápido y sin errores de muestreo en principio.
 
Irtron:
Una vez más.

Precios, lotes, dinero - precisión fija.
Los indicadores son flotantes.

Esta diferencia es en esencia, aunque el doble se utiliza para representar a ambos. En realidad, determina lo que se llama "estilo de programación".
De nuevo, el criterio de "corrección" de cada uno es diferente. A mi entender, por ejemplo, NormalizeDouble() es una función ridículamente ineficiente y, en consecuencia, absolutamente innecesaria.
Hace poco, en algún hilo (no recuerdo exactamente), una persona se quejaba del extraño funcionamiento del Asesor Experto. ¡Y resultó que incluso el precio tomado del servidor para su orden todavía necesita ser normalizado!
Después de eso, simplemente acepté NormalizeDouble() como un procedimiento obligatorio. La verdad es que todavía no entiendo bien cómo funciona el código a veces, por eso me interesa saber cómo se debe hacer.
¿Y qué enfoque sugieres en lugar de NormalizeDouble()?
 
Irtron:
komposter:
¿Alguna sugerencia (a nivel de usuario, no de desarrollador de MT)?
Por ejemplo, el precio. Ofertas, ahí, preguntas, paradas:
int ComparePrice(double a, double b)
{
    a -= b;
    b = Point / 2.;
    if (a > b)
        return (1);
    if (a < -b)
        return (-1);
    return (0);
}
A menudo es mejor hacer todos los cálculos de lotes y niveles en números enteros. Muchas veces más rápido y sin errores de muestreo en principio.
Estoy de acuerdo, en Omega todo estaba en INT. ¿Sugiere convertir todo en MT a INT primero, y luego calcular?
P.D. Y su ComparePrice es una solución muy interesante, ni siquiera lo entendí de inmediato.
ComparePriceComparePrice
 
Irtron:
Una vez más.

Precios, lotes, dinero - precisión fija.
Los indicadores son flotantes.

Esta diferencia es en esencia, aunque el doble se utiliza para representar a ambos. En realidad, determina lo que se llama "estilo de programación".
De nuevo, el criterio de "corrección" de cada uno es diferente. A mi entender, por ejemplo, NormalizeDouble() es una función ridículamente ineficiente y, en consecuencia, absolutamente innecesaria.

Primero, escriba varios Asesores Expertos en su propia orden y sienta el vendaval de sus clientes que el stop loss de repente resultó ser 1 punto erróneo... Y luego explícales lo absurdo de la función NormalizeDouble(), me pregunto cómo te funcionará=)
 
VBAG:
¡¡¡Y resulta que incluso el precio tomado del servidor de su pedido todavía necesita ser normalizado!!!
No es probable (c). Las tripas de la MT son casi imposibles de normalizar.
Hubo y hay un montón de conversaciones sobre el rendimiento incomprensible de la EA cuando se prueba en los datos históricos incomprensibles.
 
Irtron:
Por ejemplo, el precio. Ofertas, ahí, preguntas, paradas:
Eso ya es algo. Cada vez es más específico ;)
Si te dedicas a comparar precios, no necesitas una función tan sobrecargada como la mía.

Y en forma simplificada funciona tan rápido como ComparePrice:
int start()
{
    double a = 1.23450001, b = 1.23449999;
    int start1 = GetTickCount(), c1;
    for ( c1 = 0; c1 < 100000000; c1 ++ ) ComparePrice( a, b );
    int end1 = GetTickCount();
    
    int start2 = GetTickCount(), c2;
    for ( c2 = 0; c2 < 100000000; c2 ++ ) equal( a, b );
    int end2 = GetTickCount();
 
    Print( "ComparePrice: ", (end1-start1), ", equal: ", (end2-start2) );
 
    return(0);
}
 
int ComparePrice(double a, double b)
{
    a -= b;
    b = Point / 2.;
    if (a > b)
        return (1);
    if (a < -b)
        return (-1);
    return (0);
}
 
bool equal( double a, double b )
{
    return( MathAbs( a - b ) < Point );
}
2007.09.10 03:19:24 CheckCompareDoubleSpeed GBPUSD,Daily: ComparePrice: 20922, equal: 20453
 
Integer:

Primero, escriba algunos Asesores Expertos en su propia orden, sienta la tormenta de los clientes porque el stop-loss de repente resultó ser 1 pip equivocado... Y luego explícales lo absurdo de la función NormalizeDouble(), me pregunto cómo te funcionará=)

Déjame contarte un secreto.
He escrito muchos más Asesores Expertos personalizados de los necesarios para empezar. Nunca he sentido la necesidad de comprarlos porque nunca he dado ninguna razón para hacerlo. En mis programas, se garantiza que el stoploss está (y no "parece") donde debe estar. Por lo tanto, no tengo que explicar nada de eso al cliente, especialmente sobre alguna función muy específica. Me parece que el objetivo de escribir un EA es librarse de esas preguntas y explicaciones para el cliente.
123456789...11
Nuevo comentario