ВУЗ:
Составители:
На первоначальном этапе не следует стремиться к
оптимизации кода в ущерб его читаемости. Такую оптимизацию
отложите на потом, когда программа будет отлажена.
Не скупитесь на комментарии. При повторном
использовании программы они вам очень пригодятся.
II.Используйте графику времени выполнения.
Визуально контролировать поведение решения НАМНОГО проще и
нагляднее, чем просматривать огромные поля цифр. По этой
причине чрезвычайно полезно строить график (или
поверхность) решения после каждой итерации. В случае
неустойчивости счёта обычно удаётся увидеть, в каком месте
(по пространству) зарождается и нарастает неустойчивость.
Особенно это заметно в случае, когда неустойчивость
вызывается краевыми условиями. При обкатке программы можно
сравнивать численные решения модельных задач с точными
аналитическими, выводя на экран дисплея графики тех и
других.
III.Желательно, чтобы все величины, используемые программой
были выражены в одной системе единиц.
Постоянный перевод единиц из одной системы в другую в
разных местах программы и использование внесистемных
единиц измерения часто становится для программиста
настоящим бедствием и может стать источником
многочисленных ошибок. Поэтому такой перевод желательно
производить только один раз, при считывании входных данных
(и возможно второй, при выводе результатов). Иногда можно
рекомендовать написание программы в обезразмеренных
переменных.
IV.Везде, где возможно при отладке следует использовать
объективный контроль.
При проверке правильности записи громоздких конечно-
разностных выражений чрезвычайно полезно проверить
результаты численного дифференцирования, подставив в
качестве решения пробные функции и сравнив с результатом,
полученным аналитически. Прежде всего, это позволит
проверить наличие аппроксимации. Однако значение такого
теста глубже: это почти гарантия, что конечно-разностный
оператор запрограммирован правильно, так, как
предполагалось в конечно-разностной схеме.
При написании каких-либо вспомогательных процедур
всегда, когда это возможно, их следует оттестировать
отдельно. Например, процедуры прогонок или алгоритм Гаусса
решения системы линейных уравнений можно проверить на
модельных системах линейных уравнений сравнением
полученного решения с точным.
На первоначальном этапе не следует стремиться к оптимизации кода в ущерб его читаемости. Такую оптимизацию отложите на потом, когда программа будет отлажена. Не скупитесь на комментарии. При повторном использовании программы они вам очень пригодятся. II.Используйте графику времени выполнения. Визуально контролировать поведение решения НАМНОГО проще и нагляднее, чем просматривать огромные поля цифр. По этой причине чрезвычайно полезно строить график (или поверхность) решения после каждой итерации. В случае неустойчивости счёта обычно удаётся увидеть, в каком месте (по пространству) зарождается и нарастает неустойчивость. Особенно это заметно в случае, когда неустойчивость вызывается краевыми условиями. При обкатке программы можно сравнивать численные решения модельных задач с точными аналитическими, выводя на экран дисплея графики тех и других. III.Желательно, чтобы все величины, используемые программой были выражены в одной системе единиц. Постоянный перевод единиц из одной системы в другую в разных местах программы и использование внесистемных единиц измерения часто становится для программиста настоящим бедствием и может стать источником многочисленных ошибок. Поэтому такой перевод желательно производить только один раз, при считывании входных данных (и возможно второй, при выводе результатов). Иногда можно рекомендовать написание программы в обезразмеренных переменных. IV.Везде, где возможно при отладке следует использовать объективный контроль. При проверке правильности записи громоздких конечно- разностных выражений чрезвычайно полезно проверить результаты численного дифференцирования, подставив в качестве решения пробные функции и сравнив с результатом, полученным аналитически. Прежде всего, это позволит проверить наличие аппроксимации. Однако значение такого теста глубже: это почти гарантия, что конечно-разностный оператор запрограммирован правильно, так, как предполагалось в конечно-разностной схеме. При написании каких-либо вспомогательных процедур всегда, когда это возможно, их следует оттестировать отдельно. Например, процедуры прогонок или алгоритм Гаусса решения системы линейных уравнений можно проверить на модельных системах линейных уравнений сравнением полученного решения с точным.
Страницы
- « первая
- ‹ предыдущая
- …
- 39
- 40
- 41
- 42
- 43
- …
- следующая ›
- последняя »