NormalizeDouble парадокс - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
разрыв шаблона в том что даже после нормализации остаются хвосты!
после нормализации хвостов нет... Не вводите народ в заблуждения.
не ввожу .... но у меня есть
ситуация такая: нормализую число double, записываю в глобальную переменную терминала, потом читаю её, снова нормализую и получаю хвосты!
в итоге - нет сил вылавливать эти приколы - просто взял и принудительно обрезал с помощью DoubleToStr(current,2)
не ввожу .... но у меня есть
ситуация такая: нормализую число double, записываю в глобальную переменную терминала, потом читаю её, снова нормализую и получаю хвосты!
в итоге - нет сил вылавливать эти приколы - просто взял и принудительно обрезал с помощью DoubleToStr(current,2)
Если вы переменную double нормализовали например до 5 знаков то переменная и будет хранить 5 знаков, в случае рапринтовки и прочего вы переводите переменную в другой тип данных в следсвии чего может появляться хвост.
но в дабл после нормализации хвоста нет...
Что бы не получать косяков, в местах применения нужно делать нормализацию, по ходу вычислений можно не делать...
Если вы переменную double нормализовали например до 5 знаков то переменная и будет хранить 5 знаков, в случае рапринтовки и прочего вы переводите переменную в другой тип данных в следсвии чего может появляться хвост.
но в дабл после нормализации хвоста нет...
Что бы не получать косяков, в местах применения нужно делать нормализацию, по ходу вычислений можно не делать...
то это может давать хвосты именно в процессе этого преобразования?
не знал
спасибо!
то есть если я делаю например преобразование
то это может давать хвосты именно в процессе этого преобразования?
не знал
спасибо!
NormalizeDouble именно так и работает (и всегда так работал, начиная с самого первого MQL)
Число умножается на 10 в степени digits, переводится в целый вид (отбрасываем дробную часть), а потом делится на 10 в степени digits
Какие проблемы-то? Разрыв шаблона?
Разве отбрасывание дробной части? Округление выполняется.
NormalizeDouble(1.25,1) = 1.3
Разве отбрасывание дробной части? Округление выполняется.
NormalizeDouble(1.25,1) = 1.3
то есть если я делаю например преобразование
то это может давать хвосты именно в процессе этого преобразования?
не знал
спасибо!
Не совсем так. Двоичная систем != десятичная система. Значения двоичный разрядов после запятой: 0,5 / 0,25 / 0,125 / 0,0625 / 0,03125 и т.д. Из этих кирпичиков нельзя сложить все десятичный цифры. Например, невозможно точно представить десятичное число 0,3(можно сложить лишь приблизительное значение), в двоичной системе это будет либо немножко меньше, либо немножко больше. Так и появляется этот хвост.
Точно представляются только те числа, который делятся без остатка на 1/2^любая степень.
Другими словами, мы искажаем числа тогда, когда пытаемся представить десятичный цифры в двоичном виде.
Нам привычно, что не записать точно результат операции 1/3 придётся округлять. Но в троичной системе имеется точное представление операции == 0,1. Если бы родной нам была троичная, а пк работал с десятичной, то мы бы удивлялись мусору в разрядах при обратном переводе в троичную систему числа 0.1троич.
Такая аналогия:
Нам привычно, что не записать точно результат операции 1/3 придётся округлять. Но в троичной системе имеется точное представление операции == 0,1. Если бы родной нам была троичная, а пк работал с десятичной, то мы бы удивлялись мусору в разрядах при обратном переводе в троичную систему числа 0.1троич.
все это так
но почему то даже копеечный калькулятор умеет при чтении числа из памяти выдавать ровно то что туда записано
записал дробь 1,23 и получил обратно ровно 1,23 без всяких хвостов
а тут такие приколы
по идее пользователь должен быть избавлен от такой рутины как представление числа в бинарном формате
<занудство mode off>