Удивительные вычисления в C12

[Игорь Столяров]

Вот даже при глубоком уважении к погружению автора в столь актуальную тему, нужно упомянуть
год публикации: 2006. А написано наверно в конце прошлого века. Где-то там были процы i286 и
упомянутые "мат. сопроцессоры" к ним ... Т.е. это всё безусловно верно. Но актуально 30-40 лет назад.

Сейчас у каждого в кармане смартфон с вычислительной мощностью майнфрейма тех времён.
Уже не нужно считать такты сложения двух чисел. Можно выходить из леса - немцы ушли.

[finsoftrz]

Вы ошиблись лет на 20.
Если что-то работает быстрее, универсальнее и совместимее, то почему бы этим не пользоваться, только чтобы не писать round? Для тех, кто уже привык писать round на автомате, так себе аргумент.

[Игорь Столяров]

Для тех, кто уже привык писать round на автомате, так себе аргумент.

Здесь ещё нужно посчитать насколько вызов Round() для нормализации замедляет вычисления с REAL.
Но дело в другом. Round() - это всегда потеря точности. Даже если это "правильная" потеря как с REAL.
Я использую и REAL и Round() - но точечно именно там где они нужны - вычисления без потери точности
и округление результата таких вычислений. Для финансовых вычислений - DECIMAL. Как-то так.

[finsoftrz]

Если я правильно понимаю, по этой причине Вы вместо одного проекта параллельно ведете два?
Что Вы будете делать, если потребуется изменить точность decimal поля в базе данных, нужно конвертировать и пересматривать все места, где может использоваться?

[Игорь Столяров]

пересматривать все места

Как раз таки и нет !
Гипотетически предположим, что в БД точность поля PROCENT меняется с 2-х знаков на 4-е знака после десятичной точки.

Изменяем формат поля с DECIMAL(13,2) на DECIMAL(15,4), при необходимости конвертируется БД и ... всё.
Мне не нужно лопатить весь код и заменять конструкции PROCENT = Round(X,.01) на PROCENT = Round(X,.0001)

Я понимаю, что при использование REAL можно гибко менять точность значений без изменений в БД.
Но так ли часто это нужно, что бы долгие годы "на автомате" плодить в коде бесконечные ROUND() ?
У Вас в соседней теме есть красивая статистическая табличка. Посчитайте в ней кол-во операторов ROUND().

[finsoftrz]

Никогда особо не задумывался, чтобы уменьшить количество round. В принципе, никто не запрещает сгенерить код, который автоматом выполняет round в функциях модификации базы данных (я крайне редко напрямую использую обычные add/put). В бизнес логике все считаемые значения группируются в блоки, можно сделать процедуры, которые округляют все real поля в переданной параметром group или queue. Это действительно позволяет сильно уменьшить количество кода.