数値計算課題に関する注意
鳥取大学工学部 応用数理工学科 学部生向け資料
[数値計算のページに戻る]
- このプログラムでは、どういう方程式を解いているのか?
- プログラムを書いている最中はともかく、
何ヶ月かたつと何の式か完全に忘れてしまい、
「あれ、このプログラムって何だっけ?」となることが多い。
予防策として、方程式を、プログラム中に
コメント文の形で書いておくべきである。
(複雑な式の場合は、TeXファイルを作っておき、
プログラム中に「
***.tex を参照
」と書いておく。)
方程式についてのコメントは、変数の説明も兼ねるようにする。
- 数値計算しやすいように方程式を書き直す
- 無次元化の際に、
基準量を適切に選ぶようにする。
課題プログラムの実例と講評
- まちがいプログラム! (2000年)
- 他人が作ったプログラムを、内容を理解せずに信用してはいけない。
- 2002年10月の課題: コメント
- 実例(1-5)とコメントを比較してみよう。
悪いプログラム
- バグがある。
- 汎用性に欠ける。
- 初期条件がプログラム中に書いてある。
- 出力ファイル名がプログラム中に書いてある。
- 数式にカッコがない(間違って解釈される)。
- 入力メッセージと変数名が食い違っている。
いかにもバグのありそうなプログラム
読みにくいプログラムは、バグの温床です。
- 字下げが適切でない。
- 空行がまったくない。 または、空行がやたらに多い(「1行おき」とか)。
- 等号の前後に空白がない。
- 式が無意味に長い。
- コメント(注釈)がほしくなる。 または、コメントがやたらに多い。
- コメントと実際の内容が食い違っている。
- ものすごく長いプログラムなのに、サブルーチンがひとつもない。
- 同じことを何度も書いている。 (これは本当にバグのもとになる!)
FORTRAN77の危険なところ
- 暗黙の型宣言 (
implicit なんとか
)
- 必ず
implicit none
を使うように。
「implicit double precision
」などというのは過去の遺物。
- 大文字と小文字は区別されない
- もし
u
を使ったら、
別の変数として U
を使うことはできない。
なぜなら、u
と U
は
FORTRAN77にとっては同じものだからだ。
- 行番号はバグのもと
-
do
... enddo
などの
制御構造を活用して、
行番号なしのプログラムを書くようにする。
- グラフだけ提出してもだめ!
本文を書くこと。 特に、次のような点を説明する:
- このグラフはどうやって得たのか?
- 縦軸や横軸は何を示しているのか?
- このグラフから何が分かるのか?
- 数値計算には、つねに誤差がある。
その誤差がどれくらいの大きさかを
知っておくことが大切である。 (結果を鵜のみにするのも、
逆に何でも数値誤差のせいにするのも、どちらも間違っている。)
たとえば、Δt を 半分(または1/10)にして、
同じ初期条件で計算してみる。
結果がほとんど変わらないようなら、誤差は少ないと思ってよい。
- 数値計算の結果が正しいかどうかを、
考えられる限りの方法でチェックする。
- 数値計算の結果を、
手計算で得られる解(厳密解や近似解)と比較する。
- 摩擦のない系の場合は、
エネルギーが保存していることを確認する。
摩擦がある場合は、エネルギーが正しく減っていることを確認する。
- 常微分方程式の数値解と厳密解を比較せよという場合、
GNUPLOTで両方を重ねて図示し、両者の食い違いについて検討する。
- 食い違いは 時間とともに どう変化しているか?
最初から合わないのか、時間とともに合わなくなってくるのか?
- 『値が一致しているかどうか』だけでなく、
『微分(グラフの傾き)が一致しているかどうか』も見る。
- 言うまでもないことだが、
文字化けしたレポートを提出してはいけない。
[数値計算のページに戻る]