Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Цены, лоты, деньги - фиксированная точность.
Индикаторы - плавающая.
Эта разница - по сути, хотя для представления и тех, и других используется double. Она, собственно, определяет то, что Вы называете "стилем программирования".
Опять же, критерий "правильности" у каждого свой. По моим понятиям, например, NormalizeDouble() - нелепейшая, неэффективная и, соответственно, абсолютно ненужная функция.
не лучше ли заменить на
Или так нельзя?
Проблема сравнения чисел с двойной точностью надумана и исходит от элементарного незнания матчасти.
Надо либо дать четкие указания по решению этой "проблемы", либо одно из двух =)
Зато будут проблемы с производительностью.
Какие будут предложения (на уровне пользователя, не на уровне разработчиков МТ)?
Часто лучше вообще все вычисления лотов и уровней делать в целых числах. Во много раз быстрее и без ошибок дискретизации в принципе.
Еще раз.
Цены, лоты, деньги - фиксированная точность.
Индикаторы - плавающая.
Эта разница - по сути, хотя для представления и тех, и других используется double. Она, собственно, определяет то, что Вы называете "стилем программирования".
Опять же, критерий "правильности" у каждого свой. По моим понятиям, например, NormalizeDouble() - нелепейшая, неэффективная и, соответственно, абсолютно ненужная функция.
После этого, я просто принял для себя NormalizeDouble() как обязательную процедуру. Я действительно пока еще плохо понимаю как иногда работает код, поэтому и интересуюсь как надо.
А какой подход Вы предлогаете взамен NormalizeDouble()?
Какие будут предложения (на уровне пользователя, не на уровне разработчиков МТ)?
Часто лучше вообще все вычисления лотов и уровней делать в целых числах. Во много раз быстрее и без ошибок дискретизации в принципе.
P.S. А ComparePrice Ваш - очень интересное решение, сразу даже не дошло.
Еще раз.
Цены, лоты, деньги - фиксированная точность.
Индикаторы - плавающая.
Эта разница - по сути, хотя для представления и тех, и других используется double. Она, собственно, определяет то, что Вы называете "стилем программирования".
Опять же, критерий "правильности" у каждого свой. По моим понятиям, например, NormalizeDouble() - нелепейшая, неэффективная и, соответственно, абсолютно ненужная функция.
Для начала напишите несколько экспертов на заказ, прочувствуйте на себе бурю заказчика от того что вдруг стоплосс оказался на 1 пункт не там где на надо... И потом им объясняйте про нелепость функции NormalizeDouble(), интересно как это у вас получится=)
А оказалось, что даже цену взятую с сервера со своего ордера все-равно надо нормалайзить!!!
Разговоров было и есть много про непонятную работу советника при тестировании на непонятно каких исторических данных.
Для цены, например. Биды, там, аски, стопы:
Если брать сравнение цен, такая перегруженная функция как у меня конечно не надо.
А в упрощенном виде она работает так же быстро как и ComparePrice:
Для начала напишите несколько экспертов на заказ, прочувствуйте на себе бурю заказчика от того что вдруг стоплосс оказался на 1 пункт не там где на надо... И потом им объясняйте про нелепость функции NormalizeDouble(), интересно как это у вас получится=)
Открою секрет.
Я написал намного больше экспертов на заказ, чем нужно для начала. Бурю заказчика не чувствовал никогда, потому что ни разу не давал повода. Стоплосс в моих программах гарантированно находится (а не "оказывается") там, где надо. Соответственно, и объяснять заказчику ничего такого не приходится, тем более про какую-то там весьма специфичную функцию. Мне как раз кажется, что смысл написания советника на заказ и заключается в избавлении заказчика от подобных вопросов и объяснений.