🍈超越コボラーの逆襲２〜おまけ付き

sphiarno-88
2022/02/10 04:08

🍓前書き

前回、グラフ理論からの脱線としてＣＯＢＯＬの有効性を、別のプログラムとベンチして検証することをやりました。しかし、勝利できたのがＳＣＲＡＴＣＨだけと、これは「超越コボラー」としては不甲斐ない成果となりました。

なお、お断りをしておきますが、「超越」とはなにもコボラーとしての卓越した技術という趣旨を持って述べたものではなく、コラッツ予想に取り組んだ結果、「超越数」であるネイピア数ｅと相当因果関係がありそうだ、という趣旨であります。要約すれば「中二病」ということです。

いずれにしても、このままでは終われない。打開策を練って、第二の反撃を行います。

🍌ええい！しからば…！！

まずは、今回のＣＯＢＯＬ結果報告です。

ＵＳＥＲ　ＴＩＭＥ：　１１３ｍｓ

これは、前回の結果から速度が７０倍程度向上しており、Ｃと比較しても勝らずとも劣らない成果をあげています。下のＵＳＥＲタイムが、以前のものの結果です。最初がＣＯＢＯＬで、後がＣです。

言語：　ＵＳＥＲ　ＴＩＭＥ
（以前のもの）
ＣＯＢＯＬ：　７８２１ｍｓ
Ｃ　　　　：　　　７６ｍｓ
（今回のもの）
ＣＯＢＯＬ：　　１１３ｍｓ

ヒントが見えてるのでなんなのですが、これは苦手なとこだけＣを利用してＣＯＢＯＬに埋め込んだものです。偽り看板ＣＯＢＯＬのその中身はＣということです。おまけにいえば、ＧＮＵ（ＯＰＥＮ）ＣＯＢＯＬはそれ自体がＣです。

方法は、まず前回のＣのコラッツプログラムをライブラリー形式にします。具体的には呼び出し名称（ここではｃｏｌｌａｔｚ）を確認し、実行プログラム：ｍａｉｎを削除します。

unsigned long collatz(unsigned long n);

ＣＯＢＯＬ側でコールコマンドを記述します。

&gt;&gt;D    DISPLAY "WK_I: " WK_I
   CALL 'collatz' USING BY VALUE WK_I RETURNING RTC
&gt;&gt;D    DISPLAY "RTC: " RTC

Ｃプログラムと一緒にコンパイルします。

cobc -x -free collatz_c.cob collatz_cob.c
time ./collatz_c

この結果が最上図になります。

🍎よく分からない仕様

そもそもＣＯＢＯＬもＣなので、と言われればそうなのですが、とりあえずＣと同等の高速性能を引き出して面目躍如といったところです。しかし、どうも腑に落ちない。今度は、単に１を連続的に加えて出力する方法でベンチマークしてみます。

プログラムごとの時間計測方法に？な部分があるので、可能な限り外部からも時間計測してみます。

まず、ＣＯＢＯＬです。

cobc -x -free cobbench.cob
time ./cobbench

次は、Ｃです。

gcc cobbench.c -o cobbench_c
time ./cobbench_c

最後に、ＣＯＢＯＬの比較対象とされやすいＪａｖａです。

javac.exe Egg/CobBench.java
java Egg.CobBench

＊　結果：　内部計測時間：外部計測時間（ＵＳＥＲ）：総時間（ＲＥＡＬ）　
ＣＯＢＯＬ：　　　３８ｍｓ：　　１４０ｍｓ：　４０３ｍｓ
Ｃ　　　　：　　１８２ｍｓ：　　　５９ｍｓ：　３２４ｍｓ
Ｊａｖａ　：　５２９７ｍｓ：　　　　？ｍｓ：　　　？ｍｓ

コンパイル時間は考慮してませんが、総時間がＣと大差がないので比較的高速に見えます。そして、Ｊａｖａに対しては圧倒的に高速にも「見え」ます。

しかし、このプログラム（の企画）自体が株式会社ＣＯＢＯＬというところによってなされているものであり、自社広告を含んだインチキ・トリックなプログラム（計画）である可能性があります。

そこで、コマンドラインへの出力をなくしてみます。最適化させないため入力を不定値にもしましたが、結果はほぼ同じでしたので省略します。

まず、ＣＯＢＯＬです。

PROCEDURE                       DIVISION.
  ACCEPT STIME FROM TIME.
  PERFORM UNTIL CNT = 100000
    ADD 1 TO CNT
*&gt;    DISPLAY CNT" TIMES EXECUTION."
  END-PERFORM.

Ｃです。

  do {
    i++;
    // printf("%7d times execution.\n", i);
  } while (i &lt; NUMBER);

Ｊａｖａです。

   // loop
   while (i &lt; len) {
     i = i + 1;
     num = num + i;
     sum = sum + num;
     // System.out.println(i + "time's execution.");
   }

Ｊａｖａも外部時間計測してみました。

pwsh.exe
Measure-Command {java Egg.CobBench}

＊　結果：　内部計測時間：　外部計測時間（計）
ＣＯＢＯＬ：　　　　２ｍｓ：　　　４８ｍｓ
Ｃ　　　　：　　　６８ｍｓ：　　　　４ｍｓ
Ｊａｖａ　：　　　　０ｍｓ：　　１４１ｍｓ

残念ながら、この結果から分かることは何もありませんが、外部計測時間は実際の感覚に近いものでした。ひょっとしたらＪａｖａの方は、いやらしい背景画像と怪しげなテキストの光が、Ｊａｖａを固くさせて？動きにくくしているのかもしれません…（実際には株式会社ＣＯＢＯＬの測定結果と同程度でした）

１６進数を１０進数に直して表示する、というところにＪａｖａとＣＯＢＯＬのなにがしの差異はあるかもしれません。ＢＣＤ：バイト１０進数なら、データを余分な計算をせずに直接変換できます。数値も含めたテキストのファイル処理が得意、というのはそういうところにあるのでしょう。

ＣＯＢＯＬがＪａｖａに対して高速に「見える」というのは、テキスト出力に対するそうした含みを持たせた表現ですが、どうせなら、いやらしい背景画像からも見えてはいけないナニカが「見えて」くれ…

（昔のそっち系は、傾けたらちょっと「見える」とか、暗がりで観測すれば「見える」とか、そんな精神修行でした…そもそもパーソナルコンピュータはそういう用途のためのマシンだった…らしい）

🍊おまけ

先日、ＥＸＣＥＬでＬＡＭＢＤＡ関数が一般公開されたとのことでしたので、ＥＸＣＥＬでもコラッツ予想をやってみました。

簡単に図にできるところはＥＸＣＥＬのメリットですね。

収束状況もとらえてみました。ただ、ビューが大きくなりがちなので面白みに欠けます。

方法は次のようにします。

ＬＡＭＢＤＡ関数の作成方法：
①数式を選択。
②名前の管理を選択。
③新規作成を選択。
④名前（任意）欄にＣｏｌｌａｔｚと入力。
⑤参照範囲のところに以下を入力。
=LAMBDA(x, IF(x=1, 1, IF(MOD(x, 2)=0, (Collatz(x/2)+1), (Collatz(x*3+1))+1)))

呼び出し側のセルでは、

=Collatz(&lt;任意のナンバーまたはセル＞)

ないし、

=MAP(&lt;任意のナンバーまたはセルまたはアレイ＞, Collatz)

とすれば出力できます。

また、コラッツ予想の次の数を求めるものも作ってみました。名前はＣＯＬ＿ＮＥＸＴなどとすればよいでしょう。

=LAMBDA(x, IF(MOD(x, 2)=0, x/2, x*3+1))

これと同じことは、ＬＡＭＢＤＡ関数以外のこれまでのものでも同様にできますが、ＬＡＭＢＤＡ関数以外の方法を応用して表から作成しようとすると、思わぬ罠にはまります。ステップ不定性の問題です。例えば、次のような式を考えます。

=IF(MOD(ROW(), 2)=0,INDIRECT(ADDRESS(ROW()/2, COLUMN()))+1, INDIRECT(ADDRESS(ROW()*3+1, COLUMN()))+1)

これはアドレス変更不可のモデルではありますが、工夫をすればそこは問題なくなります。問題は、この方法は調査範囲が十分でないと、ときどき嘘つきマシンとして動作する、ということです。下図のようになります。

一番左のインデックスが入力値、Ａがステップ数、Ｂは初めて本当の答えを導き出した回、Ｃ以降（Ｃは１回目）は探索範囲を２＾ｎとして上記式（ただし、入力が１のときは１）を当てはめた答えです。

どこまで調べたらどのようなことが説明（証明）できるのか、というのは二重否定の除去を許さない直観主義論理と深い関わりがあります。自己を超越した次の世界において初めて現世界の自己を説明できるかどうか、という可能性が、コラッツ予想を困難にしている問題ともいえそうです。

式内で処理するためには、式中にスタックを適切に処理できる能力がなければなりません。スタックを、積んで、リエントリーして、下ろして、リターンして、最後のスタックのリターンが戻り値（結果）です。このスタックを仮想的に存在させられる方法が、エクセルのＬＡＭＢＤＡ関数というわけです。ＢＲＡＩＮ＿ＦＵＣＫ同等のスタックマシンが十分に期待できるので、ここでチューリング完全ということになります。

話は変わりますが、ＥＸＣＥＬはプログラミング言語かどうか、という話題があります。ひとつ面白い考察を与えてみましょう。

上記の式は、若側から順番に計算しただけならば、計算を終えない部分が残ります。しかし、使用しているコンピュータや環境にもよりますが、リンク先に更新があった場合は再度計算し、新しい値を返します。もし、セルのひとつひとつが、内部の入力から出力を画面に返す関数とすれば、エクセルは「非同期、かつ、セルの数だけ生成されたマルチスレッド、および、マルチチャンネルのプログラム」といえるのではないでしょうか。上記の「嘘つきマシン」は、これは１０２４になるまでやってみましたが、それぞれのセルが何度もの更新を感知・取得し、再計算しては更新し…の過程を自動で行ったものです。

話を戻しましょう。ＥＸＣＥＬの場合、ＬＡＭＢＤＡ関数を受け取れる関数は多くはありません。配列から配列を取り出すＢＹＲＯＷ関数を使用してみます。