Аннотация:
Если яблоко поровну разделить на троих, каждому достанется треть. Так в нашу жизнь входят дроби, примерно с теми же целями входят они и в программирование.. Но реализация дробей в виде типов данных float/double ведёт себя не совсем "математично". В чём причина отличий, как минимизировать их влияние на результат вычислений, как же всё это всё-таки реализовано и почему запятая плавает — читайте в статье.
Здравствуйте, Сергей Холодилов, Вы писали:
СХ>Если яблоко поровну разделить на троих, каждому достанется треть. Так в нашу жизнь входят дроби, примерно с теми же целями входят они и в программирование..
Статья безусловно правильная, но несколько суховатая. Конечно, умный человек сделает из нее выводы, но все-таки надо учитывать реальность. А реальность такова, что умных людей очень мало. Например, надо было явно сказать, почему выражение fabs(a-b)<=DBL__EPSILON является полной лажей — а ведь им сразу начинают пользоваться ламеры, как только узнают, что нельзя сравнивать числа с плавающей точкой на равенство. Это, кстати, еще большее ламерство — постулат что нельзя сравнивать числа с плавающей точкой. На самом же деле, нельзя сравнивать на равенство числа, полученные разными способами. А плавающая точка тут вообще ни при чем — просто она как-бы провоцирует это ламерство. Вот на этом надо бы сделать акцент.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re: Плавающая запятая
От:
Аноним
Дата:
16.03.08 14:52
Оценка:
Здравствуйте, Сергей Холодилов, Вы писали:
СХ>Статья: СХ>Плавающая запятая
СХ>Авторы: СХ> Сергей Холодилов
СХ>Аннотация: СХ>Если яблоко поровну разделить на троих, каждому достанется треть. Так в нашу жизнь входят дроби, примерно с теми же целями входят они и в программирование.. Но реализация дробей в виде типов данных float/double ведёт себя не совсем "математично". В чём причина отличий, как минимизировать их влияние на результат вычислений, как же всё это всё-таки реализовано и почему запятая плавает — читайте в статье.
Статья хреновая: Практически ничего нет. То что есть не несёт никакой полезной информации. И потом, почему статья не полная? Она будет дописана? Или останется в таком виде?
В любой книжке по численным методам, больше полезного можно узнать.
Здравствуйте, SergH, Вы писали:
MS>>Например, надо было явно сказать, почему выражение fabs(a-b)<=DBL__EPSILON является полной лажей — а ведь им сразу начинают пользоваться ламеры, как только узнают, что нельзя сравнивать числа с плавающей точкой на равенство. SH>Объясни, почему это неправильно? Потому что помогает только 99% случаев, а не в 100%? Ну, что делать. Я рассчитываю, что, благодаря огромному диапазону double вычисления происходят всё-таки не на его краях.
Есть сразу две причины.
Ламерство #1: честное сравнение должно учитывать не абсолютную, а относительную ошибку. Если ты какую-то выкладку умножишь на 2**-8, то её точность не изменится (просто все порядки уменьшятся и всё), а вот твоя формула для сравнений окажется неверной.
Ламерство #2: Обычно при применений вычислений на практике есть какая-то заранее известная точность, с которой они ведутся. Так что соравнивать логичнее с этим пределом точности, а не с всякими константами, зависящими от аппаратуры...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, SergH, Вы писали:
SH>Почуствовал себя ламером Я именно так делаю. И даже в статье написал SH>Объясни, почему это неправильно? Потому что помогает только 99% случаев, а не в 100%? Ну, что делать. Я рассчитываю, что, благодаря огромному диапазону double вычисления происходят всё-таки не на его краях.
Здравствуйте, SergH, Вы писали:
SH>А что такое по твоему DBL__EPSILON? Если это граница точности double, т.е. единица младшего разряда при минимальном порядке, то, конечно, это лажа. Просто потому что ошибка будет больше. Если нет, то почему это "константа, зависящая от аппаратуры"?
SH>Я считал, что это какое-то разумное значение, выбранное программистом, который примерно представляет, с какого масштаба числами он работает. И какой точности ему при этом хватит.
1) ID с двумя _ подряд в C/C++ AFAIK зарезервированы и не могут использоваться в прикладном коде.
2) DBL_EPSILON определена там же и обозначает самое маленькое положительное число, которое ещё можно добавить к 1.0 и получить отличный от 1.0 результат.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Vain, Вы писали:
V>Всё-таки, ты игнорируешь то что надо рассказать про типы кодировок.
Игнорировать это замалчивать и не отвечать, тогда в обсуждении хвосты повисают. А я не игнорирую, я честно и открыто отказываюсь. Конечно писать про кодировки в этой статье _не_ надо. Они тут не используются.
V>Уж какие есть.
Здравствуйте, Аноним, Вы писали:
А>Статья хреновая: Практически ничего нет. То что есть не несёт никакой полезной информации. И потом, почему статья не полная? Она будет дописана? Или останется в таком виде?
Ты тут первый раз?
Тогда обрати внимание на самый низ страницы:
Полная версия этой статьи опубликована в журнале RSDN Magazine #4-2007.
Оскал капитализма, нужно как-то журнал продавать На сайте полная версия будет месяцев через 5-6.
Поскольку не ты первый на это попадаешь, имхо, надпись следовало бы разместить на более видном месте. Выдвину соответствующее предложение.
Делай что должно, и будь что будет
Re[3]: Плавающая запятая
От:
Аноним
Дата:
17.03.08 14:57
Оценка:
Здравствуйте, SergH, Вы писали:
... SH>Тогда обрати внимание на самый низ страницы: SH>
Полная версия этой статьи опубликована в журнале RSDN Magazine #4-2007.
SH>Оскал капитализма, нужно как-то журнал продавать На сайте полная версия будет месяцев через 5-6.
Здравствуйте, Аноним, Вы писали:
А>Щас вроде уже 2008 год
Угу. А журнал только вышел.. Ну да, вот такая беда у нас со сроками выхода. Основная проблема — статей мало, а хороших — совсем мало, и иногда даже печатается то, что, по хорошему не должно бы — иначе просто нечего... Допустим, не в этом случае Но в целом..
Число с плавающей запятой называется нормализованным, если выполняется условие: 1 <= |M| < q
Не хочу показать своё невежество, но я полагал, что диапазон всё-таки зависит от основания:
q^n <= |M| < q^(n+1)
,где ^ — возведение в степень.
т.е. такие диапазоны: [1:2), [2:4), [4:8) при основании "2", ну и т.д.
И потом, в IEEE 754 мантисса в нормализованном виде, насколько я помню, лежит в диапазоне [2:4), чего я не обнаружил в тексте.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
V>Число с плавающей запятой называется нормализованным, если выполняется условие: 1 <= |M| < q
V>Не хочу показать своё невежество, но я полагал, что диапазон всё-таки зависит от основания: V>
V>q^n <= |M| < q^(n+1)
V>
V>,где ^ — возведение в степень.
Ну, во-первых, 1 <= |M| < q это 1^0 <= |M| < q^(0+1), так что мой вариант это частный случай твоего. Во-вторых — что такое для тебя n? Оно фиксировано? Для меня это всегда 0 и я не вижу причин усложнять определение, вводя дополнительный параметр.
V>т.е. такие диапазоны: [1:2), [2:4), [4:8) при основании "2", ну и т.д.
а так же [1/2 ,1), [1/4, 1/2), ага
Но ведь надо выбрать один какой-то диапазон. Т.е. нужно в определении формата зафиксировать значение n. У всех известных мне форматов это 0.. Так что опять не вижу смысла усложнять определение.
V>И потом, в IEEE 754 мантисса в нормализованном виде, насколько я помню, лежит в диапазоне [2:4), чего я не обнаружил в тексте.
Насколько известно мне, всё-таки [1, 2). Судя по тому, что мои примеры с искуственным конструированием float из битов работают, я прав. Какие-нибудь ссылки/аргументы в пользу твоего мнения?
Здравствуйте, Vain, Вы писали:
V>И потом, в IEEE 754 мантисса в нормализованном виде, насколько я помню, лежит в диапазоне [2:4), чего я не обнаружил в тексте.
significand. The component of a binary floating-point number that consists of an explicit or implicit leading bit to the left of its implied binary point and a fraction field to the right.
Здравствуйте, SergH, Вы писали:
SH> У всех известных мне форматов это 0..
А вот тут я наврал. Для IBM System/360 нормализованная мантисса от 1/16 до 1.
Но всё равно, это всего лишь масштабный коэффициент, усложнять определение не хочу. Не математика, чай Мне не нужно настолько общее определение, чтобы под него попали все возможные частные случаи. Мне нужно чтобы оно было простым, понятным, и покрывало 95% частных случаев. С учётом того, что случай, когда определение лажает довольно экзотичен и даже описан в статье, я считаю, что сделал всё, что нужно было, чтобы не ввести читателей в заблуждение
Здравствуйте, SergH, Вы писали:
SH>> У всех известных мне форматов это 0.. SH>А вот тут я наврал. Для IBM System/360 нормализованная мантисса от 1/16 до 1.
Т.е. основание там 16? SH>Но всё равно, это всего лишь масштабный коэффициент, усложнять определение не хочу.
Как раз наоборот, это важная деталь для понимания. Основание имеет здесь значение, т.к. иначе число может быть неоднозначно представимо, что фактически является денормализацией.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Ага, с примером разобрались.
SH>>А вот тут я наврал. Для IBM System/360 нормализованная мантисса от 1/16 до 1. V>Т.е. основание там 16?
Почитай статью, да?
Да, основание там 16.
SH>>Но всё равно, это всего лишь масштабный коэффициент, усложнять определение не хочу. V>Как раз наоборот, это важная деталь для понимания. Основание имеет здесь значение, т.к. иначе число может быть неоднозначно представимо, что фактически является денормализацией.
Брр. Основание — да. А вот твоё n — нет. Если ты посмотришь, то увидишь, что основание q у меня в определении с самого начала было. Если совсем точно, то у меня так:
Число с плавающей запятой называется нормализованным, если выполняется условие:
1 <= |M| < q
Если q – основание системы счисления, в которой записано M (т.е. в 99% случаев), условие сводится к тому, что в мантиссе запятая стоит после первого значащего разряда.
Согласен, что более безопасно было бы написать:
Если q не только основание числа с плавающей запятой, но ещё и основание системы счисления, в которой записано M (т.е. в 99% случаев), условие сводится к тому, что в мантиссе запятая стоит после первого значащего разряда.
Тем самым подчеркнув, что определение даётся в контексте введённых с самого начала статьи обозначений, в которых q — не что-то с потолка, а именно основание.
Здравствуйте, Vain, Вы писали:
V>Как раз наоборот, это важная деталь для понимания. Основание имеет здесь значение, т.к. иначе число может быть неоднозначно представимо, что фактически является денормализацией.
Но в общем-то ты прав.
У меня всё это написано, но недостаточно явно.
Т.е. о том, для чего производится нормализация просто не сказано. Спасибо за замечание, на днях исправлю.
Здравствуйте, SergH, Вы писали:
V>>И потом, в IEEE 754 мантисса в нормализованном виде, насколько я помню, лежит в диапазоне [2:4), чего я не обнаружил в тексте. SH>http://www.validlab.com/754R/standards/754.pdf SH>
significand. The component of a binary floating-point number that consists of an explicit or implicit leading bit to the left of its implied binary point and a fraction field to the right.
SH>Т.е. нормализованное значение всё-таки [1, 2)
Где-то это я всё-таки видел...
В статье ничего не сказано про прямой/обратный/дополнительный код, что несколько настораживает.
Если взглянуть на страницу 7 указанного вами документа, то вообще не ясно, почему E (single) лежит в диапазоне [-126:127]. Учитывая то что, Emin-1 и Emax+1 зарезервированы, соответственно, для +-0 и NaN, то всё-равно не понятно, почему [-127:128], ведь доп.код смещён влево, а не вправо — [-128:127], в статье про это я не нашёл что-то.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>В статье ничего не сказано про прямой/обратный/дополнительный код, что несколько настораживает.
В десятичной части статьи это ни к чему, там рассматриваются более высокоуровневые вопросы. Когда речь заходит о двоичной системе счисления, явно сказано, что все компоненты — мантисса и порядок — положительные. Так что никаких особых кодов не нужно, всё в прямом.
V>Если взглянуть на страницу 7 указанного вами документа, то вообще не ясно, почему E (single) лежит в диапазоне [-126:127]. Учитывая то что, Emin-1 и Emax+1 зарезервированы, соответственно, для +-0 и NaN, то всё-равно не понятно, почему [-127:128], ведь доп.код смещён влево, а не вправо — [-128:127], в статье про это я не нашёл что-то.
Страница 7 — это про табличку? Ну так там же следующей строчкой после Emin идёт Exponent Bias, который всё объясняет.. Как он применяется написано на той же странице 7, в разделе Basic Formats:
Numbers in the single and double formats are composed of the following
three fields:
1. 1-bit sign s
2. Biased exponent e = E + bias
...
Здравствуйте, SergH, Вы писали:
V>>В статье ничего не сказано про прямой/обратный/дополнительный код, что несколько настораживает. SH>В десятичной части статьи это ни к чему, там рассматриваются более высокоуровневые вопросы. Когда речь заходит о двоичной системе счисления, явно сказано, что все компоненты — мантисса и порядок — положительные. Так что никаких особых кодов не нужно, всё в прямом.
Не всё, диапазон прямого кода симметричен, а дополнительного — нет.
SH>Страница 7 — это про табличку? Ну так там же следующей строчкой после Emin идёт Exponent Bias, который всё объясняет.. Как он применяется написано на той же странице 7, в разделе Basic Formats:
Не ясно, почему диапазон дополнительного кода "перекошён" вправо, а не влево.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, McSeem2, Вы писали:
MS>Статья безусловно правильная, но несколько суховатая. Конечно, умный человек сделает из нее выводы, но все-таки надо учитывать реальность. А реальность такова, что умных людей очень мало. Например, надо было явно сказать, почему выражение fabs(a-b)<=DBL__EPSILON является полной лажей — а ведь им сразу начинают пользоваться ламеры, как только узнают, что нельзя сравнивать числа с плавающей точкой на равенство.
Почуствовал себя ламером Я именно так делаю. И даже в статье написал
Объясни, почему это неправильно? Потому что помогает только 99% случаев, а не в 100%? Ну, что делать. Я рассчитываю, что, благодаря огромному диапазону double вычисления происходят всё-таки не на его краях.
MS>Это, кстати, еще большее ламерство — постулат что нельзя сравнивать числа с плавающей точкой. На самом же деле, нельзя сравнивать на равенство числа, полученные разными способами. А плавающая точка тут вообще ни при чем — просто она как-бы провоцирует это ламерство. Вот на этом надо бы сделать акцент.
Плавающая точка тут очень причём. Для целых чисел операции сложения, вычитания, умножения — ассоциативны и математичны. Для статической точки правильно работает сложение и вычитание. Для плавающей точки — ничего правильно не работает, порядок любых операций важен. Это я, кстати, написал.
Во-первых, давай ты будешь признавать свои ошибки. Иначе возникает ощущение, что тебе хочется не разобраться, а меня уязвить. И то, где ты был неправ, ты воспринимаешь не как новое знание, а как досадную оплошность — не удалось уколоть, попробую другой подход. Мне неприятно общаться в таком режиме. А поскольку в саппорт я не нанимался и денег мне за это не платят, ещё пара комментов в том же духе и продолжай разговор один. Ага?
V>Не всё, диапазон прямого кода симметричен, а дополнительного — нет.
Ещё раз. Все компоненты — положительные числа. Мантисса всегда больше нуля. Экспонента всегда больше нуля (из-за смещение). Знак — 0 или 1. Какие тут варианты кодирования? Положительные числа в прямом/обратном/дополнительном кодируются одинаково.
V>Не ясно, почему диапазон дополнительного кода "перекошён" вправо, а не влево.
Не ясно, причём тут дополнительный код и кто перекошен.
Здравствуйте, SergH, Вы писали:
SH>Во-первых, давай ты будешь признавать свои ошибки.
Про какие ошибки ты говоришь? SH>Иначе возникает ощущение, что тебе хочется не разобраться, а меня уязвить. И то, где ты был неправ, ты воспринимаешь не как новое знание, а как досадную оплошность — не удалось уколоть, попробую другой подход. Мне неприятно общаться в таком режиме. А поскольку в саппорт я не нанимался и денег мне за это не платят, ещё пара комментов в том же духе и продолжай разговор один. Ага?
Детский сад, ага. V>>Не всё, диапазон прямого кода симметричен, а дополнительного — нет. SH>Ещё раз. Все компоненты — положительные числа. Мантисса всегда больше нуля. Экспонента всегда больше нуля (из-за смещение). Знак — 0 или 1. Какие тут варианты кодирования? Положительные числа в прямом/обратном/дополнительном кодируются одинаково.
Во первых, плавающие числа связаны с целыми, которые кодируются в доп коде, к примеру представление нуля, или расположение бита знака или мантиссы.
Во вторых, есть такой предмет, "Проектирование ЭВМ" в котором сначало объясняется типы кодирования, а потом формат плавающей запятой, что не просто так, что и вам желаю. V>>Не ясно, почему диапазон дополнительного кода "перекошён" вправо, а не влево. SH>Не ясно, причём тут дополнительный код и кто перекошен.
Вот и написали бы про это.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>Про какие ошибки ты говоришь?
И диапазон мантиссы у IEEE 754 от 2 до 4-х.
И основание у меня в определении нормализации не упомянуто.
И мантисса видимо в доп коде, да? Или в обратном? Или не мантисса, а экспонента? На эту тему я никаких утверждений не дождался, только сомнения и намёки.
Здравствуйте, SergH, Вы писали:
V>>Про какие ошибки ты говоришь? SH>И диапазон мантиссы у IEEE 754 от 2 до 4-х.
Я написал, что "насколько я помню", а не сказал что так и есть. Это я не с потолка взял, а видел в одном документе, связанном с форматом плавающих чисел. SH>И основание у меня в определении нормализации не упомянуто. SH>И мантисса видимо в доп коде, да? Или в обратном? Или не мантисса, а экспонента? На эту тему я никаких утверждений не дождался, только сомнения и намёки.
Диапазон порядка нессиметричен, что является признаком доп. кода. SH>Но не суть. До новых встреч.
Написав статью, как я понимаю, ты взял на себя обязательство сделать её лучше, но на мои предложения ты непонятно почему сопротивляешься и отвечаешь в том же духе в котором сам не хочешь чтоб с тобой говорили, угу, очень красиво.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Erop, Вы писали:
E>Есть сразу две причины. E>Ламерство #1: честное сравнение должно учитывать не абсолютную, а относительную ошибку. Если ты какую-то выкладку умножишь на 2**-8, то её точность не изменится (просто все порядки уменьшятся и всё), а вот твоя формула для сравнений окажется неверной.
E>Ламерство #2: Обычно при применений вычислений на практике есть какая-то заранее известная точность, с которой они ведутся. Так что соравнивать логичнее с этим пределом точности, а не с всякими константами, зависящими от аппаратуры...
А что такое по твоему DBL__EPSILON? Если это граница точности double, т.е. единица младшего разряда при минимальном порядке, то, конечно, это лажа. Просто потому что ошибка будет больше. Если нет, то почему это "константа, зависящая от аппаратуры"?
Я считал, что это какое-то разумное значение, выбранное программистом, который примерно представляет, с какого масштаба числами он работает. И какой точности ему при этом хватит.
Ок, продолжим про этику ведения дискуссий. Потом попросим ветку отделить и снести в мусорку.
V>Я написал, что "насколько я помню", а не сказал что так и есть. Это я не с потолка взял, а видел в одном документе, связанном с форматом плавающих чисел.
Во-первых, тот документ тебе наврал. Во-вторых, проверить это довольно просто. У тебя у самого получилось, правда, не с первой попытки. В-третьих, ты написал так:
И потом, в IEEE 754 мантисса в нормализованном виде, насколько я помню, лежит в диапазоне [2:4), чего я не обнаружил в тексте.
В тексте сказано, что она лежит в диапазоне [1, 2). То что ты этого не заметил, означает, что ты его невнимательно читал. Но критикуешь.
SH>>И основание у меня в определении нормализации не упомянуто.
Это осталось.
SH>>И мантисса видимо в доп коде, да? Или в обратном? Или не мантисса, а экспонента? На эту тему я никаких утверждений не дождался, только сомнения и намёки. V>Диапазон порядка нессиметричен, что является признаком доп. кода.
Если прочитаешь всё-таки статью, то найдешь там формат, у которого смещение -2. Это "признак" какого кода?
Я же уже давал ссылку на описание в стандарте:
Numbers in the single and double formats are composed of the following three fields:
1. 1-bit sign s
2. Biased exponent e = E + bias
...
Ага? Хранится всегда положительное значение. От 0 до 2^n — 1. Для вычисления реального из него нужно вычесть смещение. Если, например, смещение равно -2, надо прибавить 2. Если, как у float, смещение равно 127, надо вычесть 127.
Всё, как у меня:
Показатель степени – целое число, он может быть как положительным, так и отрицательным. Видимо, для того, чтобы не возиться с отрицательными числами, обычно он хранится в виде беззнакового целого со смещением. А для того чтобы получить реальное значение показателя степени, нужно вычесть из записанного значения некоторую константу.
V>Написав статью, как я понимаю, ты взял на себя обязательство сделать её лучше,
Чего не брал, того не брал. Тем более не брал обязательств рассматривать все предложения всех читателей. Рассматриваю только корректно сформулированные, и никаких обязательств не даю.
V>но на мои предложения ты непонятно почему сопротивляешься и отвечаешь в том же духе в котором сам не хочешь чтоб с тобой говорили, угу, очень красиво.
Такие уж у тебя предложения. Неконкретны, непродуманы, в большинстве вызваны недопониманием и невнимательным чтением. На мои просьбы продумать, понять и прочитать внимательно ты выдвигаешь новые предложения — такие же.
Здравствуйте, Erop, Вы писали:
E>1) ID с двумя _ подряд в C/C++ AFAIK зарезервированы и не могут использоваться в прикладном коде.
ммм.. Я думал, что только начинающиеся с __. И что в середине можно что угодно.. Но возможно я не прав, стандарт не читал.
E>2) DBL_EPSILON определена там же и обозначает самое маленькое положительное число, которое ещё можно добавить к 1.0 и получить отличный от 1.0 результат.
Спасибо, буду знать.
А насчёт:
Я считал, что это какое-то разумное значение, выбранное программистом, который примерно представляет, с какого масштаба числами он работает. И какой точности ему при этом хватит.
?
При таком подходе ламерство тоже где-то прячется или вопрос именно в выборе адекватного ситуации значение эпсилона?
Здравствуйте, SergH, Вы писали:
SH>При таком подходе ламерство тоже где-то прячется или вопрос именно в выборе адекватного ситуации значение эпсилона?
Вообще-то от задачи сильно всё зависит. Но обычно, если это какие-то расчёты, например вычматы, то смысл имеет именно относительная ошибка, а не абсолютная.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, SergH, Вы писали:
SH>Во-первых, тот документ тебе наврал.
Может быть, я не помню точно, про x86 или про другой формат. SH>Во-вторых, проверить это довольно просто. У тебя у самого получилось, правда, не с первой попытки. В-третьих, ты написал так: SH>
И потом, в IEEE 754 мантисса в нормализованном виде, насколько я помню, лежит в диапазоне [2:4), чего я не обнаружил в тексте.
SH>В тексте сказано, что она лежит в диапазоне [1, 2). То что ты этого не заметил, означает, что ты его невнимательно читал. Но критикуешь.
Здесь я ничего не критиковал. SH>>>И мантисса видимо в доп коде, да? Или в обратном? Или не мантисса, а экспонента? На эту тему я никаких утверждений не дождался, только сомнения и намёки. V>>Диапазон порядка нессиметричен, что является признаком доп. кода. SH>Если прочитаешь всё-таки статью, то найдешь там формат, у которого смещение -2. Это "признак" какого кода?
Всё-таки, ты игнорируешь то что надо рассказать про типы кодировок. V>>Написав статью, как я понимаю, ты взял на себя обязательство сделать её лучше, SH>Чего не брал, того не брал. Тем более не брал обязательств рассматривать все предложения всех читателей. Рассматриваю только корректно сформулированные, и никаких обязательств не даю.
Ну ладно, раз ты не даёшь, то и мы не будем. V>>но на мои предложения ты непонятно почему сопротивляешься и отвечаешь в том же духе в котором сам не хочешь чтоб с тобой говорили, угу, очень красиво. SH>Такие уж у тебя предложения.
Уж какие есть.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Наконец-то написан и выложен апдейт, который я обещал три месяца назад
Изменений немного, фактически только добавился раздел "Сравнение". Хотелось больше, но не получилось ничего внятного, поэтому и тормозил так долго.
Я именно так делаю. И даже в статье написал 
На сайте полная версия будет месяцев через 5-6. 
