Помогите разобраться с точностью

[Dmitriy40]

Ну, тут показан результат всех трёх режимов округления (вниз, вверх, к ближайшему) для четырёх вариантов двух отбрасываемых битов. Т.е. это таблица описания правил округления во всех трёх режимах. "-" в таблице означает усечение числа до ближайшего меньшего, "+" - увеличение числа до ближайшего большего, "-/+" - или первое или второе в зависимости от соглашения (обычно в зависимости от следующего слева бита - он должен стать нулевым).

[sashatgu]

Dmitriy40 в сообщении #1197497 писал(а):

Ну, тут показан результат всех трёх режимов округления (вниз, вверх, к ближайшему) для четырёх вариантов двух отбрасываемых битов. Т.е. это таблица описания правил округления во всех трёх режимах. "-" в таблице означает усечение числа до ближайшего меньшего, "+" - увеличение числа до ближайшего большего, "-/+" - или первое или второе в зависимости от соглашения (обычно в зависимости от следующего слева бита - он должен стать нулевым).

Объясните мне плиз это все поподробней - особенно интересует round half to even, я не понимаю откуда комп берет значения sticky bits и в каком количестве - ведь чтобы округлять он должен знать эти sticky bits (причем в каком то количестве). Я также приложил фото страницы на которой говорится о sticky bits.

Вот она:

[Dmitriy40]

Давайте для примера рассмотрим операцию умножения двух double чисел. В каждом из них есть 53 бита мантиссы, после перемножения можно получить 106 битов мантиссы, из них надо оставить снова лишь 53 бита, а остальные справа отбросить или округлить. Процессор конечно не будет считать все эти 106 битов, но он подсчитает 53+2 бита и в зависимости от режима округления и дополнительных двух битов выполнит округление произведения до 53 битов мантиссы, которые и запишет в результат умножения.
При сложении чисел часто тоже есть дополнительные биты - если складываются числа с экспонентами отличающимися на 2 и более, тогда одно из чисел сдвигается вправо и заполняет эти два дополнительных справа бита для последующего округления результата. Или результат сложения мантисс превышает 2 и потому для нормализации подлежит сдвигу вправо на бит - и выдвинутый бит и будет использован для округления. Если сдвигать ничего не надо (в том числе и результат сложения), то и округлять не надо т.к. количество битов мантиссы и не изменилось.

Округление "round half to even" в случае если отбрасываемые биты равны в точности половине младшего остающегося бита выполняет округление не к ближайшему числу (как положено по правилам математики), а к ближайшему чётному числу. Например при округлении до целых число 3,5 будет округлено до 4, но число 2,5 будет округлено до 2 вместо 3. В остальных случаях, если отбрасывается не ровно половина младшего остающегося бита, производится обычное округление к ближайшему представимому числу. Например 2,6 округлится до 3, а 2,4 к 2.

Текст на картинках объясняет всё это же, только более подробно и формально.

-- 05.03.2017, 22:40 --

PS. Может быть, если такие трудности с пониманием, поискать хорошую книжку на русском про представление чисел в двоичной системе счисления? Их полно должно быть, даже в сети информации навалом.

[sashatgu]

Dmitriy40 в сообщении #1197513 писал(а):

Округление "round half to even" в случае если отбрасываемые биты равны в точности половине младшего остающегося бита выполняет округление не к ближайшему числу (как положено по правилам математики), а к ближайшему чётному числу. Например при округлении до целых число 3,5 будет округлено до 4, но число 2,5 будет округлено до 2 вместо 3. В остальных случаях, если отбрасывается не ровно половина младшего остающегося бита, производится обычное округление к ближайшему представимому числу. Например 2,6 округлится до 3, а 2,4 к 2.

Имеется ввиду десятичное число?

[Dmitriy40]

sashatgu в сообщении #1197524 писал(а):

Имеется ввиду десятичное число?

Нет, конечно двоичное. Но для примера удобнее обычные десятичные числа. Впрочем, если настаиваете и не можете сами перенести пример на двоичную систему, вот:
Число $1{,}00011\_10_2$ будет округлено до $1{,}00100\_00_2$, но число $1{,}00010\_10_2$ будет округлено до $1{,}00010\_00_2$ вместо $1{,}00011\_00_2$. Но число $1{,}00010\_11_2$ округлится до $1{,}00011\_00_2$, а $1{,}00010\_01_2$ к $1{,}00010\_00_2$. Округление везде до 5-ти знаков после запятой методом "round half to even", цифры после знака "_" будут отброшены и в результат не попадут.

[sashatgu]

Dmitriy40 в сообщении #1197528 писал(а):

sashatgu в сообщении #1197524 писал(а):

Имеется ввиду десятичное число?

Нет, конечно двоичное. Но для примера удобнее обычные десятичные числа. Впрочем, если настаиваете и не можете сами перенести пример на двоичную систему, вот:
Число $1{,}00011\_10_2$ будет округлено до $1{,}00100\_00_2$, но число $1{,}00010\_10_2$ будет округлено до $1{,}00010\_00_2$ вместо $1{,}00011\_00_2$. Но число $1{,}00010\_11_2$ округлится до $1{,}00011\_00_2$, а $1{,}00010\_01_2$ к $1{,}00010\_00_2$. Округление везде до 5-ти знаков после запятой методом "round half to even", цифры после знака "_" будут отброшены и в результат не попадут.

Но ведь округление происходит не только при сложении-умножении, но и как я понимаю, при конвертации десятичного в двоичное (а эта конвертация происходит всегда так как комп работает тока с двоичными, я прав?) и наоборот двоичного в десятичное (это тоже происходит всегда - так как пользователю нужно видеть конечный результат в десятичном после всех сложений-умножений в двоичном, я прав?).

Так вот все таки объясните мне плиз хотя бы алгоритмически каким образом десятичное 7.5708 превращается в

0 10000000001 1110010010000111111111001011100100100011101000101010

То есть каким образом десятичное 7.5708 превращается в некое двоичное, а затем это двоичное после округления превращается в

0 10000000001 1110010010000111111111001011100100100011101000101010

Или во что там превращается десятичное, чтоб компьютер мог оперировать этим двоичным.

Ну или приведите любой другой пример на ваше усмотрение.

[Dmitriy40]

Введите тут своё желаемое число и проследите как происходит перевод в двоичную форму: http://floatingpoint.ru/online/dec2double.php
Или вот пример с числом $1{,}33_{10}$ с 5-ю знаками после запятой: мантисса будет равна $1{,}01010\_1000111101011100_2$, надо округлить по месту знака "_", смотрим справа от него, там биты $10_2$, по методу "round half to even" надо округлить биты слева от знака "_" до ближайшего чётного числа, т.е. до $1{,}01010_2$.
Как из $1{,}33_{10}$ получить $1{,}010101000111101011100_2$ - было сказано даже в этой теме выше:

slavav в сообщении #1196342 писал(а):

Найдите набольшую степень двойки, которая не превосходит ваше число. Запишите её. Вычтите её из числа. Продолжайте пока число не станет нулём или пока у вас будет хватать терпения. Те числа что вы выписали - биты двоичного представления числа.

Разумеется можно было остановиться как только получили два лишних знака.

Как к мантиссе добавить правильную экспоненту - написано или по ссылке выше, или вообще везде.

-- 06.03.2017, 01:47 --

Вообще я никак не пойму с чем у Вас затык: с округлением в двоичных числах; с переводом из десятичной системы в двоичную; с тем как это делает конкретно Java; с форматом чисел double; с правилами проведения операций с вещественными числами в процессоре; сколько надо вычислять "лишних" битов для получения исходной точности для формата doubele; или с чем-то ещё менее очевидным?

[Munin]

sashatgu в сообщении #1197537 писал(а):

Так вот все таки объясните мне плиз хотя бы алгоритмически каким образом десятичное 7.5708 превращается в

0 10000000001 1110010010000111111111001011100100100011101000101010

То есть каким образом десятичное 7.5708 превращается в некое двоичное, а затем это двоичное после округления превращается в

0 10000000001 1110010010000111111111001011100100100011101000101010

Или во что там превращается десятичное, чтоб компьютер мог оперировать этим двоичным.

Ну или приведите любой другой пример на ваше усмотрение.

Мы в своё время с такими вещами сами с увлечением разбирались по справочникам.

Возьмём десятичное 7,5708.

Целая часть $7_{10}=111_2.$

Как это получить? Делим 7 на 2: $7\mathbin{\mathrm{div}}2=3,\quad 7\bmod 2=1.$ Полученный остаток 1 записываем как последнюю цифру в результате.

Повторяем:
$3\mathbin{\mathrm{div}}2=1,\quad 3\bmod 2=1.$
$1\mathbin{\mathrm{div}}2=0,\quad 1\bmod 2=1.$
Итого, собирая все цифры вместе (повторяю, сзади наперёд, справа налево), получаем 111.

Дробная часть. 0,5708=?

Поступаем аналогично, но в другую сторону. Умножаем 0,5708 на 2 много раз, и записываем в цифры результата - то, что вылезает в целую часть.
$0{,}5708\cdot 2=1{,}1416$
$0{,}1416\cdot 2=0{,}2832$
$0{,}2832\cdot 2=0{,}5664$
$0{,}5664\cdot 2=1{,}1328$
$0{,}1328\cdot 2=0{,}2656$
ну и так далее. Целиком выписывать не буду. Для примера мне хватит.
Собирая все цифры вместе (вот тут - слева направо), получаем $0{,}10010\ldots_2.$

Важно!

Поскольку в двоичной системе основание 2, а в десятичной - основание $10=2\cdot 5,$ то процесс может стать бесконечным. Чаще всего, и будет. Но он пойдёт по кругу - получится бесконечная периодическая двоичная дробь. Это с математической точки зрения, а на практике достаточно получить сколько-то двоичных цифр, а остальные всё равно компьютер проигнорирует.

Дальше.

Мы получили пока, что наше число $7{,}5708_{10}=111{,}10010\ldots_2.$ Теперь его надо сделать из числа с фиксированной запятой (fixed point) числом с плавающей запятой (floating point), и нормализовать его. Нормализация - это сдвиг запятой до тех пор, пока целая часть не станет какой-то, например, одной цифрой:

$111{,}10010\ldots\xrightarrow{\text{на 2 цифры}} 1{,}1110010\ldots$
Количество сдвинутых цифр становится порядком числа:

$111{,}10010\ldots=1{,}1110010\ldots\cdot 2^2$
Чтобы завершить формирование мантиссы, мы заметим, что у нас число двоичное, и значит, первая ненулевая цифра всегда 1, а значит, её можно не хранить:

$1{,}1110010\ldots\to [1]{,}1110010\ldots$
Вот мы и получили мантиссу 1110010...

Остался порядок. Это $2_{10}=10_2.$

Нам надо его сдвинуть, то есть, в случае double precision (binary64) - прибавить $1023_{10}=111\,111\,111_2.$ Поскольку 1023=1024-1, то легко получаем

$111\,111\,111+10=1\,000\,000\,001.$
Это и пишем в порядок.

И наконец, знак. Наше число положительное, это обозначается битом 0.