Вопрос к мастерам MQL4. Опять про Double Compare. - страница 2

 
Еще раз.

Цены, лоты, деньги - фиксированная точность.
Индикаторы - плавающая.

Эта разница - по сути, хотя для представления и тех, и других используется double. Она, собственно, определяет то, что Вы называете "стилем программирования".
Опять же, критерий "правильности" у каждого свой. По моим понятиям, например, NormalizeDouble() - нелепейшая, неэффективная и, соответственно, абсолютно ненужная функция.
 
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 ) );
}
Код понятен, и Ваш пример очень показателен! А вот этот замут
nd( MathPow( 0.1, precision ), precision )
не лучше ли заменить на
//--- Если 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 );
}
Или так нельзя?
 
Irtron:
Проблема сравнения чисел с двойной точностью надумана и исходит от элементарного незнания матчасти.
Зато с завидным постоянством вылазит на форум.
Надо либо дать четкие указания по решению этой "проблемы", либо одно из двух =)

Irtron:
Зато будут проблемы с производительностью.
Какие будут предложения (на уровне пользователя, не на уровне разработчиков МТ)?
 
komposter:
Какие будут предложения (на уровне пользователя, не на уровне разработчиков МТ)?
Для цены, например. Биды, там, аски, стопы:
int ComparePrice(double a, double b)
{
    a -= b;
    b = Point / 2.;
    if (a > b)
        return (1);
    if (a < -b)
        return (-1);
    return (0);
}
Часто лучше вообще все вычисления лотов и уровней делать в целых числах. Во много раз быстрее и без ошибок дискретизации в принципе.
 
Irtron:
Еще раз.

Цены, лоты, деньги - фиксированная точность.
Индикаторы - плавающая.

Эта разница - по сути, хотя для представления и тех, и других используется double. Она, собственно, определяет то, что Вы называете "стилем программирования".
Опять же, критерий "правильности" у каждого свой. По моим понятиям, например, NormalizeDouble() - нелепейшая, неэффективная и, соответственно, абсолютно ненужная функция.
Недавно в какой-то из веток(точно не помню) человек сокрушался на непонятную работу советника. А оказалось, что даже цену взятую с сервера со своего ордера все-равно надо нормалайзить!!!
После этого, я просто принял для себя NormalizeDouble() как обязательную процедуру. Я действительно пока еще плохо понимаю как иногда работает код, поэтому и интересуюсь как надо.
А какой подход Вы предлогаете взамен NormalizeDouble()?
 
Irtron:
komposter:
Какие будут предложения (на уровне пользователя, не на уровне разработчиков МТ)?
Для цены, например. Биды, там, аски, стопы:
int ComparePrice(double a, double b)
{
    a -= b;
    b = Point / 2.;
    if (a > b)
        return (1);
    if (a < -b)
        return (-1);
    return (0);
}
Часто лучше вообще все вычисления лотов и уровней делать в целых числах. Во много раз быстрее и без ошибок дискретизации в принципе.
Согласен, в Омеге все в INT было. Вы предлагаете и в МТ переводить сначала все в INT, а потом вычислять?
P.S. А ComparePrice Ваш - очень интересное решение, сразу даже не дошло.
ComparePriceComparePrice
 
Irtron:
Еще раз.

Цены, лоты, деньги - фиксированная точность.
Индикаторы - плавающая.

Эта разница - по сути, хотя для представления и тех, и других используется double. Она, собственно, определяет то, что Вы называете "стилем программирования".
Опять же, критерий "правильности" у каждого свой. По моим понятиям, например, NormalizeDouble() - нелепейшая, неэффективная и, соответственно, абсолютно ненужная функция.

Для начала напишите несколько экспертов на заказ, прочувствуйте на себе бурю заказчика от того что вдруг стоплосс оказался на 1 пункт не там где на надо... И потом им объясняйте про нелепость функции NormalizeDouble(), интересно как это у вас получится=)
 
VBAG:
А оказалось, что даже цену взятую с сервера со своего ордера все-равно надо нормалайзить!!!
Это вряд ли (c). Потроха МТ занормалайзены уже почти дальше некуда.
Разговоров было и есть много про непонятную работу советника при тестировании на непонятно каких исторических данных.
 
Irtron:
Для цены, например. Биды, там, аски, стопы:
Это уже что-то. Конкретика появилась ;)
Если брать сравнение цен, такая перегруженная функция как у меня конечно не надо.

А в упрощенном виде она работает так же быстро как и 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:

Для начала напишите несколько экспертов на заказ, прочувствуйте на себе бурю заказчика от того что вдруг стоплосс оказался на 1 пункт не там где на надо... И потом им объясняйте про нелепость функции NormalizeDouble(), интересно как это у вас получится=)

Открою секрет.
Я написал намного больше экспертов на заказ, чем нужно для начала. Бурю заказчика не чувствовал никогда, потому что ни разу не давал повода. Стоплосс в моих программах гарантированно находится (а не "оказывается") там, где надо. Соответственно, и объяснять заказчику ничего такого не приходится, тем более про какую-то там весьма специфичную функцию. Мне как раз кажется, что смысл написания советника на заказ и заключается в избавлении заказчика от подобных вопросов и объяснений.
Причина обращения: