Val2 - correto. Val3 após conversão para longo - não correto. Aparentemente, é alguma peculiaridade da dupla representação dos números de ponto flutuante. Precisamos incrementar o EPSILON. Eu não consigo me virar de cabeça adormecida. Talvez algumas pessoas conhecedoras possam me dar uma dica.
Preciso descobrir que considerações os desenvolvedores usaram para escrever isto
//+------------------------------------------------------------------+//| Сравнивает два значения типа double. |//| RESULT |//| Возвращает истину, если значения равны и |//| ложь в противном случе. |//+------------------------------------------------------------------+bool CEnvironment::DoubleEquals(constdouble a,constdouble b)
{
//---return(fabs(a-b)<=16*DBL_EPSILON*fmax(fabs(a),fabs(b)));
//---
}
DBL_EPSILON define uma diferença de 1 (um!) bit significativo de um expoente quando aplicado ao número 1.0. Na prática, não há tal diferença - os números são estritamente iguais ou podem diferir em mais de um bit significativo. Portanto, é preciso tomar algo como 16*DBL_EPSILON para ignorar a diferença de 4 bits menos significativos (ou cerca de um dígito decimal e meio último significativo de cerca de 16 disponíveis).
Naturalmente, há casos em que a gama de números é mais ou menos conhecida e previsível. Digamos, 0...1000. Neste caso, você pode tomar uma constante como 1000*16*DBL_EPSILON para uma comparação aproximada. Mas devemos ter em mente que tal comparação realmente transforma toda a idéia do ponto flutuante em um ponto fixo (adivinhe por quê).
Acontece que a #import ex5 é o mal da otimização.
Em termos de ser capaz de otimizar globalmente, sim.
Temos um esquema bastante agressivo sem tentar fazer o código menor. Assim, no modo de otimização global, geramos um código muito bom.
Isto pode ser visto no tempo de compilação, onde colocamos a velocidade resultante no topo da lista.
fxsaber
Há um erro em seu código
Obrigado, corrigido.
Ainda é um erro.
Deve ser um 5 no final.
Ainda um erro
Isto não é um erro, é um arredondamento. É assim que a versão padrão o faz.
Aqui está o código para você testar
Aqui está o seu código, teste-o.
Val2 - correto. Val3 após conversão para longo - não correto. Aparentemente, é alguma peculiaridade da dupla representação dos números de ponto flutuante. Precisamos incrementar o EPSILON. Eu não consigo me virar de cabeça adormecida. Talvez algumas pessoas conhecedoras possam me dar uma dica.
Preciso descobrir que considerações os desenvolvedores usaram para escrever isto
Parece ser aqui que o cão está enterrado.
Parece ser aqui que o cão está enterrado.
As raízes crescem a partir do fórum RSDN
Naturalmente, há casos em que a gama de números é mais ou menos conhecida e previsível. Digamos, 0...1000. Neste caso, você pode tomar uma constante como 1000*16*DBL_EPSILON para uma comparação aproximada. Mas devemos ter em mente que tal comparação realmente transforma toda a idéia do ponto flutuante em um ponto fixo (adivinhe por quê).
Uma variante do CopyTicks, que às vezes é várias ordens de magnitude mais rápida do que a original (de > 0)