Аннотация:
Если яблоко поровну разделить на троих, каждому достанется треть. Так в нашу жизнь входят дроби, примерно с теми же целями входят они и в программирование.. Но реализация дробей в виде типов данных float/double ведёт себя не совсем "математично". В чём причина отличий, как минимизировать их влияние на результат вычислений, как же всё это всё-таки реализовано и почему запятая плавает — читайте в статье.
Делай что должно, и будь что будет
Re: Плавающая запятая
От:
Аноним
Дата:
16.03.08 14:52
Оценка:
Здравствуйте, Сергей Холодилов, Вы писали:
СХ>Статья: СХ>Плавающая запятая
СХ>Авторы: СХ> Сергей Холодилов
СХ>Аннотация: СХ>Если яблоко поровну разделить на троих, каждому достанется треть. Так в нашу жизнь входят дроби, примерно с теми же целями входят они и в программирование.. Но реализация дробей в виде типов данных float/double ведёт себя не совсем "математично". В чём причина отличий, как минимизировать их влияние на результат вычислений, как же всё это всё-таки реализовано и почему запятая плавает — читайте в статье.
Статья хреновая: Практически ничего нет. То что есть не несёт никакой полезной информации. И потом, почему статья не полная? Она будет дописана? Или останется в таком виде?
В любой книжке по численным методам, больше полезного можно узнать.
Здравствуйте, Аноним, Вы писали:
А>Статья хреновая: Практически ничего нет. То что есть не несёт никакой полезной информации. И потом, почему статья не полная? Она будет дописана? Или останется в таком виде?
Ты тут первый раз?
Тогда обрати внимание на самый низ страницы:
Полная версия этой статьи опубликована в журнале 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.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Сергей Холодилов, Вы писали:
СХ>Если яблоко поровну разделить на троих, каждому достанется треть. Так в нашу жизнь входят дроби, примерно с теми же целями входят они и в программирование..
Статья безусловно правильная, но несколько суховатая. Конечно, умный человек сделает из нее выводы, но все-таки надо учитывать реальность. А реальность такова, что умных людей очень мало. Например, надо было явно сказать, почему выражение fabs(a-b)<=DBL__EPSILON является полной лажей — а ведь им сразу начинают пользоваться ламеры, как только узнают, что нельзя сравнивать числа с плавающей точкой на равенство. Это, кстати, еще большее ламерство — постулат что нельзя сравнивать числа с плавающей точкой. На самом же деле, нельзя сравнивать на равенство числа, полученные разными способами. А плавающая точка тут вообще ни при чем — просто она как-бы провоцирует это ламерство. Вот на этом надо бы сделать акцент.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, 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.]
[Даю очевидные ответы на риторические вопросы]
На сайте полная версия будет месяцев через 5-6. 
