NormalizeDouble парадокс - страница 12

 
pavlick_:
Всё понятно, нам говорит не о чем. И лучше не лезьте в разговоры если за слова не отвечаете.

Ты идиот?

Модераторы забаньте меня на неделю,  чтобы быть подальше от идиотов.

 
Integer:

Ты идиот?

Модераторы забаньте меня на неделю,  чтобы быть подальше от идиотов.

Сливайся, пустослов.
 

о, господа, это шедеврально! давайте устроим дуэль из-за дробных чисел ))))))))))) 

 

наверное будет справедливо утверждать что хвосты существуют только в десятичном строковом представлении числа,

а в бинарном представлении хвостов нет в том смысле что там нет десятичных разрядов которые бы эти хвосты могли давать,

но в момент когда число "декомпрессируется в человеческий формат" хвосты появляются как символы десятичных разрядов из-за того что алгоритм не может самостоятельно принять решение значимые ли это разряды или нет,

поэтому ему нужно "помочь" и округлить

причем в большинстве случаев для человека было бы очевидно какое число нужно получить в итоге, стоит только взглянуть на "хвост"

поэтому я и возмущался что такая простая вещь не реализована на автомате ведь для подавляющего большинства трейдиновых задач нужная точность заведомо известна априорно и было бы удобно на уровне языка иметь готовое решение

.........................

в продолжение исходной темы...

сначала у меня возникло подозрение что решение DoubleToStr(current,2)  не всегда корректно

но подставляя в print разные "хвостатые" числа в обрамлении DoubleToStr я убедился что все примеры отработали нормально

заодно обнаружил что в MQL две одинаковые функции:  DoubleToStr и DoubleToString которые делают кажется одно и тоже, возможно одна из них реликт старой версии MQL до 600 версии оставленная для совместимости?

.............................

а еще я подумал что бинарный формат чисел наверное непригоден для задач требующих высокой точности

в трейдинге наверное таких задач нет, а в астрономии или физике наверное такие приколы с бинарными числами неприемлемы