LINUX.ORG.RU

История изменений

Исправление dva20, (текущая версия) :

Компьютер не умеет хранить их именно в десятичном виде

Да, это было как бы понятно и до этого вопроса, вопрос в другом был, почему перенос запятой (умножение на 10.0 введенных с клавы) не может быть без потери правой части исходного числа. Ну пусть бы оно там плавало в большую сторону, и при умножении 0.56 * 10.0 выдавало бы 5.600000000001, но в реальности плавает в меньшую сторону и результат может быть 5.599999999998.

То есть, по сути то я ввёл 10.0, а не 9,9999999. Вот в чём вопрос. Куда C++ дел мои доли? Или почему он их УКРАЛ зараза такой?? Это что за комиссии такие!? ))))))

Если бы я ввел 9.99999999 при умножении 0.56 × 9.99999999, то я бы и получил результат ожидаемый как 5.5999999944. Так работает KCalc в KDE.

Но я ввёл 10.0, а С++ записал это в двоичной системе как 9,999999999…. Почему он не записал это как например 10,000000000000011 ? Вот вопрос.

Исходная версия dva20, :

Компьютер не умеет хранить их именно в десятичном виде

Да, это было как бы понятно и до этого вопроса, вопрос в другом был, почему перенос запятой (умножение на 10.0 введенных с клавы) не может быть без потери правой части исходного числа. Ну пусть бы оно там плавало в большую сторону, и при умножении 0.56 * 10.0 выдавало бы 5.600000000001, но в реальности плавает в меньшую сторону и результат может быть 5.599999999998.

То есть, по сути то я ввёл 10.0, а не 9,9999999. Вот в чём вопрос. Куда C++ дел мои доли? Или почему он их УКРАЛ зараза такой?? ))))))

Если бы я ввел 9.99999999 при умножении 0.56 × 9.99999999, то я бы и получил результат ожидаемый как 5.5999999944. Так работает KCalc в KDE.

Но я ввёл 10.0, а С++ записал это в двоичной системе как 9,999999999…. Почему он не записал это как например 10,000000000000011 ? Вот вопрос.