Вот у меня по логике некоторый числовой тип данных должен быть целым (инт, например), т. к. выражает количество раз и тому подобные величины, которые дробными быть никак не могут. А в расчётах нужно использовать их как числа с плавающей запятой, т. к. может быть ситуация вида "1/3" и тому подобные.

При этом расчёт находится в модели.

Как поступить - в модели же хранить их как с плавающей запятой, и только в модели представления превращать в целые, чтобы уже в представлении для юзера они представлялись как целые? Или в модели и в модели представления хранить как целые, а в расчётах превращать в с плавающей запятой?

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

Или, может быть, есть другие варианты?

Nicky_Nuser7320,

второй, имхо, лучше. и что плохого в приведении типов?
Плохо то, что:

1. Загромождаются вычисления. У меня и так громоздкая формула, я уже не знаю, как на Сишарпе её получше расположить, чтобы читаемость была хоть небольшая, а если ещё вместо

a + Math.Pow(b, 2.0) / (3 - 1)

писать

(double)a + Math.Pow(b, 2.0) / ((double)3 - (double)1)

то вообще заблудиться можно. И это ещё простой вариант.

2. Надо постоянно помнить, что нужно приводить типы. Хорошо, если есть функция расчёта и все её параметры можно сделать даблами, а передавать ей инты и приводить их в даблы при передаче), а если в произвольном месте, без специальной функции расчёта?

pationвыбор типа данных, зависит от требований, а не от модели, представления или температуры воздуха
Требования это и есть модель. В смысле, что модель разработана по требованиям (тех. заданию). Ну и для "количества раз" как-то глупо использовать вещественные числа, когда это натуральные даже по самой логике вещей. Я считаю, что модель должна максимально точно отображать окружающий мир. То, что при вычислениях все числа и результаты, начиная с какого-то момента всё равно превращаются в числа с плавающей запятой (кто даст гарантии, что результатом не будет дробное число, да ещё какое-нибудь иррациональное?), говорит о том, что проще изначально все числа, участвующие в расчёте, сделать с плавающей запятой и затем уже не мучаться с проверками и не гадать, где стоит приводить, а где нет. Но это не является отображением реального мира, это является костылём, который вынуждены применять из-за несовершества представления чисел в компьютерах.

Nicky_Nuser7320,

зачем приводить к типу double операции сложения, вычитания? double ведь нужен только при делении, так? можно переписать:

(double)(a + Math.Pow(b, 2.0)) / (double)(3 - 1)
Да это я для примера написал. Для себя я уже решил, что буду заводить функцию вычисления и все параметры там в даблах делать, а при передаче интов их в даблы приводить. В моём случае это самое лучшее решение.

А на самом деле (сейчас откопал кусок кода) там вот такая запись (тоже не вся, но именно тот кусок, что приводил к неправильным данным):

Math.Pow(2 + (p / precision), 2.0)

Здесь precision - натуральное число, а p - переменная, принадлежащая закрытому интервалу [1; precision]. Если их обозначить, например, интами, то будет неправильный результат вычисления (p / precision) из-за округлений. Для себя я решил, что лучше на входе функции, которая содержит в себе такой код, приводить все целые к вещественным и не париться о результате.

Кстати, в пользу "теории универсальности" говорит тот факт, что функция фреймворка Math.Pow принимает только числа с плавающей запятой, да ещё только с двойной точностью, включая показатель степени . Вот стринги всякие перегружены по сто раз, чтобы по 17 разных типов принимать, а с Повером такое не сделали - почему?

pationa + Math.Pow(b, 2.0) / (3d - 1d)
Вот такой способ я буду использовать, когда не будет отдельной функции для расчёта и не будет возможности изначально все переменные для расчёта приводить к плавающей запятой.

Arm79CodeProject - Rational Numbers - .NET 4.0 Version (Rational Computing 1)
Спасибо, почитаю.

Arm79CodeProject - Rational Numbers - .NET 4.0 Version (Rational Computing 1)
Меня смутило, что это за специальное такое представление рациональных чисел. Потом понял, что это структура именно для представления обыкновенной дроби.

Так мне не нужна обыкновенная дробь. То, что там дробь где-то у меня возникает - это неважно. Я всё равно с некоторым приближением её вычисляю и превращаю в десятичную. Так что не понимаю, чем мне может помочь структура для представления обыкновенных дробей. Разве что все вычисления с дробями вести в виде обыкновенных дробей (с помощью этой структуры), тем самым не накаплавия ошибок при промежуточных вычислениях, а окончательное вычисление делать только в конце?.. Но всё равно, могут попасться невычисляемые без потери точности дроби, так что в конце всё равно при последовательном вычислении дробей будут накапливаться ошибки... Вот если бы эта штука поддерживала сокращение дроби и упрощение выражений, вместо того, чтобы тупо произвести последовательность действий над числами, которые можно сократить... С другой стороны, заложенные формулы всё равно же я сам пишу, поэтому все операции по сокращению я же сам и делаю ещё на стадии написания формул... А закладывать аппарат символьных вычислений с упрощениями и сокращениями... да ну нафиг.

Мне эти рациональные типы данных пригодятся в другом месте, где у меня ошибки из-за погрешностей округления даблов. Ещё только вот найду информацию о производительности этих Rational.