или 'арифметические вычисления и небезопасность универсального полифорфизма'

проект
arithmetic -- классы для для симплекс метода
побочный эффект - разный результат в вычислениях (3 * 5) / 2
из-за разного округления в классе целых.

Очередной пример нарушения принципа, который сводит к нулю
пользу от универсального полиморфизма в обеих формах.
Как от полиморфизма включения, так и от полиморфизма шаблонов.

Есть две версии полиморфной функции:
одна написана в терминах базового класса (каталог v2/PrgFunc.cs)вторая, как шаблон (каталог v3/PrgFunc.cs):Округление до целого в них выполняется при помощи обычного отбрасывания дробной части:
(int) out1;

Но в классе целых деление переопределено так, что используется банковское округление
и 15 : 2 дает 8

в результате обе версии полиморфной функции возвращают
разные значения то ли 7, то ли 8 в зависимости от реального класса объектов.

Это результат (надеюсь) всем известных проблем с условиями
контра- и ко- вариантностью
функционального типа метода. Эти условия всем разжевали Б.Мейер и Л.Карделли.
для методов (функций) у которых множество объектов класса появляется
с левой и с правой стороны функциональнй стрелки:

f: domen(class) >< X -> domen(class) >< Y
(для любых множеств X и Y)
/*
Стало понятно после формального анализа примера Мартина
с наследованием квадратов и прямоугольников
в статье Об отличиях между понятиями типа и класса
https://www.researchgate.net/publication/344177979
, что условия в родительском классе можно задавать таким образом, что область определения
и множество значений метода не будет меняться. Но к нарушению принципа подстановки будет приводить.
*/

В такую группу методов попадают все алгебраические операции:
domen(class) >< domen(class) -> domen(class)
То есть, функции для вычисления чего либо, скорее всего, нельзя писать
полиморфные.
/*
в Переопределении сложения: небезопасное наследование
в группе целых
(https://www.researchgate.net/publication/366867037)
приводился пример с проблемой на операциях вычитания, переход от полугруппы натуральных к группе целых)

*/

В частности, в этом примере, проблема заключается в операциях деления (переход от кольца целых к полю вещественных)ИМейер и Карделли показывали пальцем на эксепшены полиморфной функции.
в текущем примере полиморфные функции (function) не выбрасывает эксепшен,
а тихонько начинает нарушать начальное требования
-- для округления использовать отбрасывание
дробной части. Это еще хуже, чем эксепшн.

Классы integer и real были отлажены, что бы показать как плохо
станет работать полиморфный симплекс метод.
В текущем примере результат сем-восем еще такое дело,
а неправильная оптимизация в симплекс методе явно будет нарушать
начальную спецификацию при попытке использовать универсальный полиморфизм.

Виды округления в Си Шапре согласно IEEE 754 -2019
Округление к ближайшему или четному (Банковское округление)
Math.Round(v, MidpointRounding.ToEven)
Округление к ближайшему или большему по модулю
Math.Round(v, MidpointRounding.AwayFromZero)

выбирается ближайшее целое число, а если их два - то,
в первом случае -- четное, во втором -- большее по модулю.

Округление отбрасыванием дробной части
(int) v или Math.Truncate(v)

Округление к положительной бесконечности
из двух целых чисел выбирается большее:
Math.Ceiling(v) или
Math.Round(value, MidpointRounding.ToPositivetiveInfinity)
Округление к отрицательной бесконечности
из двух целых чисел выбирается меньшее:
Math.Floor(v ) или Math.Round(value, MidpointRounding.ToNegativetiveInfinity)