Semen PopovРебят, я понял, что Java не врет. Но, мне от этого не легче. Целью своего сообщения ставил поиск выхода из таких ситуаций. Возникнут задачи, в которых мне нужно будет работать с вещественными типами (5-7 значащих цифр до дробной точки и 3-5 после) и быть уверенным, что получу точный результат (хотя бы при операциях сложения и вычитания). Получил совет - использовать BigDecimal. Спасибо.
Ну и пусть другие языки округляют - результат-то я получу тот, который мне нужен. Я не понимаю, почему при сложении 2 разрядов после точки округление выполнять - это неправильно. Оно туда напрашивается. Да, вы мне по-доброму напомнили, как хранятся вещественные типы в памяти, да, операции над ними выполняются с погрешностью, но, опять же, мне нужен результат. В примере я складываю и должен получить результат - десятичную дробь не более 6 значащих цифр до точки и 2 после - всего 8 значащих цифр. Не воспринимайте в штыки, что для меня увиденное удивление, потому что у меня есть другие программы (не на Си), где делаю эти операции и получаю ответ, не зависимо от того, что вещественные типы одинаковы. Только что сварганил пример и перепроверил. Никаких округлений при выводе, вывожу как строку (хотя форматы вывода существуют различные). Там использую тип REAL (объявляет 8-байтовую переменную со знаком в формате с плавающей точкой Intel 8087 (двойной точности), 15 значащих цифр), имеется библиотека двоично-десятичных операций и процедур (Binary Coded Decimal (BCD)), которые выполняются таким же образом как операции десятичной арифметики выполняются на бумаге. В этих операция используются промежуточные значения с точностью до 31 значащих цифр с каждой стороны от десятичной точки. Возможно, еще в этом отличие.Привет!

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

Так же и в этом варианте Java выдает КАК МОЖНО БОЛЬШЕ ошибок на этапе компиляции и разработки.
к примеру на иных языках программирования на "малых" знаках точности округления может хватать и результат будет совпадать с нужным. Но если вдруг исходные данные превысят предел точности округления, то в ПО пРоявится ошибка. В отличие от этого подхода Java выдает "ошибку" сразу (в том смысле, что не скрывает от программиста свои данные).

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