図・表・アルゴリズムなど

アルゴリズムの表現

図・表・アルゴリズムなど

アルゴリズムの表現

いきなり...

次に記したものはよく引き合いに出される閏年の判定基準を記したものである． 言うまでもないが，これは天文学的な一年 (地球の自転軸と太陽の位置関係が同じになるという) が，約365.24218987日であることからカレンダーを時々修正する基準である．

グレゴリオ暦による閏年の判定方法: 西暦年が 4 で割り切れる年は閏年 ただし，西暦年が 100 で割り切れる年は平年 ただし，西暦年が 400 で割り切れる年は閏年

さて，この表記を見て気になったのは私だけだろうか...ここで西暦年を y としよう．

• y=2010 だったら，1, 2, 3 どれにも合致しないので平年でも閏年ではない (??)
• y=2012 だったら，1 のみに合致するので閏年
• y=2100 だったら，1 にも 2 にも合致するので結局，平年なの? 閏年なの (??)
• y=2000 だったら，1 にも 2 にも 3 にも合致するので結局，平年なの? 閏年なの (??)

何が言いたいのか，というと...

この判定基準では 1, 2, 3 の順に条件を評価し， どこかで条件が合致してもそこで確定できず，最後まで条件と照らし合わせて，最後の適合条件が適用される，ということ． さらに，どの条件にも合致しなかったら平年である，ということ，が暗黙の前提となっているのである． 果たしてこのような暗黙の了解は普遍性があるのだろうか?

私は「否」である． これとは逆に上から順に条件を評価し，条件が合致したところで状態が確定する，という判定記述はいくらでもみられる． また，列挙された各条件に順序的依存関係がない記述法も多く見られる． さらにはこれらが混淆したものすらある． 「ただし」ほど紛らわしい表現はないと思う． さらに，「番号」があるから，というのもそれによって読者が順に評価すると理解する保証にはならないのである．

余談ではあるが，プログラミングに向く人と向かない人がいること， (特定の簡易言語での)プログラミングが一応できる自称プログラマでも，構造化とか宣言型・関数型・論理型とかになるといきなり挫折する人がいるのはこのあたり (思い込み and/or 押し付け) に根源があるのかもしれない．

もちろん，

• y=2010 だったら，1, 2, 3 どれにも合致しないので平年
• y=2012 だったら，1 に合致するが，2, 3 に合致しないので平年
• y=2100 だったら，1 と 2にも合致するが 3 には合致しないので平年
• y=2000 だったら，1 に合致するが，2にも合致し，3にも合致するから結局閏年

ここで示したことは，処理手順，アルゴリズムを「文章」で表現する際の非常に大きな問題点なのである． 情報科学系の論文であれば，処理手順やアルゴリズムは Pascal で書いてしまえ， という最終兵器があるが，他の分野ではままならないであろう． 読者に行間を読ませず，憶測させずに正しい理解がされるような記述が必要なのである．

文章の有用性と脆弱性

定式化

数式の利用

アルゴリズム表現言語