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()? |