「アルゴリズム＋データ構造=プログラム」つまりプログラムは、アルゴリズムとデータ構造を組み合わせたものである。
Niklaus Wirth(ニクラウス・ヴィルト)先生が1975年著書の日本語訳版のタイトルです。
(2023/05/03 タイトル画像を変更)
プログラムとは
「アルゴリズム＋データ構造=プログラム」と言うことで、書籍にはソート(クリックソートやバブルソートなど)や再帰呼び出し(リカーシブコール:エイトクイーン問題など)、他の例が示されています。
これは以前所属していた会社内学校の情報科で教科書として使われていたものです。
この書籍では、Pascalと言うプログラミング言語を用いてプログラムソースコードの例を示していますが、これを他のプログラミング言語(C言語など)に移植するのは難しくありません。
「アルゴリズム＋データ構造」さえしっかり理解できれば、プログラミング言語はその時々で最適なものを利用すれば良いのです。
プログラムは、「アルゴリズム＋データ構造」を実現する/したものであり、プログラミング言語はその目的を果たすための手段に過ぎないと言えます。
プログラミング言語とは
「プログラミング言語」と言う名前がついていますが、これらで作れるものは「プログラムソースコード(プログラムの元となる命令/命令群)」であり、これを作る作業のことを「コーディング」と言います。
「プログラムソースコード」では長いので、「ソースコード」や「ソース」と略されます。
話の流れで「コード」と略すこともありますが、「コード」はコンピューター関係の用語として、他にも多く使われることもあり、いきなり「コード」と言っても「何のコード?」となってしまうので注意が必要です。
昔、まだプログラムが小規模/簡単だった時代では「プログラミング」＝「コーディング」であることは多かったですが、現在の大規模化/複雑化した時代では「プログラミング」＞「コーディング」であり、「プログラミング」＝「コーディング」となるケースは少なくなっています。
これは、「プログラミング言語」を習得しても「コーディング」ができるようになったことであり、別に「プログラミング」ができることを表しているとは限らないことを表しています。
さらにプログラム(アルゴリズム＋データ構造)ですら、さらに上位の目的を果たすための手段でしかありません。
真の目的は、顧客満足度を向上するだとか、論理だけ示しても絵に描いた餅の可能性があるので実施例として示すとかなど、その時々の要件を満たすことです。
顧客が何をもって満足するかは、対象の顧客によりさまざまです。
アルゴリズムもこの世の中に無数に存在し、それを定量的に評価し言い表すことは難しいです。
このため、プログラムの要件定義で、依頼主である顧客と綿密な打ち合わせを行い、どのアルゴリズム(とデータ構造)を使うか、その組み合わせでどのような効果が出るのか、などを決めていき、設計します。
このアルゴリズムの集まりの設計をアーキテクチャと言い、これを作成する人をシステムアーキテクトとかソフトウェアアーキテクトと言います。
プログラミングの求職の条件などで、「XXXのアルゴリズムが使えますか?」と言ってもアルゴリズムは無数にあり、特に名前もついてない場合もあるのでうまく伝わりません。
プログラミング言語の種類は、アルゴリズムの種類より遥かに少ないため「XXXのプログラミング言語が使えますか?」と言った方が応募しやすくなります。
しかし、それは目的と手段の位置づけが入れ替わってないか(軸ブレしてないか)注意するが必要があります。
当サイトは「プログラミングの深淵を求めて」と言う名前を名乗っていますが、プログラミング言語(コーディング)の種類に捕らわれた記事は、ほとんど存在していないはずです。
アルゴリズム(とデータ構造)もプログラミング言語もその時々で、最適なものを選べば良いのです。
本サイトの投稿記事の公開方法がWebベースであるため、Javascriptの比率が多いのはそれが最適だからです。
プログラム(アルゴリズム＋データ構造)が真の目的(顧客満足度など)を実現するための手段であり、そのプログラムを具体的に記述(コーディング)するためにプログラミング言語を使うのであり、目的と手段が入れ替わらないように注意を払っているつもりです。
もちろん、目的を達成するために扱うことができる手段(アルゴリズムやプログラム言語)の種類は多いに越したことはありませんが、手段を目的にしてしまっては無いか? を常に考えるようにしています。
多くのプログラミング言語は地球語
少々、余談ですが。
「多くのプログラミング言語は、所詮、地球語です。LISPは火星語ぐらい概念が違う。」と言うような言葉がありました。
これは、30年ぐらい前のコンピューター関係の雑誌に書かれていたものです。
多くのプログラミング言語は英単語と数式の組み合わせであり、プログラミング言語の種類により特徴や癖がありますが地球語の範疇であることが理解できます。
LISPと言う言語の説明は省略しますが、火星語と例えられるぐらい概念が違います。
このため、いくつかの地球語に属するプログラミング言語を「使いこなす」レベルで習得していれば、新しい言語でもすぐに扱えるようになります。
もちろん、新しい言語でも「使いこなす」レベルに達するには数か月かかるかもしれませんが、その程度です。
なお、SQLは、データの集合(=データベース)を扱うもので、プログラミング言語とは少し違いますが、地球語と火星語の間ぐらいでしょうか?
コラッツ予想のからくりでの適用例
コラッツ予想のからくりでは、簡易確認用ツールとしてExcelのマクロ関数のみ(VBAは不使用)で作りましたが、そこには「アルゴリズム＋データ構造」があり、このツールもプログラムと言えます。
このツールは簡易確認用として公開していますが、ある意味プロトタイプ版です。
真の目的を満たすためのプログラムで処理したい対象がどのようなものかを調べるために簡易的に作ったものです。
コラッツ予想の式は簡単なものでありアルゴリズムも簡単です。
問題はデータ(データ構造)の方で、無限に存在する正の整数が対象です。
ただし、このツールは簡易版のこともあり制限が厳しいです。
Excelで扱える数値の制限(マクロ関数毎に制限が違って苦労しました)により48bitの計算精度で作成しましたが、検証する過程で導き出したコラッツ予想KAI(2進数で見た時に見やすく矯正する式)から、元の値nが48bitの範囲内の計算精度でも、KAIの式で必要な計算精度は最低でも300bit以上の計算精度が必要なことがわかりました。
このため、本格確認用にさらに大きい値、512bit以上、できれば1024bit(1Kbit)や2048bit(2Kbit)の計算精度がある環境が必要であることが判明しました(この話の続きは プログラミングテクニック 究極のプログラミングでプロダクトライフコストを削減する を参照ください2023/03/23追記)。
また、コラッツ予想のからくりでは、「うまく計算リソースから除外」と言う言葉を使っています。
現在のコンピューターのリソースは有限(ネイティブな計算精度は64bitなど)です。
このため、解決したい問題や実現したい問題そのものをそのまま扱えることは少なく、モデル化して扱うことが多いです。
IT(Information Technology:情報技術)やICT(Information and Communication Technology:情報通信技術)は、Information=情報を扱う技術ですが、コンピューターで「情報そのもの」を扱えるケースは少ないです。
現実世界で「知識を知恵に変える」のような言葉があるように、コンピューターでは「情報をデータに変える」必要があります。
情報をコンピューターが扱えるリソースの範囲内のデータに昇華して、そのデータを処理し結果を求めます。
逆に情報を劣化させたデータにしてしまうと、さまざまな問題/不具合が発生してしまうので、昇華できているのかは常に注意が必要です。
このデータへの昇華のことをモデル化とか簡略化などと呼びます。
処理した結果は、モデル化したままのデータで出力しても良い場合もありますが、モデル化したデータを元の情報のレベルへ戻さなければならない場合があります。
戻さなければないないものをそのまま出力してしまうと、「なんだこれ?」となってしまうのは明らかです。
例えば、234,000と言う数値があったとき、234Kや234千などと表したりします。
これを3倍するとき、計算は234×3=702となりますが、この702をそのまま結果としてしまうとダメですよね?
702,000や702Kや702千など、元の情報のレベルに戻さなければ結果としては間違いです。
コラッツ予想の式は奇数時と偶数時の式を無限に繰り返すだけであり、偶数時の式で「うまく計算リソースから除外」＝簡略化を繰り返しています。
簡略化したデータを元の情報のレベルへ戻す部分が無いのです。
このため、コラッツ予想の式自体は簡単なのに、それから得られる数列が不思議に見える要因の１つになっています。
また、この簡略化が2進数の世界で発生しているので、普段10進数を使う我々は余計に不思議に見えてしまいます。
コラッツ予想KAIでは、このモデル化(簡略化)すると言う部分を機能しないように元の情報のレベルへ戻す矯正をしたにすぎません。(2023/05/03画像追記)
ちなみに、「2進数に馴染みがない」と言う人がいるかもしれませんが、PCやスマホに代表されるデジタル機器の内部は、ほぼすべてを2進数で処理しています。
これらのデジタル機器は、2進数で処理している素振りを見せないように人間が理解しやすいように表面上見せているだけです。
馴染みが無いのではなく、相手(デジタル機器)の本質を知ろうとしていないだけです。
「プログラミング」＝「デジタル機器を操作するプログラムを作ること」において相手(デジタル機器)の本質(2進数)を理解せずに的確に扱うことは難しいのです。
別のプログラミングにおいても、モデル化(簡略化)が正しく機能しているか、矯正したデータと照らし合わせる(テスト/検証する)ことで「劣化データになっていないか」、「モデル化によりデータを昇華できているか」を確認することはよくあることです。
最後に
「プログラム」や「プログラミング言語」や「コーディング」の明確な定義は諸説あると思いますが、本サイトでの利用は、本稿のように定義しています。
また、プログラミングでは「情報をデータに変える(昇華する)」必要があること、得られる結果は「元の情報のレベルへ戻す」必要があるのかどうなのかを常に心がけてください。
何かの参考になれば幸いです。
ご意見、ご要望、不具合などのご連絡
ご意見、ご要望、不具合などのご連絡は次からお願いします。
- コメント
本投稿へ下部の コメントを書き込む からご連絡ください。
コメントは承認方式となっており、当方が承認しないと公開表示されません。
公開表示を希望されない方はその旨コメントに記述ください。 - Twitter
ご連絡は @dratech2020 https://twitter.com/dratech2020 の該当ツイートに返信するか、ハッシュタグ「#プログラミングの深淵を求めて」を付けてツイートしてください。 (すぐに気が付かない場合がありますので、ご了承ください)
関連投稿
(2023/05/03 リンクの表示方法を変更)
コメント