FórumSeções

Pergunta para os mestres da MQL4. Novamente sobre Double Compare. - página 2

Novo comentário
Mais uma vez.

Preços, lotes, dinheiro - precisão fixa.
Os indicadores são flutuantes.

Esta diferença é em essência, embora o dobro seja usado para representar ambos. Na verdade, ele determina o que você chama de "estilo de programação".
Mais uma vez, o critério de "exatidão" é diferente para todos. A meu ver, por exemplo, NormalizeDouble() é uma função ridiculamente ineficiente e, conseqüentemente, absolutamente desnecessária.
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 ) );
}
O código é claro, e seu exemplo é muito ilustrativo! E este aqui é um blip.
nd( MathPow( 0.1, precision ), precision )
não seria melhor substituí-lo 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 );
}
Ou é errado?
Irtron:
O problema de comparar números com dupla precisão é rebuscado e vem do desconhecimento básico da matemática.
Mas, com persistência invejável, ela aparece no fórum.
Ou dar instruções claras sobre como resolver este "problema", ou uma das duas =)

Irtron:
Mas haverá problemas de desempenho.
Alguma sugestão (nível de usuário, não nível de desenvolvedor MT)?
komposter:
Alguma sugestão (nível de usuário, não nível de desenvolvedor MT)?
Por preço, por exemplo. Licitações, lá, pede, pára:
int ComparePrice(double a, double b)
{
    a -= b;
    b = Point / 2.;
    if (a > b)
        return (1);
    if (a < -b)
        return (-1);
    return (0);
}
Muitas vezes é melhor fazer todos os cálculos de lote e nível em números inteiros. Muitas vezes mais rápido e sem erros de amostragem em princípio.
Irtron:
Mais uma vez.

Preços, lotes, dinheiro - precisão fixa.
Os indicadores são flutuantes.

Esta diferença é em essência, embora o dobro seja usado para representar ambos. Na verdade, ele determina o que você chama de "estilo de programação".
Mais uma vez, o critério de "exatidão" é diferente para todos. A meu ver, por exemplo, NormalizeDouble() é uma função ridiculamente ineficiente e, conseqüentemente, absolutamente desnecessária.
Recentemente, em algum tópico (não me lembro exatamente), uma pessoa estava reclamando sobre a estranha operação do Expert Advisor. E se verificou que mesmo o preço retirado do servidor para seu pedido ainda precisa ser normalizado!
Depois disso, eu simplesmente adotei NormalizeDouble() como um procedimento obrigatório. Eu realmente ainda não tenho um bom entendimento de como o código às vezes funciona, é por isso que estou interessado em como ele deve ser feito.
E que abordagem você sugere ao invés de NormalizeDouble()?
Irtron:
komposter:
Alguma sugestão (a nível de usuário, não a nível de desenvolvedor MT)?
Por preço, por exemplo. Licitações, lá, pede, pára:
int ComparePrice(double a, double b)
{
    a -= b;
    b = Point / 2.;
    if (a > b)
        return (1);
    if (a < -b)
        return (-1);
    return (0);
}
Muitas vezes é melhor fazer todos os cálculos de lote e nível em números inteiros. Muitas vezes mais rápido e sem erros de amostragem em princípio.
Concordo, em Omega tudo estava em INT. Você está sugerindo converter tudo em MT para INT primeiro, e depois calcular?
P.S. E seu ComparePrice é uma solução muito interessante, eu nem mesmo a recebi de imediato.
ComparePriceComparePrice
Irtron:
Mais uma vez.

Preços, lotes, dinheiro - precisão fixa.
Os indicadores são flutuantes.

Esta diferença é em essência, embora o dobro seja usado para representar ambos. Na verdade, ele determina o que você chama de "estilo de programação".
Mais uma vez, o critério de "exatidão" é diferente para todos. A meu ver, por exemplo, NormalizeDouble() é uma função ridiculamente ineficiente e, conseqüentemente, absolutamente desnecessária.

Primeiro, escreva vários Expert Advisors em seu próprio pedido e sinta a tempestade de seus clientes porque a parada de perda acabou de repente por ser 1 ponto errado... E então explicar-lhes sobre o absurdo da função NormalizeDouble(), eu me pergunto como funcionará para você=)
VBAG:
E acontece que mesmo o preço retirado do servidor de seu pedido ainda precisa ser normalizado!!!
Não é provável (c). As tripas da MT são quase impossíveis de normalizar.
Houve e há muitas conversas sobre o desempenho incompreensível da EA quando testado em dados históricos incompreensíveis.
Irtron:
Por preço, por exemplo. Licitações, lá, pede, pára:
Isso já é alguma coisa. Está ficando mais específico ;)
Se você comparar preços, você não precisa de uma função tão sobrecarregada como eu tenho.

E de forma simplificada, funciona tão rápido quanto o 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: ComparePreço: 20922, igual: 20453
Integer:

Primeiro, escreva alguns Expert Advisors em seu próprio pedido, sinta a tempestade dos clientes porque o stop-loss de repente acabou por ser 1 pip errado... E então explique sobre o absurdo da função NormalizeDouble(), eu me pergunto como isso funcionará para você=)

Deixe-me contar-lhe um segredo.
Escrevi muito mais Expert Advisors personalizados do que o necessário para começar. Nunca senti a necessidade de comprá-los porque nunca dei nenhuma razão para isso. Em meus programas, é garantido que a perda de estoque está (e não "aparece") onde deveria estar. Assim, não tenho que explicar nada do tipo para o cliente, especialmente sobre alguma função muito específica. Parece-me que o objetivo de escrever uma EA é se livrar de tais perguntas e explicações para o cliente.
123456789...11
Novo comentário