zub писал(а):>>Это полный бред
не бред. 0+1 конечно сработает точно, но есть мноооого других чисел которые в десятичной системе выглядят коротко и красиво, а в двоичной не имеют точного представляния. Просто смириться и учитывать - ничего в этом страшного нет.
>>Есть число, заданной размерности, ему присваивают 0, а потом увеличивают на 1. Оно не может, не в какой логике быть после 1,000001.
непонял к чему это, но если так происходит, то это глюк не компилятора, а программы))
Ну из моего примера посмотри комменты. Округление вне диапазона -1...1 происходит нормально, а округление внутри него выдает "паразитное" значение. Прототипы моих расчетов в Delphi все считали нормально. Если такая погрешность существует, это не задача для высокого уровня(lazarus), это должно было обработаться на низком уровне, где компилятор рулит, иначе какой толк от fpc и lazarus, если все равно самому считать байты надо.
Если условность в точности есть, то она должна быть везде, а не здесь хочу, а здесь не хочу. Следовательно с твоих же слов, и арифметика должна была компилятором обработаться с учетом погрешности. Операторы +-/*= это не мы решаем как они работают, а в компиляторе описана их функция. Не нормально, если половина расчета выполняется что "1*0,8=0,8", другая "1*0,8=0,800004" (к примеру). С трудом представляю как вывести на чертеж/в форму/еще куда то коэффициент расчета "0,8", если его даже функция округления превращает переменную с ним в число с 10 знаками после запятой, вместо заданных ей 2х.
wavebvg писал(а): Это дорого (с точки зрения машинного времени), но Вы можете реализовать это самостоятельно и радоваться точности.
С точки зрения машинного времени дорого изначально правильно высчитать число, а потом оперировать десятком таких в более медленных функциях корректировки числа не дорого?)))
