SergeSerge3leo
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Eugeen
Цитата:| придумать реальные задачи с невозможностью считать с несократимыми дробями довольно сложно практически. |
Честно говоря, лично мне, достаточно сложно придумать реальные задачи, которые можно было бы решить в рациональных числах типа:
Код: type rational
integer(8) nominator
integer(8) denominator
end type
|
Для тех задач, которые, лично мне, кажутся реальными, при их решении в точных рациональных числах требуется многократная точность. Например, Фортран интерфейс к библиотеке GMP предлагает: type(mpq_t).
Цитата:| Если в несократимой дроби из примера выше: sum(1/k, k = 1 .. 31) = 290774257297357 / 72201776446800 из числителя вычесть 1, то результат будет отличаться на -3.4390939875305444541428421975796e-13 |
Мне встречались статьи в которых рассматривалась реализация "приближенных рациональных чисел" ("приближенная рациональная арифметика"). Там не всё так просто с алгоритмами, например, в данном случае, вычитание 1 не позволяет после сокращения привести числитель и знаменатель из диапазона 0..249 в диапазон 0..231, требуется, либо рекурсивное продолжение банкета, либо вычитать надо было не 1.
Кроме того, смысл применения "приближенных рациональных чисел" неясен. В самом деле, при использовании рациональных чисел без спецфункций мы можем использовать любые методы без оглядки на численную устойчивость, например, тоже LU разложение. А при использовании "приближенных рациональных чисел" у нас каждая операция, в худшем случае может дать определённую относительную и/или абсолютную ошибку, соответственно мы должны выбирать численноустойчивые методы и оценивать ошибки этих методов. Заметим, с точки зрения худшего случая "приближенные рациональные числа" примерно эквиваленты обычным плавающим числам или числам с фиксированной точкой.
А как использовать тот факт, что они немного "рациональные", хоть и "приближенные", при анализе погрешностей методов, лично мне, совершенно непонятно.
В любом случае, наши задачи обработки наблюдений, даже для моделей с матрицами плана (если, конечно, их вычислить) "типа дроби 100000000\1 вне главной диагонали и 1\10000000 на ней" более менее нормально решались даже на одинарной точности (real*4), конечно, при небольшом количестве измерений (десятки и сотни) при использовании сингулярного разложения. Сейчас измерений больше (бывает, и десятки тысяч, и более), так что спокойнее использовать (real*8), а не балансировать "на грани фола".
P.S.
Цитата:| Напр. для аттестации кодов безопасности обязательно надо представлять верификационный отчет (на равне с валидационным) иначе, без аттестационного паспорта прогой пользоваться для обоснования безопасности нельзя. |
 Антиресно, а что бы Вы (или Вам) в таковом отчёте написали бы про LUFACT()/LUSOLV() или про BACKW1()? |
А если применить мозг и творчески доработать до рабочего, то от "на ней" не останется ни одного байта. 