История изменений
Исправление 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 ? Вот вопрос.