Здравствуйте всем!

Таблица содержит поле типа REAL. Признаюсь, что это деньги. Знаю, что денежки лучше хранить в копейках, но вот руки пока не дойдут до изменения структуры.
А теперь, если не брать во внимание то, что это деньги, т.е. рассматривать общий случай. Сейчас для себя хочу прояснить некоторый общий случай для решения проблемы сложения вещественных чисел. Стоит задача - сложить REAL-значения полей таблицы. Учитывая то, что получаем погрешность в вычислениях в стандартном решении приходят мысли его обхода. Возможно ли это?
Вариант:
Есть ли возможность операции сдвига плавающей запятой вправо на 2 позиции? Тогда можно было было складывать не REAL-значения, а целые части от умноженного на 100 значения. Что-то типа . Даст ли это правильный результат?

Может есть другие, пусть непримитивные, решения?

С уважением, Семен Попов

Пробовал. Иначе бы не справшивал про сдвиги. и дают неверный результат. Я думал, что операция сдвига будет корректно отрабатывать. Если она, конечно, существует.
Есть еще варианты? Может с преобразованием типов? С использованием строковых типов? Для меня пока не важна скорость вычисления (я все равно вскоре перейду на копейки) - мне важен верный результат. Спасибо

Mark BarinsteinЗдравствуйте.

Пример того, что не нравится, можете привести?Мне не нравится то, что при сложении REAL-значений максимум с двумя знаками после запятой я получаю погрешность в сотых долях. Одно из решений - хранить значения в копейках (х100). Это будет решено, но позднее. А сейчас думаю, как подшаманить скрипт так, чтобы погрешности при суммировании избежать. Были варианты складывать целые части от умноженного на 100 значения. Допускается получить сумму копеек - в приложении я это обработаю. Но скрипт в моем случае (около 200 записей) дает неверный результат. Может ли этот скрипт давать погрешность?

Скрипты и дают одинаковый, но неверный результат. Набор значений, на которых тестировал, приложил к сообщению. Отдав сложение приложению (по записям из ), получаю результат - 972114.71 . Этот же результат получаю с помощью формул Excel. А вот скрипт даёт результат 972114.70 . В чём загвоздка?

Не прокатывает. Получается тот же результат - 972114.70 . Может легче будет копейки получить? Результат 97211471 меня бы устроил.

Спасибо всем за отзыв. У меня DB2 версии 8.1.14.
Заметил такую ситуацию. Скрипт возвращает неверное значение 972114.70 , а скрипт дает верный результат 972114.71 . Выходит, что округлять нужно только итоговый результат?

Vladimir KiselevРеально округлять нужно там, где это нужно (смешно звучит, но так и есть).Да, я знаю, что в бухгалтерии разные правила вычислений. Например, можно иметь два денежных значения 100.144 и 100.353 , с которых нужно получить сумму. В первом варианте можно сложить округленные до сотых значения и получится сумма 100.49 . Во втором можно сначала сложить значения, затем округлить итог. Тогда получим сумму 100.50 . Понятно, что эти правила должна мне указать бухгалтерия.

Но, мой случай простой. Нужно просто просуммировать поля, в которых пользователи из приложения "визуально" сохраняли только рубли с копейками (целые с сотыми долями). Складывая сотые должно получится число не более, чем с двумя знаками после запятой. Как хранятся эти деньги в базе - это другой вопрос. Проблема техническая. Моя, а не у бухгалтера. Вот и думаю, пытаюсь выявить для себя какую-то закономерность, правило, как ведёт себя DB2 при сложении вещественных значений, какую команду ей указать, чтобы сложение было верным. Я более, чем уверен, что ошибка у меня закралась не в скриптах, а в значениях. Возможно, одно из значений при округлении теряет одну копейку, которая мне и не достает в итоговой сумме. Грешу на приложение. Вeщественные типы java могут также создать погрешность, и в итоге получим уже двойную погрешность.

В любом случае, думаю, что правило должно отрабатывать верно. Поищу проблему у себя. Спасибо.

Vladimir KiselevНе для обсуждения, может это натолкнёт Вас на мысль, у Вас прозвучало, что с помощью формул Excel Вы получаете один результат, а с помощью DB2 другой, вероятно в данном случае искать нужно в разнице реализации расчётов в Excel и DB2 (Ваш скрипт). В Excel, по мимо прочего есть понятие отображения данных и хранения. Собственно это всё, удачного поиска ;)Это верно. Спасибо. Но, думаю, Excel здесь не причем. Я скинул данные с html-страницы, в которую вывел значения из набора . И в html-странице и в xls-файле бухгалтерами были проверены значения. А затем я их просуммировал с помощью формул. Т.е. DB2 мне показала те значения, которые были введены пользователями. Складывали их вручную и с помощью Excel, результат одинаковый и правильный. А вот, отдав сложение к СУБД, получал неправильный результат. Еще раз наталкиваюсь на мысль, что проблема в отображении значений в java-приложении. Там также используются вещественные переменные. Какое-то из значений DB2 показывается нормально, но реально имеет погрешность.

Евгений ХабаровДля Java:
1. Не используйте тип float, пользуйтесь типом double для любых вещественных операций. Проверено практикой.
2. Как делаете преобразование в яве из вещественного в строку? По дефолту можно иногда получить не совсем то что хотелось. Рекомендация: пользоваться DecimalFormat.Большое спасибо. Уже обнаружил несоответствие Вашим рекомендациям. Будем исправлять.