潜在意識とソフトウェア工学
Subconsciousness and Software Engineering
テクノロジーニュースでAI関連の記事を見ない日はない。でも、AIで検索して出てくる記事は、ディープラーニング以外目新しくない。 ましては、大学や官庁が提供する有識者の記事は、今まで語りつくされてきたものだけだ。
また、プログラムを小学校で教えることになったそうそうだが、私の主観だが、それより、暗記中心の教育方法そのものを見直す必要がある。
暗記中心の教育方法は、教育をする側にとって都合がいいだけであって、教育を受ける側にあまりメリットがない。それに記憶力は、遺伝子の優劣でしなかない。
その証拠に有識者と呼ばれる人たちは、この暗記中心の教育の優等生だから、過去の知識を捏ねくりまわすことしかできない。
3D画像描写はパーテックスをマトリック（平行移動、回転、スケーリングなど）で変化させて実現する。だからコーダーは、逆発想から画像からエッジやシェープを見いだせることに
気がついた。この閃きがディープラーニングにつながったことは確実だ。だが、暗記中心の教育ではこんな閃きはでてこないだろう。
'80年代多額の税金が費やされた第五世代コンピュータではディープラーニングの発想はなかった。これは、暗記中心の教育方法の優等生が指揮したプロジェクトだったからだ。
3Dグラフィックは'80年代には使用されていたから、第五世代コンピュータ開発者がマトリックスを知らなかったという理由は当てはまらない。
主観だが、ソフトウェアを構築する上で最も重要なことは、この「閃き」だ。
AIやソフトウェアを教えるとうたい数十万の費用をとる会社が複数あるが、この「閃き」はお金で教えることは不可能だ。
ちなみに、主観だが、この「閃き」はソフトウェア工学的に
UML -> クラス図 -> 関係 -> 関連(association)
だと思っている。
約40年以上前に私が初めて作ったプログラムの言語はCOBOLだった。COBOLはご存知のように、全体が4つに分かれて構成されます。
・見出し部(IDENTIFICATION DIVISION)
・環境部(ENVIRONMENT DIVISION)
・データ部(DATA DIVISION)
・手続き部(PROCEDURE DIVISION)
COBOLが外部のデータを取得する方法は、環境部(ENVIRONMENT DIVISION)にファイル宣言しデータを読むしかなかった。
だが、そのデータ形式は固定長か可変長、アクセスメソッドに至ってはシーケンシャルアクセスしかなかった。
したがってCOBOL単体で作られる動的なソフトウェアは事務処理など限られた目的にしか使えなかった。
だが、DBMS（database management system）と連携することでCOBOLで作成された動的なソフトウェアは巨大システムの中枢を担うことになった。
つまりDBMSという静的なソフトウェアはCOBOLで作成された動的なソフトウェアと連携することにより、現代の巨大システムに匹敵する力もっていた。
しかし、この静的なソフトウェアDBMSを使用するにはスキーマを作成する必要がある。このスキーマはCOBOLと同じCODSYL仕様でCOBOLと同じように 作成できるようになっていた。だからと言ってCOBOLを知っていれば誰でもスキーマを作れるわけではない。 スキーマを作成できる人は、データ構造およびアルゴリズムの精通者でなければならなかった。
HBOの「シリコンバレー」というドラマで主人公が自分を馬鹿するプログラマーに対して、小声で「バイナリィサーチ」も知らないプログラマー
に馬鹿にされたくない。と愚痴る場面があり、思わず大笑いしました。ちなみに「バイナリィサーチ」ご存知ですか？
そんなソフトウェア製造のプロ中のプロでもスキーマを作成するのは至難の業だ。
それでも苦労して構築したシステムがデータベースのストレージアクセスネックやデータ検索アルゴリズムの選択誤りで予想した性能がだせないことはよくあった。（後戻りが出来ない一発勝負）
そしてこの問題は現在よくつかわれるリレーショナルデータベースにも引き継がれている。
これは、ストレージのデータアクセスをスキーマを介して行うDBMSの限界なのだろう。Yahoo(DBMS)がGoogle(Cloud)に敗れたことからもDBMSの限界を感じる。
80年代に入りC言語が使われはじめた。当時、メインフレーム通信制御の割り込みコンテキストを担当していたので、C言語を見たとき感動した。
割り込みコンテキストで面倒なのがレジスターの退避と回復だがC言語はプロセス内にスタック領域を持ち自動的にレジスター退避と回復を行っていた。
でも、割り込みコンテキスト及び構造化言語から関数型言語になった経緯を知らない若きプログラマーが書くCプログラムは見るに堪えないものだった。
これはC言語の利点の一つ自由度の高さが原因で、誰でもが動くプログラムを簡単に作れることがC言語最大の弱点だった。
その後オブジェクト指向を取り入れたC++が登場したが、C言語の自由度を知ったプログラマーがC++のオブジェクト指向を使いこなしたとは思えない。
その証拠はJavaの登場でプログラマーはこぞってJavaに以降したことから分かる。
オブジェクト指向の登場でスキーマ不要で静的なソフトウェアの構築が可能となったが、オブジェクト指向が登場した当初だれもが、汎化(generalization : is a)より
継承を重視し、オブジェクト指向で静的なソフトウェアが構築できることは40年前にオブジェクト指向を使っていた自分しか知らなかった。
でも、静的なソフトウェアとしてJavaを使用とした場合、目的を実現する動的なソフトウェアを動かすまでに静的なソフトウェアを初期化（インスタンス化）する必要があった。
だから、90年代のオブジェクト指向環境はJavaを筆頭にCOBOLと同等の動的なソフトウェアのためのものであった。
2000年代に入るとWebが恐ろしい速さで進化した。なかでもDOM（Document Object Model）の登場には驚かされた。なぜなら、DOMそのものが、私が言うところの
静的なソフトウェアそのもだからだ。私はDOM（Document Object Model）を知り40年前に時間が戻ったと思った。
ソフトウェアを構築する場合(AI含む)静的なソフトウェアと動的なソフトウェアを考えなければならない。
この静的なソフトウェアでは基本的に不変的なアイデンティティを構築する。ソフトウェア工学的には
UML -> クラス図 -> 関係
1)汎化(generalization : is a)
2)集約(aggregation : owns a)
3)コンポジション(composition : is part of)
で構築されるy軸方向に変化する親子関係だ。
動的なソフトウェアは静的なソフトウェアをベースにコンピュータに目的の仕事を行わせる。ソフトウェア工学的には
静的なソフトウェア +
UML -> クラス図 -> 関係
1)関連(association : has a)
2)依存(dependency : uses a)
で構築される自由な方向に触手を持つ関係だ。
このクラス関係は約40年前NTT研究室で語られていたものとほとんど同じである。つまり、人間の潜在意識は脳科学的には複雑怪奇かもしれないけど、
潜在意識に記憶された情報の結びつきは、ソフトウェア工学的における上記5つの関係で説明できる。
静的なソフトウェアと動的なソフトウェア存在する環境は誰でも目にしたことがあるWebつまりホームページだ。ホームページを実現する
構造は以下のようになっている。
HTML + CSS : 静的なソフトウェア
JavaScript : 動的なソフトウェア
したがって、ホームページ(HTML5)は理に適うソフトウェア構成だ。その証拠に、JavaFX , C#(WPF)などフロントエンド系のソフトウェアを構築する言語は、静的なソフトウェア(XML)＋動的なソフトウェアの構成を取っている。
'80年代後半OSIの実装を行った私は、物理層からセション層までは理解できたが、アプリケーション層およびプレゼンテーション層が理解（想像）できなかった。（プロトコル仕様は複雑怪奇だった）
しかし、Webを知り、アプリケーション層およびプレゼンテーション層という仰々しいプロトコルなど不要で、httpという簡単なプロトコルでアプリケーション層およびプレゼンテーション層が実現されているのには驚かされた。
そして、SVG,動画,音源,WebGLなど進化が止まらないW3Cは今後も注目が集まるだろう。
これはOpenGLの演習問題を2DのSVGで実現したものだ。(ボケ防止の為に作ったコ－ド)コードを見てもらえば分かるが、ほとんどがベクトル、マトリックの単純計算だけだ。だから、演算装置が貧弱なCPUで実行するのはCPU資源の 無駄遣いだ、ということが分かるだろう。ベクトル、マトリックの単純計算はGPUで行う現在のグラフィック技術は理にかなった方法だ。
話が前後するが、ソフトウェアでなぜ関連(association)が大切かを将棋（もしくはチェス）プログラムの大まかアルゴリズムで説明する。
まず、静的なソフトウェアは、過去の膨大な将棋試合結果データを構築することから始まる。
動的なソフトウェアは静的なソフトウェアの膨大なデータから最適なデータを探しだし、次の手を打つ。
で、ここが最も重要だが、最適なデータを抽出する方法は、普通だったら、将棋のルールに従って次の手を考えることになる。
だが、実際は、将棋のルールをアルゴリズム化し人間以上にすることは不可能だから、適切な関連から静的なソフトウェアを検索する。
現代の将棋ソフトウェアで使用されている関連(association)は、「面積」だ。
ある特定の複数の駒から面積を算出し、その面積から次の手を検索する。
この関連「面積」が「閃き」であり、正直、私のような凡人には思いつきもしない発想だ。
テレビの科学番組でこの「将棋」と「面積」の関連を知ったのだが、その番組での将棋関係者のコメントが面白かった。
「プロ棋士も無意識に複数の駒間の「面積」を求めているのかもしれません？」
私はこのコメントを聞き、人間の潜在意識とソフトウェア工学はそんなにかけ離れたものではないと感じた。
HTML+CSSで作成された情報は、テキストからオブジェクト情報にパーサー（コンパイル）を利用して変換され、そのオブジェクト情報つまり静的ソフトウェアに従ってスクリーンに ホームページを描写する。そして、JavaScript（主観だがJavaScriptは肖りJavaと肩を並べる存在になったのだからJavaをなくしてもいい時期だと思う） はこのDOMを参照更新し目的を実現する、動的なソフトウェアとしてブラウザー上で動くことができる。 HTMLのDOMはノードにエレメントを持つ木構造になっており、DOMをすべて参照するにはノードからエレメントを nextで取得すれば簡単に参照できる。この木構造アクセスは、DBMS+COBOLとまったく同じだ。ただ違うのはDBMS内にあるアルゴリズムを自分で組み込める 柔軟性がJavaScriptにはある。（「バイナリィサーチ」も簡単にできるよ。でもソートが必要だからばかばかしくてJavaScriptで「バイナリィサーチ」する人は居ないだろうな。）
オブジェクト指向にはポリモーフィズムが存在するが、これをうまく利用しているのはJavaやC#じゃなくWEB(HTML)だ。要はWEB(HTML)におけるポリモーフィズムとはダックタイピングのことだ。 主観だがこのポリモーフィズムの基本的な概念はCLONE＆UPDATEだと思っている。この概念はJavaScriptでJavaやC#みたいにサブクラスとして故意に作りこめるが、ブラウザーで作成したオブジェクト すべてに機能するからHTMLのDOM内に一意的なプロパティを書き込んだり、ブラウザー上で前もって準備されているオブジェクト、たとえば配列などに自分専用のメソッドを追加できる。 このWEB(HTML)のポリモーフィズムを上手に取り入れているライブラィーがD3.jsだ。D3.jsの使い方は一見複雑だけど、このポリモーフィズムを理解しながら読み解く とその目的を実現する手段のすばらしさに気づかされるはずだ。
HTML以外にテキストからオブジェクト情報にパーサー（コンパイル）を利用して変換されデータはHTMLから派生したXMLとJSON形式が存在する。DBMS+COBOL時のスキーマはオーナーとメンバー関係を定義するだけなので、
データベースの初期化、つまりインスタンス作成を考えなければならなかった。（Javs,C#(WPF以外)もこのインスタンス作成の初期化が必要）
しかし、XMLとJSON形式はテキストでインスタンスも準備しておくことができ、
かつ、ポリモーフィズムで簡単にインスタンスを追加することもできる。またJSOM形式の場合メソッドもポリモーフィズムで追加できるので、
データ検索の為のアルゴリズを前もって準備しておくことができる。
したがって、XMLとJSON形式も静的なソフトウェアと言って過言ではないだろう。実際、私の作るフロントエンドプログラムにはJSON形式は欠かせないものとなっている。
「JSON という気味の悪い拡張子」という内容の記事が東洋経済オンライン に掲載された。ここで東洋経済オンラインという何者なのかわからない奴らにお聞きしたい、
現在のインターネット時代にJSON形式以外に簡潔に情報を受け渡せるデータ形式があるなら教えてほしい。もし、text形式といったらばぶっ飛ばすぞ！
心理学におけるアイデンティティは複雑だ。でも、ソフトウェアにおけるアイデンティティは簡単だと思っている。私が初めてアイデンティティと出会ったのは40年前のデータベースの概念設計だった。 単純にアイデンティティは帰属性である、と教えられたような気がする。私はこのアイデンティティの概念を自分の中で形にするため毎回頭の中に無造作に置かれた積木を思い浮かべる。 そして無造作に置かれた積木のアイデンティティ（帰属性）を考える。私が考える積木のアイデンティティ（帰属性）を以下に示す。
これが積木のアイデンティティの例だ。ではこれをJSON形式で表現してみよう。
{
"おもちゃ":[
"積木":{
"四角":{
"プラスチック":{"大":10,
"中":5,
"小":8
},
"木材": {"大":10,
"中":5,
"小":8
}
},
"三角":{
"プラスチック":{"大":3,
"中":40,
"小":10
},
"木材":{"大":30,
"中":4,
"小":2
}
},
"丸形":{
"プラスチック":{"大":60,
"中":20,
"小":5
},
"木材":{"大":15,
"中":7,
"小":2
}
},
"星形":{
"プラスチック":{"大":2,
"中":3,
"小":5
},
"木材":{"大":2,
"中":5,
"小":1
}
}
}
]
}
以上のようにJSONでは簡単に作成できる。（これをJavaやC#のクラスとインスタンスで表現した場合少し厄介になる。） このJSONをパーサー（コンパイル）にてオブジェクト化する。 私はこのアイデンティティを静的ソフトウェアと呼んでいる。
では、動的ソフトウェアはとは？
当然おもちゃの積木で遊ぶ子供達だ。積木でお城作る、積木で車を作る、積木で船を作る、その他子供達の発想力は私には図りしれない。
でも、おもちゃの積木のアイデンティティは上記に示す内容で基本的には大丈夫なはずだ。
だから、おもちゃの積木で遊ぶ子供達動的ソフトウェアは全然違っていてもおもちゃの積木としての静的なソフトウェア(アイデンティティ)としては共通で使えるはずだ。
ここからは主観だが、近頃のソフトウェアーのWeb記事及びソフトウェアの教育関連記事のほとんどが動的ソフトウェアの話だ。
つまり殆どが言語関連の話だ。でも言語なんて早くて数週間、遅くても数か月でマスターできる。でも、言語だけマスターしてもソフトウェアは構築できない。
コンピュータで何がしたいか目的をもて、とよく言われるが、正直40年以上コンピュータと遊んでいるが、未だにその目的を自分は見出していない。
それに、コンピュータを単に使いたいだけだったら、既存のアプリケーションを使用すれば事足りるので、いちいちプログラミングなんて面倒くさいことしなくていい。
思うに、コンピュータを意のままに動かすことができる人々の資質は「好奇心」だと思う。この好奇心がないままソフトウェアを学んでも行き付く先は「挫折」しかない。
近頃の「CG」は凄い、とよく耳にするが、どうやって「CG」は実現しているのだろうと「好奇心」を持つ人はほとんどいない。
上記におもちゃの積木の例を掲げたが、もし5歳児の前に本物の積木を与えたら、何も教えなくても子供達は積木でかってに遊び始めるだろう。
つまり、「好奇心」は人間として生まれたすべての人に先天的に備わっている。でも、社会に順応するための教育、そして実社会を生き抜く間に「好奇心」は後天的に失われるようだ。
私が最もよく見るマニュアルは「ActionScript3.0 アニメション（ボーンデジタル）」だ。このマニュアルの序文に以下のような文章がある。
『プログラミングは新しい、エキサイティングな芸術形式で、毎日のように人々の目前で成長し、関連性を深め、評価を高めます。どんな芸術形式にせよそれぞれを
学ぶ最善の方法は修行を積み、師匠の持つ貴重な体験を共有することです。』
なんだか、数世代前の日本の職人のことを言っているようだ。でも、現代のインターネット時代では日本を除く全世界のコンピューターエンジニアの基本的な考え方になっているようだ。
日本のフロントエンドエンジニアのコミュニティーサイトは低迷しているからコードを投稿しても手ごたえはないが、
海外のコミュニティーサイトにコードを投稿すると、「なぜ・・・」（英語だけど）というコメントがよく来ることから分かる。
アイデンティティを構築するに当たり重要な関係（クラス）は汎化,集約,コンポジションだ。ここで、この関係の違いを簡単な例で示す。
汎化は遺伝と同等と語られるので、上記例では動物を掲げた。しかし、静的なソフトウェアとしての汎化は、正直、私には使いどころが分からない。'80年代エキスパートシステムを構築したが、
汎化は使わなかった。（XML及びJSONに汎化の機能がないことかもアイデンティティ構築ではあまり使われない。だが、概念的には重要だ。）
主観だが近頃「汎化」は語られない。しかし、この汎化と同等の機能「継承」はよく耳する。だが、「継承」はオブジェクト指向その物のように語られているのもが多い。私が考える「継承」
はCLONE＆UPDATE、つまりマクロ（たとえばC言語の#define）の代替でしかないと思う。でも、マクロより洗練されている機能だから使い方により優れた道具となる。
「階層型」「ネットワーク型」データベースが基礎となっている自分なので、アイデンティティの構築はこの「集約」だけで充分だと考える。
でもこの「集約」は簡単なようで案外奥が深い。たとえば、オブジェクト指向
プログラム設計でまず行うことは、クラス設計だが、このクラス設計そのものがアイデンティティ（帰属性）構築そのものといえる。でも、アイデンティティ構築では、メソッドつまり手続きは考えない
から、クラス設計のベースとなり得る。私が考える人間の潜在意識こおける記憶の関係もこの「集約」だけで説明できると考える。
上記例で示したが、
生物の有機物を原子レベルまでアイデンティティ（帰属性）を構築し活用できるのは、人間の潜在意識だからこそだ。ただ、クラウドにて有機物を原子レベルまで分解し部類した
ものを記憶することは可能だ。しかし、人間の潜在意識とは違い、記憶した物同志の「関連」を自動的に見つけることはコンピュータがどんなに発達しようが不可能だ。だから
AIが人間の潜在意識いや人間を超える存在なるとは思えない。
汎化と同じようにXML及びJSONにコンポジションという機能は存在しない。でも、エンジンがない車を車と扱う人は居ないだろう。だからコンポジションという機能は不要だが概念は絶対必要だ。
Web記事でUMLのクラス図の説明に会社というアイデンティティで説明していた記事があったが私は納得がいかない。その例では会社を集約(aggregation : owns a)で表していたが、驚くことに
会社の直後に社員が存在した。会社の集約として社員と関係を持っても問題はないが、社員情報は単独で管理しても問題ないから、オブジェクト指向である必要がない。
社員と会社を関連付けなくても、社員情報はストレージに保管し社員番号をインデックスにしてSQLアクセスさせる単独の情報元にしても問題ない。（ストレージへのアクセスネックは考えないとして）
そこで私が考える会社という静的なソフトウェア(アイデンティティ)について考えて見る。 まず、静的ソフトウェアを構築する場合、動的ソフトウェアの種類と業務内容を考察する。 会社における動的ソフトウェアは社員であり、社員の仕事内容が動的ソフトウェアそのものだ。 そして、社員の仕事内容を無造作に拾い上げアイデンティティ（帰属性）を考察する。 でもこれではアイデンティティが膨大になる。しかたがって、ここでは、会社の窓口、受付案内係の業務の静的ソフトウェアに限定して考察する。
| 受付案内係の業務 | 業務で使用する情報 |
|---|---|
| 電話・メール応対 | 会社組織情報 |
| 来客応対 | 会社組織情報、入館証管理情報 |
| 社内文書作成（報告書等） | 会社組織情報 |
| ご案内業務 | 会社組織情報 |
| 会議室スケジュール管理 | 会社組織情報、会議室管理情報 |
| 予約受付・登録・管理 | 会社組織情報、予約管理情報 |
| 入館証管理 | 会社組織情報、入館証管理情報 |
| 顧客情報の登録・管理 | 会社組織情報、顧客情報 |
| 備品管理 | 会社組織情報、備品管理情報 |
| 館内放送業務 | 会社組織情報 |
| セミナーやイベント企画・準備・実施 | 会社組織情報、会社イベント情報 |
上記静的ソフトウェアは私が直感で考えたものだから精度的は50%ぐらいだろう。でも、これだけの静的ソフトウェアだけでも受付案内係の業務（動的ソフトウェア）
はある程度の言語知識がある人であれば構築可能だ。それに、今はプロトタイピングの時代だから、構築しながらシステムの精度を向上させればいい話だ。
主観だが、ソフトウェアを構築する上でまずやらなければならないことは、詳細に業務を洗い出し、それを床に投げ散らかし、アイデンティティ（帰属性）を抽出することだ。
「メンタリスト」のパトリック・ジェーンによると「見たり」「聞いたり」「味わったり」「感じたり」「匂ったり」と五感はすべて記憶として潜在意識に残るそうだ。
でも、この記憶は脳の広範囲に記憶されるので、呼び起こすことが困難になる。だが、この記憶と同時に感じた五感と関係づけれるので、ある日突然、五感で何かを感じたとき、
記憶が呼び起こされることが良くあるそうだ。
「YOUは何しに日本へ？」で「大昔に食べたかつ丼を食べにいく」というyouに密着取材する回があった。30年以上前のことなので、店を探すのも大変だったが、
それらしき「そば屋」を発見。30年以上前から店を営んでいて、「かつ丼」は開店当時からあるということなので、youは「かつ丼」を注文した。そして、
「かつ丼」を食べ「これこれ」と叫んで、youは大粒の涙を流した。youの涙の訳をたずねると
「当時言葉もわからない異国で不安だったが、「かつ丼」のうまさから、こんな美味しいものがある国だったらやっていける。」とその時日本で生活することを決心した。
その時の記憶が「かつ丼」を食べたとき呼び起こされたそうだ。
これがパトリック・ジェーンが言うところの記憶と五感のリンクなのだろう。
youが最後に「30年前、日本で「がんばろう」と決心したことに悔いはない。」と言ってくれたことに日本人の自分としては少し安堵感を覚えた。
この記憶と五感のリンクはソフトウェア工学的には「関連」だが、「集約」は案外呼び込み易い記憶として扱われるようだ。
例えば、嫁のお父さんと会った時の記憶は何年たっても忘れることはないだろう。
なお、コンピュータには五感はない。だから、AIがどんなに進化しようがコンピュータが涙を流すことはないだろう。
LOSTが好きで動画サイトで数回見た。（でも、飽きないからまた見るつもりだ。）
LOSTシーズン1で最も印象に残っているシーンは、ソーヤーが「いかだ」で島からの脱出を試みる日、別れの言葉を交わしている際、ジャックが何気なく話した親父の口癖
「だからレッドソックスは勝てない」という言葉をソーヤーを聞いた。ソーヤーはその言葉からオーストラリアで出会った医師のことを思い出した。そして、ジャックに、「
親父さんは、ジャックのことを誇りに思っていた」と伝える。
実社会において、医師と詐欺師が交わることは殆どない。ましてや、医師と詐欺師に友情が芽生えるなんて住む世界が違うからあり得ないはなしだ。
だが、ジャックとソーヤーはこれが固い絆となり、これから起こる予想だにしない試練に協力して立ち向かうことになる。もし、このシーンがなければ以降の話は面白くなかっただろう。
で、このシーンをソフトウェア工学的に表してみた。
『レギオン』（マーベル）の（シーズンおよびエピソード回は忘れた）イントロで「今」について語っていた。たしか「今」は過去と未来の間にある「虚像」だ、と言っていたような気がする。
でも、私は「今」が「虚像」であることはだいぶ前から気がついていた。人間が「今」を確認する為に使用しているのは「視覚」だ。でも、この視覚は光で運ばれる情報だが、
光が脳に届く間も時間は止まることなく動いている。だから、「脳」に届いた光の情報は「今」ではなく「過去」のはずだ。
このことから、止まることのない時間という基準で「今」を見ることは不可能だ。だから、「今」は脳が、ある特定の時間の過去と未来予測から作り出した「虚像」でしかない。
私が40年前以上前コンピュータに出会ったとき、一番最初に教わった概念がタイムスライスだった。ちなみにこの概念を説明するのは難しい。
それに、このタイムスライスのアルゴリズムを組み立てられる人は、ハードウェアのアーキテクチャを熟知したハッカーしか居ない。
でも、アルゴリズムよりも、コンピュータのプラットホーム上のタスクが、人間の脳と同じように、時間に区切りはなく動き続けていると勘違させているタイムスライスの技術の方が重要だ。
それから、コンピュータのタイムスライスを実現させるために必要な処理がある。それは「アイドルループ」だ。
コンピュータはこの「アイドルループ」を実現するために電源OFF（もしくはスリープ）になるまで永遠ループしている。
つまりここで言いたかったのは、人間の脳もタイムスライスに近い機能があり、脳もある特定の時間でタイムスライスしているから「今」を感じられる、ということだ。
そして、人間の脳もコンピュータと同じで永遠ループしているはずだ、そしてそのループは人が死ぬまで続いている。
タイムスライスを実現するために必要なハードウェアのアーキテクチャは割り込みコンテキストだ。割り込みコンテキストはハードウェアとソフトウェアとの通信インターフェースだ。
ハードウェア（CPU）は外部及び内部からのシグナルを感知すると、ソフトウェアの都合などお構いなしにソフトウェアにシグナル通知するため、割り込みコンテキストプログラムを強制的に呼び出す。
その際、ハードウェアはソフトウェアを信用していないので、コンテキストプログラムに対してタイマー監視を行う。そして、ソフトウェアがタイムオーバーになると、ハードウェアは
容赦なくフリーズする。
割り込みコンテキストの処理は、この限られた時間内にハードウェアが設定した外部情報（たとえばストレージデーター）をプラットホーム上のタスクが見えるメモリーにコピー
し、タスクに対してハードウェアからの通知があったことを知らせ終了する。そして、通知（イベント）を受けたタスクはハードウェアの監視受けない仕組みでで仕事を行う。
これを実現するためプラットホーム（OS)は、ハードウェアからの通知域、タスクが参照更新できるメモリー域を管理しなければならない。これを管理するためにのハードウェアのアーキテクチャにPT（ページテーブル）
が存在する。（このPTで管理するメモリーサイズはページ（4096バイト）で、機械的に管理することができる）要はオペレーティングシステムの主な処理は割り込みコンテキストとPT（ページテーブル）
の管理といっても過言ではないだろう。
しかし、人間の脳にはPTは存在ない。でも記憶は潜在意識の奥深くに保管されているから、PTのように機械的な管理でない方法で記憶を管理していることは推測できる。 '80年代エキスパートシステムを一緒に開発していたNTT研究所の研究員が「人間の脳細胞は、コンピュータのメモリーではなくCPUに近い」と教えてくれが、 もしかすると脳はコンピュータ(CPU)のPT（ページテーブル）より複雑な方法で記憶を管理しているのかもしれない。
人間の脳は、何もしていないとき、つまり「ぼーっ」としているとき一番活動しているそうだ、そのときの状態を「デフォルト・モード・ネットワーク」というそうだ。
そして、この「デフォルト・モード・ネットワーク」は永遠ループしているらしい。主観だが、この永久ループにより「今」という虚像を作りだしていると思う。
私は趣味でアニメションプログラムを作成している。ご存知のようにアニメションプログラムは画像をある間隔で書いては消しの繰り返しを行い、人間の残像現象を
利用し静止画が動いているように見せる技術だ。そして、フレームの切り替え時間は映画のフレーム数（24/１秒間）と同じようなるように33msで行う。
アニメションプログラムを作ったことがあるすべての人が経験するのことだが33msで静止画像が作成できなかた場合当然コンピュータはフリーズする。その際のスクリーンは作成途中の画像で
流れるように乱れる。
話は変わるが私は糖尿病で、現在血糖コントールのため薬を服用している。この薬の最大の副作用は低血糖だ。この低血糖は最悪意識を失うので、医師に「自分は糖尿病患者であるこを証明する
ものを身につけておくこと」と言われていた。そんな中夕方コンビニの商品棚を見ている時、見慣れた画像が現れた。それはアニメションの静止画を時間内に作成できず、コンピュータがフリーズ
する直前の画面に似た画像が流れる事象が自分の脳内で発生した。「これは、低血糖による病状だ」と思い糖分補給を行い座って安静にして遠くを見ていたらいたら、低血糖は収まった。
私はこのことからデフォルト・モード・ネットワーク（永遠ループ）は現在という虚像を作るために最も重要な機能であり、低血糖のような脳内に十分なエネルギーがない場合、
正常な虚像を作成できないと認識したとき、脳は自分を守るため意識を失うのだろうと悟った。
そして、この事象は俗に言う「目まい」だと直感した。
上記コードは低血糖で経験した「目まい」をヒントに作成したコードだ。原理は簡単で過去のフレームを現在のフレームに重なるように時間をかけて消えるようにしただけだ。このコードにが「目まい」の疑似体験になると思う。