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