Каков принцип округления дробных чисел у компьютера/компилятора?

Всем привет.

У меня тут такой вопрос для темы: Как именно осуществляется округление дробных чисел в компьютере? Какими правилами он пользуется?
Я пишу программу, просто как тренировочную, в целях практики, так как я только начинаю путь программирования,ее цель (программы) это тренинг по математике, различного уровня сложности и головоломки, и вот в этой программе, возникли проблемы с расхождением результатов: результат, который ввожу я, (вычисленный на калькуляторе) отличается от результата, который вычисляет компьютер. При том что используемый калькулятор - стандартный в ОС Windows. Мало того значение в переменной округляется на разных этапах компиляции, что приводит в расхождению результатов и невозможно подобрать правильный. Такое ощущение, что компьютер играет со мной в стаканчики и крутит вертит эти результаты, чтобы запутать.

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

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

Конечно программа не принесет прибыли, и даже может пользы (в плане математики) от нее будет не много, но как практическая работа она очень интересная.


P.S. Пытался загрузить проект (правда он не закончен), но не получается пока... буду пытаться еще грузить, может кому интересно будет на него взглянуть.

0

Сообщение от Evg 0.333 0.333333 0.333333343267 0.3333333432674407959 0.3333333432674407958984375 0.333 0.333333 0.333333333333 0.33333333333333331483 0.333333333333333314829616256247 0.333 0.333333 0.333333333333 0.33333333333333333334 0.333333333333333333342368351437

На примере ↑↑ как раз применимо правило ↓↓

Чем больше бит у типа, тем более точно можно представить число (т.е. тем меньше значение этого числа будет отличаться от оригинала)

Принцип представления числа в виде "числомусор" (0.333333333333333333342368351437) (конечно же это не мусор, а труды кропотливых вычислений процессора, но в моем случае, они излишни и мешают.) в этих числах тоже понятно, но как сделать так чтоб этот "мусор" не мешал работать с подобными числами и не искажал результаты и программа работала корректно. Желательно малой кровью, потому что мои знания на данном этапе в программировании не обширны (это еще мягко сказано, я обучаюсь самостоятельно и только дошел до изучения класса и объектов класса), поэтому если есть возможность решить данную проблему малой кровью, то подскажите литературу или принцип как это сделать, если таких решений нет, то я пока оставлю данный проект, которой как мне показалось очень легкий в исполнении и дальше буду более интенсивно изучать программирование и математику, конечно же.

Более точная суть моего вопроса такова: Как заставить/попросить компилятор игнорировать "мусор", чтоб он не мешал сравнению результата, потому что именно этот "мусор" мешает работе.

P.S. Вот так будет конкретно поставлена цель моего вопроса, хотя я сам чувствую ее не корректность.

Добавлено через 10 минут

Сообщение от Renji В этом месте вы должны побить большие числитель и знаменатель на отдельные разряды и умножать/складывать их столбиком. Это собственно длинная арифметика и есть.

Понял в чем суть, видел такое в одном из постов, но просто реализовать это в программе я точно не смогу, слишком сложно, в моем случае будет на много хуже. Если только самому не высчитывать таким образом результат, когда пользуешься программой, но в таком случае пользователей(которых у этой программы и так не будет) не будет совсем))), из-за неудобства использования. А так это конечно поможет понять какое представление записано в переменной "ResultLDN" и точно такое же представление ввести в пользовательскую переменную.

0

txtbit, хотел бы внести некоторое уточнение по поводу:

Сообщение от Renji Впрочем, если вы о преобразовании double->int, то там просто обрубается дробная часть.

Не совсем так. У сопроцессора, в котором происходят все вычисления и преобразования, есть три режима округления: к меньшему, к ближайшему и к большему. По-умолчанию используется "к меньшему", при котором и происходит "обрубание дробной части".
Как поменять режим сразу не скажу,т.к. не пользуюсь. Обхожусь округлением к меньшему. Например, когда надо округлить до ближайшего, я перед преобразованием в целое добавляю 0.5

0

Сообщение от txtbit А так это конечно поможет понять какое представление записано в переменной "ResultLDN" и точно такое же представление ввести в пользовательскую переменную.

Ну возьми например double (https://ru.wikipedia.org/wiki/... й_точности) с его представлением в виде

±знак · (1+ (мантисса/2⁵²)) × 2^{порядок − 1023}

1

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

1

Общий порядок определять, взяв логарифм числа по основанию 2 и округлив до меньшего целого. Для мантиссы нужно поделить исходное число на 2 в степени, полученной из логарифма. Вычтя после этого 1 и умножив остаток на 2^52 и округлив до целого получишь мантису.

На примере 0.1 :

log₂ 0.1 = -3.32..., степень -4 (т.е. поделить на 2^-4 или умножить на 16), итого получаем 1.6, 1 вычитаем, и 0.6 умножаем на 2^52 = 4503599627370496 . Получаем число 2702159776422297.6, с дробной частью которая будет процессором округляться. И именно на эту дробную часть и будет отличаться записанное в double число от 0.1 . Суммарно запишется

(1 + 2702159776422298/2⁵²)*2^1019-1023

Добавлено через 51 минуту

Сообщение от txtbit Как заставить/попросить компилятор игнорировать "мусор"

Компилятор не сможет за тебя рассчитать, какая была накоплена ошибка вычислений в процессе производства действий. В примере выше я указал, что при попытке записи в double 0.1 фактически записанное число будет отличаться от 0.1 на 4/72057594037927936 (1/18014398509481984) . При сложении таких двух таких чисел, поскольку число будет нормироваться к единице и лишние знаки мантиссы отбросятся, величина ошибки станет ещё больше. При умножении - тем более.

В общем всё будет сложно. Но обычно (если речь не идёт о деньгах и прочих высчитываемых "абсолютно" вещах) просто пренебрегают этими ошибками и говорят "это у нас double, у него примерно 16-17 десятичных знаков, которые будут повторены точно при введении, за столько-то действий у нас ошибка вычислений не должна превысить 2-3 знака в мантисе, значит будем пользоваться только первыми 13 знаками".

0

Сообщение от txtbit Принцип представления числа в виде "числомусор"

Это не мусор. Это печать в десятичном виде того числа, которое хранится в машине в двоичном виде. А число, хранимое в двоичном виде, отличается от точного значения 1/3. Потому что точное значение 1/3 нельзя записать точно в двоичном представлении

Сообщение от txtbit но как сделать так чтоб этот "мусор" не мешал работать с подобными числами и не искажал результаты

Начать с того, что научиться внятно ставить вопрос. Если тебе нужно точное представление чисел в десятичной записи - используй специальные библиотеки. Больше никак

Сообщение от ValeryS есть старый способ округления, использовался еще до сопроцессоров например нужно округлить до сотых

Он точно так же не работает, как и не работают прочие эрзац-методы

1

txtbit, кроме формата (см. например стандарт IEEE 754 https://ru.wikipedia.org/wiki/IEEE_754-2008) есть ещё проблема сохранения значимости. Тут и близко нельзя говорить о "малой крови" в реализации. Но что бы понять предмет может пригодиться:
https://www.cyberforum.ru/blog... g3523.html
смотрите внизу, начиная со слов:

Сообщение от мутота всякая Теперь о таких вещах как точность, надёжность и сочетательность (ассоциативность).

0

Сообщение от Evg Он точно так же не работает,

что есть "не работает"?
не представляет точно число из компьютера в число на дисплей, сиречь из двоичного в десятичное представление?
Разумеется нет ибо системы счисления разные
я могу так же привести в пример задачи которые на АВМ решались точно, а на ЭВМ с определенной долей погрешности
или что то другое имелось в виду?
В прочем мы с тобой это уже обсуждали несколько лет тому назад

0

Сообщение от ValeryS ибо системы счисления разные

Не системы счисления, а системы отображения порядка числа. 16 в десятичной всегда однозначно переводятся в 0b10000 двоичной. А вот 10⁵ перевести в 2^x, чтоб x был целым, нельзя никак, т.к. log₁₀2 есть трансцендентное число.

Добавлено через 8 минут
В общем по сумме всего - автору искать или делать библиотеку или которая работает с обыкновенными дробями, или библиотеку которая работает с числами с десятичным основанием степени (тогда ошибки вычисления будут более прозрачными для понимания).

0

Сообщение от ValeryS В прочем мы с тобой это уже обсуждали несколько лет тому назад

Мы-то с тобой оба это понимаем. А вот начинающие, прочтя твой пост, могут сделать для себя неверные выводы. Поэтому дальнейшее пояснение не для тебя, а для этих самых начинающих (ну и для ТС'а):

Сообщение от ValeryS что есть "не работает"?

Берём тест из поста #24 и добавляем печать с большим количеством знаков после запятой

Т.е. сей способ НЕ округляет число. Значение по прежнему отличается от ожидаемого (т.е. от результата округления на бумаге). Всё "округление" сводится лишь к тому, что в печати с дефолтным значением точности создаётся видимость того, что округление реально отработало

К тому же у ТС, если я правильно понял, другая задача. Ему нужно работать с точным значением числа, а вовсе не напечатать на экране видимость того, что число точное. А для работы с точными значениями есть только один способ - программная эмуляция. Т.е. через специальные библиотеки

1

Сообщение от TRam_ Не системы счисления, а системы отображения порядка числа.

двоичная и десятичная это не системы счисления?

Сообщение от TRam_ А вот 105 перевести в 2x, чтоб x был целым, нельзя никак

серьезно?
10⁵=100000=0b1100001101010000=2¹⁶+2¹⁵+2¹⁰+2⁹+2⁷+2⁵

а вот здесь

Сообщение от TRam_ 16 в десятичной всегда однозначно переводятся в 0b10000 двоичной.

16 это десять в какой степени?

0

Сообщение от ValeryS серьезно?

Тут 7 слагаемых с разной степенью, а мне нужно одно. Причём можно даже с коэффициентом (но не равным 10⁵ и целочисленным). Ешё раз - я говорю о той степени, которая называется порядком числа. И в которое возводится основание, определяющее положение плавающей точки.

Добавлено через 1 минуту

Сообщение от ValeryS 16 это десять в какой степени?

В степени 1.2041199826559247808549...

0

Сообщение от Evg К тому же у ТС, если я правильно понял, другая задача.

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

После первых измерений ему показалось, что картина распределения получится слишком грубой. Он решил уточнить методику. Перебрал несколько сортов нитей подвески. Поставил сверхчувствительный гальванометр. Затем ему пришло в голову автоматически стабилизировать температуру прибора. Учесть искажающее влияние трансформатора… — Почему вы не учитываете полярных сияний? Заряды кота у сторожихи? — спросил его Аникеев. — Вы больны. Болезнь называется «немогуостановиться». Научитесь себя ограничивать. Получили примерную величину и двигайте дальше. Искать истину в последней инстанции — зряшный труд. И существует ли она, эта последняя инстанция?

(с) Д. Гранин "Иду на грозу"

Добавлено через 2 минуты

Сообщение от TRam_ Тут 7 слагаемых с разной степенью, а мне нужно одно.

значит десятичное будет не в целой степени

Сообщение от TRam_ В степени 1,2041199826559247808549...

что сии точки означают, уж не бесконечную дробь ли?

0

Сообщение от ValeryS насколько я понял у ТС непонимание что числа хранятся в машине не так как пишет человек на бумаге

Это не только у ТС. Думается, это как минимум у половины форума. К сожалению, по простому такие вещи донести не получается. А если уходить в конкретику, то получится слишком сложно

Сообщение от ValeryS и к тому же болезнь "немогуостановится"

Для начала болезнь "не могу внятно сформулировать хотелку". А потому никто не понимает, чего в точности он хочет. А понимали бы - давно бы дали совет, как поступить

1

Именно её и означают. Не была бы она бесконечной - тогда можно было бы скомбинировать превращение 10 в 16 с помощью корней и степеней, а так всё ещё хуже :

Сообщение от ValeryS значит десятичное будет не в целой степени

т.е. основание 10 будет в степени бесконечной дроби. И поэтому одно в другое в целых величинах не переводится. И даже (т.к. дробь бесконечная) даже в целых корнях не переводится.

Добавлено через 3 минуты

Сообщение от Evg А понимали бы - давно бы дали совет, как поступить

Автор просто хочет проверить точность математики, не зная математики, но с помощью же математики . Те примеры, которые он дал в посте #6 показывают, что скорее всего не знаком с обыкновенными дробями и не слышал о нахождении наибольшего общего делителя.

0

Сообщение от TRam_ .е. основание 10 будет в степени бесконечной дроби. И поэтому одно в другое в целых величинах не переводится.

так об том и речь

0

Стоит ли вам так округлять для сравнения до n знаков не вижу смысла, ведь это можно считать ошибкой.
ведь одно дело когда 5,0005 == 5, другое когда 0,001==0,0015
Но может это вам поможет, когда мне нужно было выводить фиксированной длины знаков после зпт, то я либо в процессе расчета, либо перед выводом, округлял их с помощью round или других функций округления

обычно до 3 знаков требовалось
round(znachenie * 1000) / 1000

или мб вам стоит перед началом умножить значения переменных на 100000 , провести расчеты,а перед сравнением снова разделить на 100000 и вывести результаты.

0

Сообщение от SemenTVS то я либо в процессе расчета, либо перед выводом, округлял их с помощью round или других функций округления

это очень страшная фраза. SemenTVS, покажите-ка пример того, как Вы

Сообщение от SemenTVS в процессе расчета

Сообщение от SemenTVS округлял их с помощью round или других функций округления

0

Никто не понимает, чего в точности он хочет. А понимали бы - давно бы дали совет, как поступить

Для конкретики вопроса, скомпилируйте этот участок кода, и вы поймете о чем я говорю. Вот это и есть суть моего вопроса.

Вписать распознание кириллицы придется самим, потому что я не знаю пока как именно ее распознавать, меня пока так все устраивает...

Добавлено через 6 минут
Эти примеры решаются методами описанными вами выше, уважаемые форумчане, но просто задумка этой программы, чтоб человек, который не в курсе всех этих премудростей математики, мог просто потренироваться в вычислении подобных примеров (не знаю зачем ему это, но просто такой кайф у него в свободное время), и чтоб просто порешав на бумаге, он мог ввести свои результаты и они совпадали с тем, что "на решал" компьютер.

0

Сообщение от "txtbit; Вот так:-8.40939720e-06 выглядит результат в переменной Result когда видишь его через отлдачик.

Число хранится в форме мантисса*2^экспонента. У вас запись в форме мантисса*10^экспонента. То есть, экспонента меньше в log2(10) раз. А так как точного значения логарифма десяти по основанию два отладчик не знает, при пересчете мантиссы получаем ошибки округления.

Сообщение от "txtbit cin >> UserResult;

Попытка ввести 0.что-то там, это попытка ввести десятичную дробь. Еще раз получаем ошибки округления.

Сообщение от "txtbit if (UserResult == Result)

И конечно же, итоговое число с исходным уже не совпадает.

1