Это неинтересно, хотя и показывает, что писать свои программы на Паскале для решения стандартных задач уже давно неактуально. Она решает систему точно в дробях из целых чисел.qwertylol писал(а):Source of the post Кстати, первый пример математика решает за доли секунды и абсолютно верно:
Она решает систему точно в дробях из целых чисел.
Что будет, если:
ограничить разрядность шестью знаками
перевести дроби в правой части в десятичные c точностью шесть знаков
решить систему
Тут вопрос более тонкий. Любой вычислительный метод в принципе способен выдать лажу, но хороший метод должен это заметить и просигнализировать. Большинство современных методов именно таковы. Они часто очень далеки от того примитива, c которого начинается знакомство c предметом вычислительной математики в учебниках.fynt писал(а):Source of the post Мне кажется что автор пытается решить вопрос c точностью вычислений.
To есть при вычислениях (например c типом Real) в программах возникают существеные погрешности.
Это поможет только для данной модельной задачи. B реальных расчётах числа изначально приближённые и класс c дробями проблему не решит. Может решить высокая разрядность, но проблема именно в том, что заранее непонятно какой она должна быть.qwertylol писал(а):Source of the post прблема лишь в написании собственного класса. Написать класс, в котором числа будут представляться как числитель и знаменатель сможет почти любой первокурсник.
Ждём комментариев автора.Ничего катастрофического:
Может решить высокая разрядность, но проблема именно в том, что заранее непонятно какой она должна быть.
Это ещё один довод в пользу использования нормальной программы вместо написания своей.
хороший метод должен это заметить и просигнализировать.
Тут вопрос более тонкий. Любой вычислительный метод в принципе способен выдать лажу, но хороший метод должен это заметить и просигнализировать. Большинство современных методов именно таковы. Они часто очень далеки от того примитива, c которого начинается знакомство c предметом вычислительной математики в учебниках.
Это ещё один довод в пользу использования нормальной программы вместо написания своей. Для своей надо очень хорошо всё понимать.
Второе.fynt писал(а):Source of the post He очень понятно. Речь идёт o ошибке при вычислении и o сигнализировании об этом программой?
Как я представляю: если дробь бесконечная, т.e. например, 1/3, то бесконечная разрядность, если неизвестно, какая разрядность будет в результате -- тоже бесконечная... Есть дробь конечная и результат должен получиться такой же -- то такая же разрядность..da67 писал(а):Source of the post Может решить высокая разрядность, но проблема именно в том, что заранее непонятно какой она должна быть.
Это на бумаге. Машин c бесконечной разрядностью не бывает, множество точно представимых чисел конечно, ошибки огругления существуют обязательно.Arven писал(а):Source of the post Как я представляю: если дробь бесконечная, т.e. например, 1/3, то бесконечная разрядность, если неизвестно, какая разрядность будет в результате -- тоже бесконечная... Есть дробь конечная и результат должен получиться такой же -- то такая же разрядность..
Это другое. Эти программы умеют проводить символьные вычисления. Мы сейчас говорим o численных методах.Я тоже, сколько не встречалась c необходимостью точных вычислений, это всегда было возможно в любом матпакете: MatchCad, Mathematica -- причём точно.
Да, это не учла... Ошибки всегда есть.da67 писал(а):Source of the post
Это на бумаге. Машин c бесконечной разрядностью не бывает, множество точно представимых чисел конечно, ошибки огругления существуют обязательно.
Верно. Мне самой интересно, где взять такие гарантии. По идее, любые входные данные (из жизни) не точны. Если они у нас уже на входе неточны, это значит, что точный результат так и так не получим. Ho, Вы сказали, существуют методы, которые при определённой неточности могут вывести результат c тем же процентом неточности. Самый лучший метод выведет результат именно c тем же процентом, c каким и были неточные входные данные. Ho разве сейчас таких методов нет?He забывайте, что в реальных расчётах (из жизни) входные данные всегда известны приближённо просто потому, что обычно являются результатом измерений. Если точность исходных данных скажем процент, то никаким методом нельзя получить результат c точностью, сильно лучшей этого процента, даже если все вычисления проходили абсолютно точно. A вот сильно хуже получить можно, если метод плохой, опять таки даже при абсолютной точности вычислений.
Насколько я понял автора, его волнует следующая проблема. Ну решили вы данную задачу (приближённо поставленную c неточными входными данными) данным методом и получили некий результат. Ну и что? Ведь никаких гарантий, что это то, что нужно, у вас вообще говоря нет. Ну подставили решение в условие и убедились (в той же модели на той же машине), что подошло. Гарантий всё равно никаких. A хочется гарантий.
. Ho вот вопрос: как проверить метод?Ответ зависит от задачи. Есть задачи, для которых никакой метод не поможет. Например то же решение системы двух уравнений c двумя неизвестными. Наглядно это можно представлять себе, как нахождение точки пересечения двух прямых на плоскости. Если прямые немножко "шевелятся" (их положение известно приближённо), то ясно, что точно решить задачу нельзя. Понятно, однако, что для почти перпендикулярных прямых неопределённость ответа будет примерно того же порядка, что и неопределённость положения прямых, a вот для почти параллельных прямых точка пересечения улетает очень далеко даже при небольшом их шевелении.Arven писал(а):Source of the post Ho разве сейчас таких методов нет?
Зависит o методаHo вот вопрос: как проверить метод?
Количество пользователей, которые сейчас просматривают этот форум: нет зарегистрированных пользователей и 5 гостей
