ゼルコバの木テント村

Count Per Day を長い間使ってきたが，2019年からはWordPressの「ガイドライン違反」でWordPressのプラグインページからダウンロードできないようになっている．Count Per Day の公式サイトからはいまでもダウンロード可能だが，Count Per Day はコードを修正するつもりはないようで，「ガイドライン違反」の状態が続いている．テント村では代替品としてLive Visitor Counterというのを使い始めたのだが，どうもいまいちだ．①カウントが過大に思われる，②前日訪問者数が出ない．カウントが過大というのはおそらくロボットを除外していないためと思われるので，概数を引き算してやればよいというだけだが，前日訪問者数が出ないというのはかなり残念だ．別にアクセス解析ツールをインストールしてダッシュボードでチェックするという手もあるが，いまのところそこまでやりたくない．プラグインではないが，PHPで自前のカウンタを表示という手もある↓．

https://www.metabanium.com/diary/access-counter/

この記事の筆者はCount Per Day のユーザで，サーバーはロリポップ！とか似ているところもあり，親近感を覚えたのですぐにでも設置と思ったのだが，残念なことにこのカウンタは現在オンラインのユーザカウントを持っていない．下記の記事によると，Count Per Dayの「ガイドライン違反」の内容は，「Count per Dayの機能の一部（国名の表示部分）で使っている「GeoIP」が、「GPLではない」ということ」だったようだ．GeoIPとは，IPアドレスから地域を特定する技術，GPL（GNU General Public License）にはその取扱い関する規定が含まれているのだろう．詳細は不明だが，カウンタにはもちろん国名などは表示されないし，特に実害はないような気がするので，復活させてみた．

https://www.web-jozu.com/wordpress/count_per_day/

プラグインは自動更新されているようで，V3.6.1まで進んでいる．やはり，見慣れているし，これで十分なのだが…ただし，総訪問者数と現在オンライン中の人数の位置が入れ替わっているような気がするのだが，記憶違いだろうか？

これで決まりということにするつもりだったのだが…なぜか，設置後しばらくして，右クリックメニューが出っ放しの状態になり，画面操作がまったくできなくなるという現象が起きたため，また「無効」に戻した．右クリックメニューが出たままになるというのはまれに起きることがあるが，「悪い兆候」であることは確かなので，因果関係ははっきりしないが，止めておくというのが安全なような気がする．上記の自前のカウンタはウィジェットとしてインストールできるのでそのうちヒマができたときにでも試してみたい．その前にLive Counterに目が慣れてしまうかもしれないが…まぁ，世の中にはロボットからも完全無視されているサイトはいくらでもあるので，その意味ではロボットも大事なお客さまの一人と考えてもバチは当たらないだろう．

できた！パートⅡ経済循環マトリックスと総体経済の四面等価原理が仕上がった．ずいぶん掛かってしまったが，満足できる仕上がりになった．これで実体経済関わる循環マトリックスの仕様は完全に固まったのではないかと思う．あとは，パートⅢを残すだけだ．金融経済循環マトリックスはボリュームの関係でパートⅢに移すことにした．金融経済循環マトリックスに関してはまだ仕掛りのままで，目鼻も付いていないという感じだが，パートⅢは全体として「読み物」という感じが濃厚なので，あまり手を掛けずにアップすることにしたい．

Live Counterの表示は現在，Live Visitors 24, Visitors Today 114, Total Visitors 53393のようになっている．LIVE VISITORSは現在オンラインでアクセスしている訪問者数かと思っていたが，どうも違うのではないか？おそらく，これは通常ユニークビジターと呼んでいる数字で，VISITORS TODAYというのは当日訪問者数ではなく，通常なら「閲覧数」ないし「ページビュー」と呼んでいるものではないだろうか？そう解釈すれば，現在表示されている数字もそれほど実態とかけ離れたものではないという感じになるのだが…しかし，そうなるとTOTAL VISITORSはかなり膨らんだ値になってしまう．前日訪問者の数字が残っていないというのも残念なところだ．あるネット記事によると，「カウンタ」を設置するというのももはや「昔の話」ということになっているようなので，あまりこだわっても意味がないのかもしれない…

パートⅡ経済循環マトリックスと総体経済の四面等価原理

いや，まだ一つ確認しておくことがある．マトリックスの仕様変更で輸出財，輸入財の定義が変化しているので，資料と数字が合わなくなっている可能性がある．確認しておこう．参考資料によると，1996年の米国貿易収支は輸出が581.2億ドル，輸入609.1億ドルになっている．新しいマトリックス上では輸出2523億ドル，輸入2499億ドルでかけ離れた数字になっている．この数字はむしろ「企業基準」の輸出2523.0，輸入2498.6に近いというより，一致している．つまり，この表は「国籍基準」ではなく，「企業基準」のものになっている．確かにそのようだ．この試算では「資料」で不足している情報を補うために，国内→国外[輸出]341，国外→国内[輸入]318という2つの推計値を適用している．

仕様変更がこの辺りに影響していないかどうか，チェックしておいた方がよいのではないか？⇒輸出入財の仕様変更が影響するのは，最終財の輸出入だけなので多分影響は出ないと思う．最終財の販売はX国内の国内販売1066とB社→国外の1189だけでそれ以外はすべて中間財として処理されている．B社と国外はともにY国籍として扱っているので，国内消費と同じになり，貿易収支には関わりがない．企業基準から国籍基準に切り替えるためには，α社とβ社の行と列をそれぞれ入れ替えればよいだけなのでそれほどの手間という訳ではないが，パスしても問題ないだろう．とりあえず，これで完成ということにしておきたい．さて，いよいよ最後のパートⅢに掛かることにしよう．

Japanese Font for WordPressからのレポートで，CountPerDayはすでにサポート終了しているので，Advanced Page Visit CounterないしGoogle Analyticsに切り替えることが推奨されている．エラーを引き起こす可能性のある「危険なプラグイン」という指摘もあるので，切り替えておくことにしよう．⇒いろいろ試してみたが，これというのがない．最終的にLive Visitor Counterというのを使うことにしたが，まだ3000しかインストールされていないし，ダークモードを指定すると数字が出なくなるなどのバグもある．デザインはシンプルで悪くはないが，これを使うと少し遅くなるような感じもする．ともかく，しばらく使ってみることにしよう．

カウンタを付け替えた影響ではないと思うが，Open Live Writerから投稿したら，テキストが全部太字になってしまった．⇒いや，太字になったのではなく，「見出し」になっていたためだ．デフォルトではもちろん「段落」になっているはずなのだが…

このカウンタは当てになるのだろうか？LIVE VISITORSが7になっている．通常，この値は0, 1, 2のいずれかくらいだったはずだ．このウィジェットはバカチョンで使うようになっていて表示項目以外は何も変えることができないようになっているので，このまま使うしかない．「訪問者数」などの場合は，同一人物のアクセスをダブってカウントするようなことはあり得るが，LIVE VISITORSはリアルタイムでカウントしているはずなので，「重複カウント」ということは原理的に起こり得ないはずなのだが…まぁ，しばらく様子を見るしかない．

VISITORS TODAYもさっき30だったのが，もう45にもなっている．これも奇妙だ．この作者はジョークのつもりでこんなものを作っているのだろうか？ロボットなどをカウントしていればかなりの水増しにはなるかもしれないが，それにしても多過ぎる．昨日までのカウントを引き継げたというのはうれしいが…

「経済循環マトリックス計算のルールブック」新訂版では６個のパラメータを新規追加しているが，このうち，少なくとも中間益と販売益は不用であるように思われる．⇒いや，証明にはやはり必要だ．マトリックスからは外してもよいような気はするが…というのは，これらの値を参照しなくてもマトリックスは描画できるからだ．この意味では，内需要と外需要もマトリックス上では不用なのではないか？⇒中間益が生産額の定義で使われている．つまり，

生産額＝最終財＋中間益

としている．以前の定義では生産額l＝最終財＋純移出となっていた．現行なら

生産額＝最終財＋純輸出

ということになる．どちらが正しいのか？これは当然後者だろう．純輸出＝中間益＋販売益なので，中間益＝純輸出となるのは，販売益＝0の場合だけだ．実際，今の場合は販売益=0だが，単体経済のマトリックスではおそらく不整合が発生することになるだろう．いや，その反対ではないか？所得額も最終財＋中間益となっているのだから，こちらの方が正しいのではないか？所得額と支出額はそれぞれ，（売上高－仕入高）と（全消費＋損益）から導出しているので正しい．問題は生産額をどこから持ってくるか？という点だ．仕掛り品は生産に入らないが，中間財の輸出は生産に入れなくてはならない．

生産額＝最終財＋中間財－純仕入

とすると，生産額＝最終財＋中間益に帰着するので，これで正しい．つまり，中間益，販売益，内需要，外需要は媒介変数としてマトリックス上では省いてよい．純仕入はすでに計算済みなので，計算の便から言えば中間益を計算するより，最終財＋中間財を計算した方がよい．⇒マトリックスに「中間＋最終財」という作業用パラメータを追加した．これでほぼ固まったのではないかと思う．

「経済循環マトリックス計算のルールブック」の改訂版をアップしようとしているのだが，結構しんどい作業になった．新しい用語の定義に従って既出のサンプルマトリックスの数字を再計算し，改訂内容を検証しようとしているのだが，定義がまだ頭によく入っていないこともあって，難儀している．細かい数字を追わなくてはならないので，「もう，これ以上頭が回らない」という感じに近付いている．ともかく，「やればできる作業」なので続けることにしよう．

▲原因は分からないが，WordPressでテーブル内のセルで日本語フォントを使えない状態になっている．WordPress本体にはフォントの操作機能はないので，Advanced Editor Tools（旧名 TinyMCE Advanced）というプラグインを使っている．インストールした時点では出ていた（はずの）日本語フォントがメニューから消えて，あまり聞いたことのないような英字フォント名しか選択できない状態になっている．⇒もしかすると，最初からそうだった可能性もある．

「日本語フォント追加用のプラグイン」というのがあった→Japanese Font for WordPress．テーマのCSSを直接修正するという方法もある．⇒試してみたが，フォントメニューの内容には反映しない．Japanese Font for WordPressはTinyMCE などに日本語フォントを追加するためのプラグインだが，「メイリオ」には対応していないようだ．Easy Google Fontsというのもある．グーグルフォントというのは，Noto Sans JPのことだろうか？わたしはメイリオを使いたいのだが…ネットで検索したら2018年頃にわたしが投稿した記事が出てきた．それによると，その頃はメイリオがデフォルトフォントになっていて，それをMeiryo UIに直したいと考えていたようだ．人は変わるものだ…

WordPressからOLWにダウンロードしてテーブルのフォントを変更し，投稿するという手順でテーブルフォントの統一はできたが，なぜか行間が空いてしまうようになった．ほとんどの場所は1行分だが，場所によっては数十行も空いているところもある．テキスト全体を選択してフォントを一括変換したのがまずかったのだろうか？これを手操作で直すのも大変なので，元のバージョンに戻すしかない．WordPressは自動保存しているので，多分戻れるだろう．⇒確かに，フォントの一括変換の影響であることは間違いなさそうだ．

<span style=”font-family: メイリオ;”> </span>

という行がパラグラフ各行ごとに入っている．⇒ダメだ．リビジョンが読み込めない．「リクエストされた比較データを読み込めませんでした」になってしまう．もう一つ前のものは読み込めた．⇒WordPressのプラグインとして，Simple Google Fonts JapaneseとJapanese Fonts for WordPressをインストールした．前者はテキスト全体のフォントを一括してNoto Sans JPに変える．後者はTinyMCE のフォントメニューにNoto Sans JPを含む日本語フォントをいくつか追加してくれる．

どちらもメイリオを扱うことはできないが，Noto Sans JPはそれほど悪くはないので，今後はあきらめてこれを使ってゆくことにする．Noto Sans JPというのはグーグルのデフォルトフォントだ．さて，作業の続きに戻ることにしよう．⇒Noto Sans JPはそれほど悪くないかもしれない．メイリオと並べて比較してみると，Noto Sans JPの方がくっきり鮮明に見えるような気がする…

WordPressにログインできなくなってしまった．このエラーはLOLIPOP! が出しているもののようだ．

403エラーの原因は，①アカウント停止/無効（該当の契約が停止）か，ないし，②アクセスしているファイルが見つからないのいずれかだ．Open Live Writerからもアクセスできなくなっている．

ともかく，ロリポ！のユーザ専用ページにアクセスしてみよう．認証メールのURLでログインできた．海外アタックガードが有効になっている．これが原因だろうか？カスペルスキーのVPNを使っているので，海外からのアクセスになることはあり得る．現在はSweden経由になっている．無効に設定してみよう．⇒これが原因かもしれない．ログインできた．⇒OLWから投稿もできたので，大丈夫だろう．

また出てしまった．上記の障害も，このエラーから始まっている．「サイト管理者のメール受信ボックス」には通知らしきものは入っていない．⇒今度はログインできた．

「公共貨幣フォーラム」のメーリングリストでやりとりした内容をまとめてアップしようとしているのだが，思いの外手間取っている．120ページ以上のボリュームがあるのを3部に分けて，パートIIまでは大体終わったところだが，頓挫してしまった．デジタル通貨を発行する仮想的な中央銀行システムのブロックチェーンから導出された「経済循環グラフ」の接続行列に相当する「経済循環マトリックス」を構築し，それをベースに「国民経済計算」を実行し，GDPをリアルタイムで計算するという目論見だが，「経済循環マトリックスのルールブック」は仕掛りの状態になっている．とりあえず，メール本文を以下のように修正した．

「※以下12行抹消：消費収支（純消費と最終財の差分）という新たなパラメータを追加することで「貿易収支の赤字＝損益の赤字という伝統的解釈」を復活させようという目論見だが，整合性に欠けているので評価できない．「移出入の古典的定義」に関してはすでに議論を尽くしていると思うので，「経済循環マトリックス計算のルールブック」は現状で一応完結したものとしておきたい．」

という形で決着したつもりだが，そうは行かないことがわかってきた．これは「輸出入」の計数に「最終消費」を入れるかどうか？という問題で，常識的に考えれば入れるのが当然なのだが，なぜか，現行では「仕入れ」のみしか算入しないという仕様になっている．

なぜ，そういうことになっているのかがよく分からない．理由はよく分からないので，これは，「実体経済の最近のトレンド，つまり，グローバル企業による国境を超えた財貨の取引が急速に増加してきたという変化が背景にあるのではないか」という屁理屈で押し切ろうとしたのだが，このルールでは運用上かなりの制約が出てくる．たとえば，「インバウンド」による収入が輸出に含まれないとか，地域外の電力会社に支払う電気料金が「移入」にならないなどの不都合が起きる．理由が分からないので，ともかく「古典的定義」に従ってルールブックを書き換えてみたところ，ようやくそのポイントが見えてきた．つまり，「古典的定義」では一般には「三面等価原理」というものが成立しない場合がある．逆に言えば，現行の定義なら「三面等価原理」はつねに成立する．

三面等価原理を発見したのは，都留重人という日本人経済学者で，国内総生産（GDP）を所得面，支出面，生産面のどの面から見ても同じ値になるという原理だ．この法則が成立するためには，「生産されたものが過不足なく需要されている」つまり，在庫などの流動資本財が存在しないことが前提となるが，実際の経済統計では「統計上の不突合という調整項目を仮想的に計上」して人為的に一致させている．しかし，上述した「古典的定義では一般には三面等価原理というものが成立しない」というのはもっと原理的なものだ．おそらく，経済学者はまだ，これに気付いていないのではないかと思う．実際のところ，内閣府が出している国民経済計算の数字はほとんど「推計に近い」というより，「推計に過ぎない」と言って過言ではない．⇒※

※訂正：「経済循環マトリックス計算のルールブック」にいくつかの新しい用語を追加して書き直した際，一部の計算式に誤りが混入していた．誤りを修正して三面等価原理「所得額＝支出額＝生産額」がつねに成立していることが確認できた．総体経済では「総生産＝総所得＝総支出＝総消費」の四面等価原理がつねに成立する．

▲また，ネットワーク障害が発生している．WordPressにはログインできているが，「更新」すると，「このサイトで重大なエラーが発生しました」が起きてしまう．「サイト管理者のメールボックス」には何も入って来ていない．ファイルが大き過ぎるためタイムアウトが発生しているという可能性も考えられる．いま書いているこのログが投稿できることを確認してみよう．⇒問題なく投稿できた．⇒WordPressから更新してみる．問題なく更新できた．もう一度，仕掛りの大きいファイルを更新してみよう．⇒やはり，ダメだ．これより一回り小ぶりのパートⅢは更新できた．まだ，月半ばだが，povo1.0のギガを使い切っているのでかなり遅くなっていることは確かなので，その影響ということも考えられる．おそらくパートⅡはぎりぎりのサイズなのだろう．後書きとして追加したパラグラフ2つを削除して投稿してみる．

povo1.0には，220円で24時間使い放題というサービスがあるので，試してみよう．⇒ダメだ．通らない．220円も賭けたのに大損だ！⇒旧エディタではなく，ブロックエディタから投稿しても，「更新に失敗しました」になる．⇒同じ内容で「新規投稿」はできた．日付を変更してスレッドを後方に配置しているのが影響しているのだろうか？ともかく，これで続けることにしよう．

去年（2021）の5月頃から3ヶ月に渡って続いた「公共貨幣フォーラム」メーリングリストでの少数の主要メンバーとの対話ではグラフ理論を使った「貨幣循環論」を展開していたが，特にその中では「持続可能な経済循環系」を論じるのに「オイラー閉路」を用いていたのを思い出し，急遽ネットにアップロードしておくことにしたのはよいが，かなり手こずっている．わたしが発言した部分をまとめただけで124ページもあり，編集作業が思うに任せない状態になっている．現在，HTMLを編集するツールとしては，①LibreOffice，②Open Live Writer，③WordPressの3つがあるが，重過ぎて作業にならない．この中で一番軽いのはLibreOfficeだが，直接投稿できないというのが難点だ．

Open Live Writerでは一文字入力するだけでしばらく待たないと制御が戻ってこないという感じ，WordPressならなんとか応答してくれるが，「更新」ボタンが不能状態になってしまって，いざ保存することすらできなくなってしまう．⇒最終的にファイルを3つに分割することで何とか事態を収めた．ファイルを分割して3部構成とすることによって構成がわかり易くなり，論旨も明快になるという二次的な効果もあった．強調する語句を太字にしたり，引用と地の文を区別するために色分けするなどの下ごしらえは大体完了しているので，残っている主な仕事は「テーブル」の崩れを調整するだけになった．WordPressにはHTMLを編集するためのごく基本的な機能しか備わっていないので，Advanced Editor Toolsというプラグインをインストールした．これが入ると，フォントのサイズ変更やテーブルの編集ができるようになる．

何とか，パートⅠは片付いた！

エコロジカルに持続可能な経済循環系グラフ

一応パートⅠは仕上がったことにして，パートⅡに移ることにしよう．

大分大きな穴が開いてしまったが，いつの間にか「世間」のGW最大10連休とかいう波に乗っていたのかもしれない．そう考えれば，もう少し遊んでいてもいいかな？とも思われるが，どうもこの流れで行くと，「もう少し」では済まなくなりそうな気配もある．こんなに離れているのであれば，きっちり整備してテストを仕掛けておけばよかったと思っても，もう遅い．この5日間テストを走らせていればどんなに遅くとも500点くらいまでは削減できていただろう．「極小反例サンプル」が手に入っていた可能性は高い．

いや，まだ遅くはない．これからもまだしばらく「開発」から逸れた状態が続く可能性は濃厚なので，それだけはやっておいた方がよいのではないか？現在仕掛りになっているのは，コラッツ予測問題のための検証ツールのプログラミングとそれに並行して実施しているゼルコバの木の整備だが，ここに来てにわかにもうひとつのミレニアム懸賞金問題が急浮上してきた．例の「数学・物理etc 談話室」で「ケーニヒスベルクの橋の問題」が話題となり，そこでまた大きな進展があったためだ．もう少し詰めないとものになるかどうかは分からないが，感触としては十分な手応えがある．「二兎を追う者は一兎をも得ず」と言われるが，「一石二鳥」ということわざもある．

https://www.facebook.com/groups/2354748741306929/posts/5048400828608360/

「ケーニヒスベルクの橋の問題」というのは，オイラー閉路と呼ばれる「一筆書き問題」だが，別のFBグループのメッセンジャーを使ってディスカッションでオイラー閉路を使って貨幣論を展開したことがあり，どこかにそれをまとめておこうと思いながらそのままになっていたので，まず，それをやっておくことにしよう．一ヶ月分くらいのメールを1本にまとめるだけだから，大した時間は掛からないだろう．⇒対話は主に公共貨幣フォーラムメンバーの下田氏，生島氏とわたしの間で行われたが，期間は2021/05/09～2021/08/01の3ヶ月で，わたしから発信したメールだけでも121ページ分もあり，対話者の分まで含めれば一冊の本になってしまうほどのボリュームがある．

整理手順としては，まず，ともかくメールボックスに入っているメール本文をコピーして，1本の新規メールに集め，それをHTMLで保存してLibreOfficeで編集できるようにしてみた．LibreOfficeからはPDFに保存できるので，それをアップロードするということも可能だが，OwnCloudはあまり使い勝手がよくないので，できればWordPressからの投稿という形にしたい．前に「数学・物理etc談話室」のスレッドまとめをテント村に投稿したときにも似たようなことをやっているが，このときは多分スレッドのコメントを１点づつOpen Live Writerにコピーしていたのではなかったろうか？

WordPressにログインし，編集画面で直接HTMLファイルの内容をコピーすると，一応WordPressで編集できるような状態にはなる．ただし，書式とテーブルは読み込まれるが，画像はリンク切れの状態になってしまう．従ってこの方式で行くとすればすべての画像を手操作で貼り込まなくてはならない．しかし，Open Live Writerでこのサイズのファイルを編集するのはかなりストレスがある．スクロールのたびにフリーズして，改行一つ受け付けるのにしばらく待たなくてはならない．⇒WordPressの編集画面ならそれほどストレスにはならない．画像はLibreでHTML出力したときに同時にファイルとして保存されているので，それを「メディアに追加」で読み込んでページに挿入するだけだ．一度この作業をやってしまえば，Open Live Writerでダウンロードしてローカルで編集することもできる．

画像ファイルの本数は６でそれほど多いものではなかった．編集と閲覧を一つのブラウザで実行できるので，ログインして編集というのもそれほど悪いものではない．と思ったが，なぜか「更新ボタン」が消えてしまう．というかグレー表示になって更新できない状態になってしまう．ネットで見るとこれは「クラシック」エディタに特有の現象で，「ブロック」エディタでは起こらないということのようなので，この際，ブロックエディタに移行することにした．「更新できない場合の対処法」というのもネット上にいろいろあったが，かなり面倒だ．

しかし，ブロックエディタはやけくそ遅いような気がする．一文字入力するごとに，しばらく待たないと次の文字が入力できない…⇒やはり，これまで通り，クラッシックエディタを使うことにする．「更新ボタン」がグレーのときも，二度押しすると反応するようになった．⇒いや，ダメだ．Open Live Writerの動作はもっと悪い．カーソルを置くこともスクロールすることもできない．⇒このテキストもOLWで書いているが，問題なく動作している．おそらく，OLWの動作不良はテキストサイズが大き過ぎるためと思われる．どうにも手の打ちようがなくなってきた．前に作ったコラッツのスレッドまとめも結構大きかったような気はするのだが，こんなことはなかった…

一番確実なのはLibreだが，ここから直接投稿することはできない．完全に仕上げてから投稿するのならそれでもよいが，投稿した現物を見ながら編集するというのがわたしの流儀だ．２つくらいに分割して編集するということは考えられる．それができれば，最後にマージすればよい．

なんとかメモリ不足の問題を解決して，CollatzTest 4000.ADLの極小反例サンプル抽出を行っているところだが，一晩走らせても，まだ80点しか削減されていない．全体で12243点もあるので，これでは焼け石に水だ．現行では，子どものいないノードだけを対象に削除テストを実行しているので，一度に1点しか削減できない．この「一度」というのに途方もない時間が掛かっている．あきらめてここで打ち切るか，何か対策を考えるか？それが問題だ．

▲単身婚ではCheckAtypicalMarriageでやることは何もないのではないか？また，結婚枠の順序が変わらない限り，Gringのリロードは不要なのではないか？⇒CheckAtypicalMarriageを実行しないと，NAMEBOX::DrawFooterLineでエラーで停止する．この関数では脚下垂線を描画しているが，下部垂線の長さを決めるパラメータが計算されていない．Gringのロードは一度だけ実行すればよいはずだが，GringChangedの中で実行しているcancelstackは必須のようだ．この辺りは後日見直すことにする．

▲12146点の「極小反例サンプル.ZEL」をデバッグモードでロード→ 「極小反例サンプル」を実行スタックオーバーフローが起きた．ResetAbsoluteで起きている．

この障害は前にも発生している（2022-04-28）．原因は描画リストで世代枠が長いチェーンになっていること，系列世代枠が描画リストを長いものにしているという2点だ．ここでは，始系列を系図木オブエクトの左枝に接続するという修正を行っている（いたはずだ）．⇒いや，暫定的にResetAbsoluteで世代枠を無視するということしかやっていない．⇒ダメだ．再実行しようとして，また，「アプリケーションはブレークモードになっています」が起きてしまった．EEFileLoadException (メモリの場所 0x00AF8DBC)というのが発生している．この障害はメモリ不足に関係しているように思われるが，よく分からない．起動して，まだ何も実行していない時点で起きているので，手も足も出ない．

2日前の版に戻って見たが，動作は変わらない．訳が分からないので，とりあえず，VS2017を修復インストールしてみる．⇒状況は同じだ．直近の3つの版を試してみたが，「ブレークモード」だ．2022-04-12まで戻ってようやく動いた．2022-04-30版では以下のメッセージが出た．

メモリリソースが足りないとなっている．この版ではコマンドラインでCollatz3950-10934.ADLを起動している．しかし，コマンドライン引数なしで起動しても，「ブレークモード」で停止する．4月29日に同じような事象があり，このときも「メモリリソースが足りません」となっていた，リリースモードでは立ち上がる→ テーブルサイズを縮小→ より小さいサンプルを作成，のように対処している．1月9日にも同種の事象があり，「ターゲットをAnyCPUからWin32に切り替えて動作するようになった」と記録している．この時期にはWindows 10とWindows 7の2つの環境を併用している．⇒確かに，これが当たりのようだ．

ここで「ターゲット」と言っているのは，ツールバーの「ソリューションプラットフォーム」と呼ばれる項目だ．VBのプロパティ→ コンパイル→ ターゲットCPUは「x86」，DLLのプロパティ→ ターゲットプロパティは「Windows 10」に固定されている．OCX，GCも同様だ．構成マネージャではVBのプラットフォームは「Any CPU」に固定で，それ以外は「Win32」に固定されている．

とんだ時間の無駄遣いをしてしまった．⇒仕掛りの最新版に戻って起動することはできたが，SetRowValue←BuildNewTableでoutOfMemoryExceptionが出てしまった．このサンプルは今まで動いていたはずなのだが…カスペルスキーの完全スキャンを実行していることが影響しているだろうか？カードテーブル情報をテキスト配列にコピーするようにしているので，確かに以前よりはメモリを余分に使うようにはなっていると思うが…⇒極小反例サンプルで参照しているのはカードの参照番号だけなので，その部分だけ格納するようにすれば大幅に削減できる．あるいは，このテキスト配列を作らないで，極小反例サンプルでGCから直接レコードを取り出すようにしてもよいのではないか？⇒とりあえず，前者の方法を試してみよう．

そもそも，バージョンが戻ってしまっている．というか，最終版がバックアップされていない．最終バックアップは2022-05-01-2で，これには2022/05/01のログの修正のすべては反映されていない．「BUNSFILEのバッファは常設とする＠20220430」は入っているが，UNDOの修正は入っていないように思われる．ここからやり直すしかない．一度仮眠してデバッグを再開するときには，必ずバックアップを取るようにしないと失敗する…

▲デバッグモードでCollatz3950-10934.ADLを開いて保存しようとして，KAKEIZU::saveFamilyBaseでERR_NOMEMORYメモリ不足エラーが発生する．ヒープサイズは4294967296をリザーブしている．これでも足りないのだろうか？⇒メモリ不足はファイル書き込み用バッファのメモリ要求で発生している．要求サイズは45,904,944，このときまでに使用しているメモリ総量は106,632,555で，トータル152,537,499．これはヒープサイズの4,294,967,296より，ずっと小さい．おそらくメモリが断片化して連続した領域を確保できないためだろう．

まとめて書き込むのではなく，一行づつ書き込むことにすれば，それほど大きなバッファは必要ないのではないだろうか？⇒現行では，系図木処理から直接ファイルに書き込むのではなく，QUICKDBという簡易データベースシステムを経由して入出力するようになっている．QUICKDBではカードデータベース，結婚データベース，記録データベースを管理して，保存時にはそれらを一括して書き出している．バッファは一度確保されると，サイズオーバーにならない限りそれを使い続けるので，それほど効率の悪いことをやっている訳でもない．QUICKDBは外部ストレージとの入出力用にBUNSFILEというクラスを使っている．

KAKEIZUは人名データベースと結婚データベースという２つのQUICKDBを持っている．QUICKDBはBUNSFILEをメンバーとして持ち，BUNSFILEの中にバッファを確保している．また，これとは別にCOUPLINGにはCHUNKFILEというメンバーを持っている．CHUNKFILEは独立に記録データの入出力用としてFILEBUFFというバッファを持っている．CHUNKFILEはMFCクラスのCArchiveと連携している．⇒BUNSFILEのバッファを常設とし，起動時に一度生成してそのまま使うことにすれば少しは改善されるのではないか？⇒やってみよう．⇒対処した．最初に確保してしまえば，その後はメモリ操作不要になる．

新規ファイルを開いた状態からCollatz3950-10934.ADLをインポートでOutOfMemoryExceptionが発生する．このエラーはVBで発生している．何か対策はあるだろうか？BuildNewTableではDataGridView.Rows.Clearでコレクションを空にしている．これを削除ではなく，更新にすることは可能だろうか？⇒UpdateTableという関数もある．UpdateTableではレコードの更新を行う．行数が足りないときには追加することができるので，これでもカバーできるのではないか？⇒いや，効果ないだろう．新規ファイルから初めているので，一覧表は元々空の状態だ．つまり，絶対的に不足しているというしかない．

不要な列は表示しないというのは効果があるだろうか？ダメのようだ．しかし，テーブルを最初からそのようなものとして構築してやればかなり効果はあるのではないか？MAXITEMを変えればそのような状況になるが，至るところで「インデックスが配列の境界外です」になるのは避けられない．テーブルを操作するほとんどすべての関数で起きるだろう．エラーが200箇所以上発生する．⇒MAXITEMを調整してテーブルを縮小するというのはかなり難しい．そもそもADLのインポートはテーブルを媒介としているので，無理がある．

検証テストのテストカウントを3900としてもう少し小さなサンプルを作った．カード数は6165，結婚数4684になった．これなら楽にロードできそうだ．⇒ロードしたADLを名前を付けて保存で，BUNSFILEのバッファが空になっている．CloseFamilyBase→COUPLING::Cleanで空になっている．⇒Cleanの代わりにdoCleanを使うことで解消した．doCleanは自己の固有データ部のクリーンのみを実行する．CleanではdoCleanを実行し，かつ下位スロットをCleanしている．多少疑問の残るところだが，一応これでよいことにしておく．しかし，このサンプルは反例になっていない．ループカウント30で脱出してしまう．

▲Collatz3950-10934.ZELを開いた後，Collatz3950-10934.ZELを読み込もうとしてQUICKDB::lodquickで例外が発生した．アクセスヴァイオレーションが発生している．BUNSFILEのバッファは保持されている．⇒どうもこのファイルはこわれているようだ．ファイル冒頭のマジックナンバーを読み込むことができない．ファイルサイズも48KBしかない．本来なら３MBくらいはあるはずだ．多分ファイル保存操作中エラーが発生して中断になっているのだろう．

▲Collatz3950-10934.ZELを開いた後，Collatz4000.ADLをインポートしてTITLELINK::SetTitleInformationで(len != TitleInfo.Rtfsize)というエラーが出た．⇒その後，SetRowValue→BuildNewTable：rowindex=5003でOutOfMemoryExceptionになった．このサンプルはカード数12243, 結婚数10170で，カードテーブルサイズ=12300，結婚テーブルサイズ=10300という設定で走っている．⇒名前を付けて保存はできた．⇒メモリ不足が関係している可能性はある．

目下の懸案となっているのは以下の2点だ．①UNDOでShadowが空というエラーが起きている，②Collatz4000-12243.ZELでループカウントオーバーが起きる．上記のCollatz4000.ADLというサンプルは②の反例に該当する．これを極小反例サンプルの抽出に掛けたいところだが，メモリ不足になるというのが最大の問題だ．DLLで発生するメモリ不足に関しては何らかの抜本策も考えられるが，VBで起きているメモリ不足に関してはほとんど対策がないか限られている．一覧表をまったく生成しないことにすればかなり効果があるのではないかと思われるのだが，隣接リストのインポートではカードテーブルをデータの受け渡しに使っているので，それもかなり難しい．

ファイルから読み込んだ1行データをテーブルのレコードに変換しないで，テキストのまま保持するということはできるのではないか？もし，それが可能ならかなりメモリ使用量を削減できるような気がするのだが… ImportFileでは実際それをやっている．インポート自体はテーブルを使わずに実行できることは立証されているので，一覧表にレコードを追加しないで空のまま放置というのでよいのではないか？⇒なんとかこれで動くようになった．

REDLINEは50という設定でも1点検査するのに相当な時間が掛かり，空振りばかり続くのでもう少しヒット率を上げるために，子どものいないノードをピックアップしてテストすることにした．多分これなら時間とともに削減が進むだろう．⇒リリースモードに切り替えたら，大分速くなった．⇒速いはずだ．対象サンプルが違う．⇒そもそも，まだ動いていない．⇒ようやく動くようになったが，やはり，UNDOでエラーが発生している．これはおそらく，UNDOに関わる修正がまだ収束していないことを示すものと考えられるので，UNDO操作に集中してもう少し小さいサンプルで動作確認を行うことにする．

▲最小反例321ZELを開き，任意のカードを削除してUNDOBASE::SetUndoListで (!copynode->shadow)エラーが発生する．copynodeはUNDOの上書き対象ノードなので，すでにshadow付きになっているはず…⇒いや，copynode不在で新規に生成されたケースだ．できたてなのだから，shadowが入っていないのは当然なのではないか？少し古い版のコードを見る必要がある．⇒2022-02-26で見ると，/* 生成したばかりでshadowを持つはずがない＠20170823 */というコメントが入っている．この位置にはshadowを設定するコードが入っているが，現行版では「1行削除＠20220423」となっている．なぜだろう？かなり考え難い．※⇒編集ミスではないだろうか？

2022/04/23の修正は，「UNDOのShadowをfreeblock化」だ．shadowはフリーメモリなのだから，どこかでメモリを確保していなくてはならないはずだが，やっていないように見える．従来論理ではfreeblock::getmemでメモリを取得しているが，freeblockとして扱うためには，_getmem_を使う必要がある．このとき，MMTYPEを指定するようになっていて，MM_SHADOWという定数が新規に追加されている．⇒定義されているだけで，まったく使われていない．⇒修正した．（この修正は入れた記憶はあるが，誤って消してしまったのだろう）

一応，カード削除でUndo/Redoができるようになったが，カード数の表示が正しくない．Undoしても数字が元に戻らない．この数字はUpdateMaxCardで更新しているのだが…UpdateMaxCardの呼び出しが掛かって来ない．⇒「極小反例サンプル」対応でコストの掛かる処理を止めているためだ．①GetNewTable，②GetNewCard，③CenteringCardSubをパスしているが，おそらく，GetNewCardでUpdateMaxCardを実行していたものと思われる．⇒「極小反例サンプル検定の時間効率改善20220501」で対処した．

▲複数カードを選択して，逐次削除→全削除を実行→Undoして，UNDOSYSTEM::UndoProcessで(UndoCurptr->UndoNumber != UndoNumber)により停止した．2点選択して逐次削除→Undo→Undoで再現する．UndoCurptrのUndoNumberは1，UndoNumberは2になっている．明らかに大域変数のUndoNumberの方が誤っている．UndoしたときにはUndoNumberはデクリメントされなくてはならないはずだ．UndoNumberはUNDOBASEとUNDOSYSTEMで重複して調整されている．しかも，反対方向に調整している．どちらか一方は不用と思われる．UndoCurptrはnoduleクラスでも定義されている．UNDOCOMMANDはそれ自体noduleなので，混乱が生じている．noduleの側はUndoNumberとし，UNDOCOMMANDでは大文字のUndoNumberを使うようにしてみよう．⇒収まったようだ．

▲CollatzTest.G.ADLをインポートして，「極小反例サンプルの抽出」を実行中，UNDOBASE::SetUndoList で(!copynode->shadow)により停止した．最初のカード削除のUNDOSYSTEM::UndoStartで起きている．⇒「極小反例サンプル」のベースはUNDOなので，これができないと始まらない．UNDOに修正を入れた後，「極小反例サンプル」のテストを実行していなかったのではないか？もう少し小さいサンプルで確認してみよう．⇒いや，すでに小さいサンプルは解けるようになってしまっている．最新のサンプルはCollatz3950-10934.ADLだ．それより大きいサンプルは特にデバッグモードでは開けない．

デバッグモードでこのサンプルを開くことはできるが，極小反例サンプルを実行しようとするとSystem.OutofMemoryExceptionが発生する．⇒BuildNewTableで.Rows.Clearの後に，System.GC.Collectを実行して，OutofMemoryExceptionは解消した模様だ．現象を再現するまでの時間が掛かり過ぎるので，MAXREDLINEを暫定的に5に設定した．それにしても遅い… LINKTABLE::cardlink(refnum)ではrefnumとrecnを同一視するように論理修正した．marglink(refnum)も同じ．また，BASETABLE::delrecnとmaxrefnumを廃止した．AppendFileは修正が大きいので，暫定的にまるごと止めてある．

OSを再起動→デバッグを再開しようとして，「アプリケーションはブレークモードになっています」がまた出てしまった．「ハンドルされていない例外」として，「内部例外：FileLoadException: ファイルまたはアセンブリ ‘ZelkovaGC3.dll’、またはその依存関係の 1 つが読み込めませんでした。このコマンドを処理するにはメモリ リソースが足りません。 (HRESULT からの例外:0x80070008)」のように表示されている．

再起動前は問題なく動作していたのだが… カスペルスキーが走っていることが関係あるだろうか？⇒リリースモードなら立ち上がる．⇒しかし，極小反例サンプルではOutOfMemoryExceptionになってしまう．現在の設定はカードテーブル12200，結婚テーブル10200で，この設定ならリリースモードはもとより，デバッグモードでも障害地点まで走ることができたのだが… もっと小さいサンプルを作るしか，打つ手がない…