「理想の究極のプログラミング」は、何もせずに目的のプログラムができることですが、そのような都合の良い話は無く、どこかで妥協しなければなりません。
しかしながら、理想を求めて妥協するのと、求めなくて妥協するのでは、その結果には大きな違いが生まれます。
1位を目指さなければ、2位はおろか上位に入ることすら難しいのはご存じだと思います。
(2023/05/03 タイトル画像を変更)
目次
究極のプログラミングとは
諸説あるとは思いますが、以下は、会社の入社当初(約30年前)に、「先輩に読んでおけ」と渡された書籍か雑誌に書かれていたものが元です。
究極のプログラミングとは、「プログラムをできるだけ作らない(コーディングしない)こと」である。
これは至極当然です、何もプログラムを作らずに目的が果たせるのであれば、こんなに楽なことはありません。
逆に0から10まですべてを作っていたら、設計/開発(環境構築含め)工数が掛かる、テスト/検証工数が掛かる、作ったものの運用などにも工数が掛かるなど、時間とお金が多く掛かるのはご存じだと思います。
よく「開発費数億円」って話は聞くと思いますが、プロダクトライフコスト(製品寿命までの費用)を見た時、世に出してからの運用(メンテナンス/保守/アップデート/アップグレードなど含む)の方の費用が高い場合が多いことをご存じの方も多いと思います。
また、不良の一部はコーディング時に作りこんでしまっていると言うことも重要です。
不良を含む不具合の対策には高額な費用が掛かる場合があります。
最初からコーディングしなければ、それらの不良を作りこむことはありません。
「理想の究極のプログラミング」は、何もせずに目的のプログラムができることですが、そのような都合の良い話は無く、どこかで妥協しなければなりません。
しかしながら、理想を求めて妥協するのと、求めなくて妥協するのでは、その結果には大きな違いが生まれます。
1位を目指さなければ、2位はおろか上位に入ることすら難しいのはご存じだと思います。
「プログラムをできるだけ作らない(コーディングしない)こと」とは、「既にあるものを最大限に活用しよう」と言うことです。
先人たちが作ったものは、工数(時間とお金など)をかけて作りだされたものです。
それを組み合わせて、目的を達成できるのならそれが一番良いことです。
世の中に無いものは作るしかありませんが、既に存在する場合は先人たちが作ったものと同じレベルのものを短期間に安価でできるなら自分たちで作っても良いと思います。
しかし、本当に先人たちが作ったもののレベルに達するのは難しいことが多いでしょう。
先人たちが作ったものが有料でも、原価計算した結果、自分たちで作るより安いのであれば、買ってでも使った方が良いです。
なお、本サイトの名前は「プログラミングの深淵を求めて」ですが、これは「理想の究極のプログラミング(何も作らない)に少しでも近づくため、その深淵を求める」と言う意味があります。
「コラッツ予想のからくり」での適用例
実施検証環境の目標
筆者は、コラッツ予想の証明の論理を公開するだけではダメで、何らかの実施検証可能な環境も必要と当初から考えていました。
実施検証環境を作るにあたって次の目標を定めました。
- 開発時にできるだけお金をかけない/かからないようにする
- 単に数値を並べるのではなく色付する
- 無償公開する
(注)知的財産権は放棄していません。
参照/利用は無償ですが、自由にして良いわけではありません。
This site is free, but not freedom.
ツールの演算精度(計算精度)の制限問題
コラッツ数列を求めるツールとして、簡易確認用のExcel版と本格確認用のJavascript(BigInt)版を作りました。
簡易確認用Excel版は48bitの演算精度で作った、ある意味プロトタイプ版であり、本格確認用で必要となる演算精度などのリソースを見極める目的で作りました。
Excelで作った理由は、単に数値を並べるだけではなく、色分けも同時にしたかったからです。
Excelの「条件付き書式」を使えば、セル内の値によって文字色や背景色を変えるなんてことは簡単です。
余談ですが、問題は「条件付き書式」の存在すら知らない人が多いらしく、あまり使われて無いためなのか、モーダル形式のダイアログ(ダイアログ表示中はメインのセルにアクセスできない)で設定項目が表示されるため、微調整に手間が掛かり、とても使い辛いものなのであり、25年ぐらい改善されていません。
昔は、「図形の書式設定」もモーダル形式のダイアログであり同様の使い辛いものだったのですが、現在は右側などの領域に図形のプロパティを表示させて実際に図形の変化を見ながらの微調整が容易になっています。
「条件付き書式」でも、同じような改善をしてほしいところです。
話を戻して、私の閃いた論理が正しいかの道筋(からくり)を示しただけでは、絵に描いた餅だと思われてしまうだろうこと、「本格確認版」を作るための時間稼ぎをすること、これらためにプロトタイプ版を「簡易確認用Excel版」として先行公開しました。(だから最初から「簡易確認用」として公開してます)
コラッツ予想で扱う数値は、無限に存在する正の整数です。
しかしながら、コンピュータのリソースは限られおりどこかで妥協が必要です。
簡易確認用Excel版の利用により、本格確認用で必要なリソース(演算精度など)の目途を付けました。
例えば、C言語などの特定のプログラミング言語を使って、四則演算を1Kbit(1024bit)とかでシミュレーションするものを作るのはそれほど難しいものではありません(PCやスマホの現在のネイティブな演算精度は64bitです)。
しかし、ものを作ると言うことは責任が伴います。
対象の処理が簡単と思えるからこそ、問題が発生したときの対策が難しい場合があります。
例えば、一定の手順で実行した時のみ問題が発生するが、その一定の手順が複雑で、その手順の特定と原因追及に膨大な時間がかかるなどがあります。
また、閃いた論理が正しいか確認する上でも、自分でコーディングしてしまうとそこに上記のような問題が入るスキを作ってしまいます。
自分でコーディングしなければ、そこに不良を作りこむこともありません。
数学のコラッツ予想自体もこれに似ています。
式自体は簡単なのにその証明が約80年以上されていませんでした。
対象が簡単だからと言ってなめていたら、斜め上の問題が発生して対策に苦労するなんて話はプログラミングの世界でもよくあることです。
このため、本格確認用では、四則演算のシミュレーションを自分で作るのは最悪のケースと考え、既に存在するものがないかを徹底的に探しました。
結果、「JavascriptのBigIntの限界値を探る」で示しましたが、Webブラウザの種類により、1Mbit(約100万bit)や1Gbit(約10億bit)の演算精度があるJavascriptのBigInt(Int=Integer型=整数型であり浮動小数点型ではない)にたどり着きました。
これは、有効桁数が2進数でそれぞれ約100万桁と約10億桁、10進数で約30万桁と約3億桁と言う天文学的数値すら可愛く見えるのでは?と言う数値を1の位まで正しく扱える整数演算が可能なものです。
これらは、各Webブラウザの提供元が動作保証しているものであり、不具合が見つかれば、レポートを出して修正してもらえば良いです。
演算精度を上げるために自分でこのようなものを作ってしまうと、予想の斜め上の問題が発生してしまい、目的と手段が入れ替わってしまう要因になりかねません。
また、ビジュアル的な色分けにJavascript(jQuery)を使う予定だったので、BigIntがJavascriptで実装されていたことで、表示部分と演算部分を分ける必要が無くなり、とても幸運でした。
さらに、SpiderMonkeyエンジン(FireFox)と、V8エンジン(Chrome系)の複数の実装の違うJavascriptエンジンがあったことも幸運でした。
複数のエンジンで実行して同じ結果が得られれば、それは私が作ったプログラムの正当性が高いことを簡単に検証できる手段になります。
結果が違えば、作ったプログラム側の問題なのか、Javascriptエンジン側の問題なのかの切り分けの助けになります。
これにより、本格確認用のJavascript(BigInt)版は初版(Rev.1)リリース後、メンテナンスは一度も行っていません。
つまりメンテナンス費用は皆無であり、究極のプログラミングによるプロダクトライフコストの削減を実践できていると自負しています。
天文学的数値やそれ以上の数値にはBigIntがお勧め
当方で動作確認はしていませんが、サーバーサイドでJavascriptを利用するのがNode.jsです。
これは、JavascriptエンジンにV8エンジンを利用しているため、BigIntを1Gbitの演算精度で利用できると思います。
ちにみに、あまり利用されてないと思いますがWindowsのコマンドプロンプトでJavascript(.jsの拡張子)のファイルを実行できます。
執筆時点でEgdeがChromiumベース(V8エンジン)のものになっていますが、コマンドプロンプトで実行できるJavascriptでは、BigInt他(const記述など)が利用できない古いJavascriptエンジンのままのようです。
天文学的数値やそれ以上の数値を上位の桁から1の位の桁まで正確に扱いたい方は、WebブラウザやNode.jsのJavascriptのBigIntの利用を検討してみてはいかがでしょうか?
最後に
もし1990年代後半にコラッツ予想に出会っていたとして、当時筆者が知っているテクニックしか利用していないため、同じ「閃き」をして同じ「道筋(からくり)」の論理を導きだせただろうと思います。
しかし、当時はExcelよりWordで仕様書を書いていた方が多いし、Javascriptは有ってもBigIntは提供されていません(BigIntが追加されたのは執筆時点から数年前のはず)。
当時何らかの形で論理を公開したとしても「絵に描いた餅」や「机上の空論」と言われたかもしれません。
2021/7/7にコラッツ予想に出会ったからこそ、簡易確認用のExcel版が作れ、本格確認用のブラウザ(BigInt)版が作れたのだと思います。
スパコンで10の20桁ぐらい(2の68乗ぐらい)まで確認しましたとか言われても「ふ～ん」で雲の上の話でしょう?
多くの人が日常的に利用しているWebブラウザ上だけで実際に動いて実際に検証可能なものが作れたのはとても幸運だと思います。
また、Javascriptで作ったプログラムソースコードは難読化もしておらず、オープンで透明性がある(なにも隠し事がない)ものです。
まとめとして、前回の「プログラミングテクニック アルゴリズム＋データ構造=プログラム」と合わせて以下をアドバイスさせていただきます。
- 目的と手段が入れ替わらない(軸がブレない)ように注意を払おう。
- 情報をデータに昇華したとき、処理結果はそのままで良いのか、元の情報と同じレベルに戻すべきなのかに注意を払おう。
- プロダクトライフコストの削減を意識しよう。
- プログラムをできるだけ作らない(コーディングしない)こと、既にあるものを最大限に活用しよう。
何かの参考になれば幸いです。
ご意見、ご要望、不具合などのご連絡
ご意見、ご要望、不具合などのご連絡は次からお願いします。
- コメント
本投稿へ下部の コメントを書き込む からご連絡ください。
コメントは承認方式となっており、当方が承認しないと公開表示されません。
公開表示を希望されない方はその旨コメントに記述ください。 - Twitter
ご連絡は @dratech2020 https://twitter.com/dratech2020 の該当ツイートに返信するか、ハッシュタグ「#プログラミングの深淵を求めて」を付けてツイートしてください。 (すぐに気が付かない場合がありますので、ご了承ください)
関連投稿
(2023/05/03 リンクの表示方法を変更)
コメント