Blind Spot in the Development Languages I Use

 The development languages I use are mainly four:

C, C++, Python, and JavaScript.
But I think there is a blind spot in these languages when I try to develop Atron.
Most programming is built on a very ordinary flow:

input
↓
process
↓
output

Input, decision, processing, output.

That structure works for many things.
But I think it actually makes Associatron harder.
The research I am doing should not bring that ordinary structure into itself.
That normal order, that almost novel-like order, really gets in the way.

Humans are irregular.

“Seeing,” “feeling,” “words,” “anger,” “laughter” — these do not come in a fixed order.

Seeing is not always first.
Hearing may come first.
Pain may come first.

For example, when I was a child, I practiced judo.
There was an unpleasant senior student who would throw me for no reason.
Because of that, on the days I had judo practice, I already felt depressed from the morning.

The actual event lasted maybe five minutes.
But for me, I worried for ten hours.

Not only humans. Animals also have trauma.
Input does not always begin with a beautiful morning.
Sometimes it begins from a lingering depressed state.

Even after danger is gone, the body remains in a state of vigilance.
There is still the anticipation that it may happen again.

In psychology and neuroscience, this is called hypervigilance.

When I develop Atron, which is something like a semi-living entity, I have to think of emotion and object as separate things.

There is a world.
Stimuli come from the outer ring of that world.
Internal states change.
Then there may be action, or there may be stagnation.
And when it returns again to the world, what remains may be fear, or depression, or a kind of halted state.

Why does anger continue?
Even if something comforting suddenly comes close, anger is still anger.
If I make my girlfriend angry, it would be nice if ice cream alone could immediately fix her mood.

But that is not how it works.

It continues for a while.

I have to show my own state that I am sorry.
I have to take several actions to repair the situation.

But in general programming and algorithms, you end up having to write absurd conditions like “take calming actions three times or more.”

That is not intelligence.
That is just making things bigger.

Atron is not like that.

Anger, fear, and enjoyment change through experience, arousal, outer-ring stimuli, and time.

When she is angry, and then I receive some award, a change happens in her too.

Or she may still be angry, but if her friends gather around her, the essence of the anger does not completely disappear, yet the anger itself begins to dissolve.

Threat bias changes into calm bias.

That is not an algorithm.

In ecological terms, that is close to the dilution effect.

Algorithms are usually:

event → reaction → result

But living systems are more like:

event → emotion → memory → next event → change

And on top of that, there is persistence.

There is dragging.

Sometimes the internal state changes, but nothing is expressed outside.

It is the same, but it is being carried as a different kind of reaction.

That is why, through experience, timid individuals appear, bold individuals appear, easily angered individuals appear, and curious individuals appear.

There are also times when emotions influence behavior separately from associative recall.

The rules and order of programming interfere with that.

Algorithms interfere with that too.

That is why, if I want autonomous first-person robots to live in matrix-like worlds or in the real world, I may need to create the development language itself.

Not just another programming language.

A development language for Atron.

A language that does not begin from input → process → output.

A language that begins from a carried-over state.

A language where internal states persist, interfere, overlap, and change over time.

A language where fear does not vanish just because the event is over.

A language where calm does not mean the essence of anger is gone.

A language where visible output is not always necessary for internal change to exist.

A language where what matters is not just reaction, but what remains.

That is the kind of development language I think Atron needs.

開発言語の盲点　C言語、C++,Python,JavaScript,メインはこの４つだけど、普通プログラムってのはinput  → process  → output　の順番でしょ？

入力、判断、処理、出力・・・
どうもこれがアソシアトロンを余計に難しくている。
僕のやっている研究は、その普通を持ち込んではいけない研究で、その小説のような順番が、本当に邪魔なんだ。

人間てのは「見る」「感じる」「言葉」「怒り」「笑い」って順番が不規則でしょ？

必ず見るが先ではない。
聴くが先かもしれないし、痛いが先かもしれない。
例えば子供の頃、柔道をやっていて、嫌味な先輩がきて理由もなく僕を投げ飛ばす。
なので、柔道を習う日は朝から憂鬱になる。
実際は5分程度の事だったけど、僕にすると10時間は悩んでいた。
人間だけではなくて動物にもトラウマってのがある。
インプットは素晴らしい朝から始まるわけじゃないんだ。
憂鬱を引きずったろころから始まる。
危険が去っても体はまだ警戒状態にあり、「また来るかもしれない」という予期が残る。
この状態は心理学や神経科学では hypervigilance と呼ばれてるでしょ？　

Atronを開発していると、半生命体なので、感情とobjectは分けて考えないといけないんだよ。世界があって、その外輪から刺激が加わる。内部状態が変化して、行動か停滞し、また世界に戻った時、恐怖とか憂鬱という停滞かもしれない。　

怒りってどうして、続くのか、いきなり安心素材が近づいても怒りは怒りだよね。
彼女を怒らせて、アイスクリームだけで機嫌が直ってくれればいいけど、そうじゃないでしょ？しばらく続く。怒らせて悪かったという僕の状態も見せなきゃいけないし、機嫌を直す行動も幾つもする必要がある。
でも、一般のプログラミングや、アルゴリズムってのは、3回以上機嫌を直す行動を取れとか、おかしな条件を幾つも入れなきゃいけないでしょう。ただ単に3人称の命令を膨大にしてるんだよ。　

　Atronってのはそうじゃない。　　
怒りとか怖さ、楽しさは経験や覚醒、外輪、時間によって変化する。　
怒っていた時に僕が表彰されると彼女にも変化が起こる。
もしくは彼女が怒っていたけど、彼女の友達が集まると、怒りの本質は消えないけど、怒り自体は解消されていく。

脅威バイアスが平静バイアスに変わっていく。
アルゴリズムじゃないよ。生態学的に言うと、 dilution effectの事だよね。

アルゴリズムってのは、出来事、反応、結果。
だけど、出来事、感情、記憶、次の出来事、変化があって、引きずりってのが加わるんだよね。だから状態更新はしてるんだけど、外に数値を出さないこともある。
同じなんだけど違う反応としてひきずってるんだよ。
だから、体験によって臆病な個体が生まれたり、大胆な個体、怒りやすい個体、好奇心が強い個体が生まれる。　
連想想起とは別の感情に影響されることがあるんだよ。　
プログラミングのルールや順番がそれを邪魔するんだ。　
そしてアルゴリズムが邪魔をする。　
だから、一人称のロボットとして自律させたときに、マトリクスや現実の世界で生きてもらうためには開発言語自体を開発しなければいけない。

-------------追記--------------

ブロガー使ってる理由を別の研究者の方々からよく聞かれるんだけど、あんまり理由は無いんだよね(笑)　そう、数式やcodeが載せられる！！
今はどれも出来るか・・・ｗ
これGoogleなんだけど、検索には引っかからないしね、それでいいんだよ、検索で上に上がってもらうと困る。論文が上位にくるでしょ。自分のノートだし、noteとかなんか星マークとかそういうんじゃないんだよね。

あと、論文調じゃないのが気になるみたい。
なんでだろうね。

アソシアトロンの論文は全部読んでるけど、もう論文の段階じゃないんだよね。
中野先生の1972年の論文と、森田先生の90年代の論文以上の論文は書けないよ。
アソシアトロンはそこで線引きするよ。

なぜって、僕が研究しているAtronは
常に状態が変わるし、誰も同じ研究結果にならない。だって一人称になってからは、半分生き物だから、毎回違う答えを出すでしょ？論文にならないじゃん。
PCの中でスタート押して停止ボタンをさなければロボットたちは、ずっとうろうろしている。ライオンから逃げたり、森の中で何か食ってる。3人称のロボットの言語を真似しようとしている。外輪のワールドは、ロボットたちが居なくても勝手に動いているんだよね。
こんなの論文にしたところで再現できないから詰じゃん。
学者さんも興味ないでしょ。

いや、文体を学者さんたちが好きな論文調にすることはできるし、数式にもできるけど、僕のこのブログの役割は付箋なんだよね。ゴミメモをちょびっとだけまとめたもの。
自分のため、同じ研究仲間のため。それ以外にないよね。

しかも、今の学会や機関の評価基準とは別なので実際に現物が活躍するって1点以外に興味はないよね。論文に時間をかけるならRPGゲーム世界で自律1人称キャラでどう動くか試すとか、実社会でどう活躍するとかの方が面白いじゃない。
上でも書いたけど、引きずるロボットだし、失敗から学ぶので痛みが分かるんだよ。なので試合に負けた孫に寄り添うとか「悔しくないのかよ！」とか、子供達と一緒に体験して成長するロボットなので、１００％命令に従う優秀なロボット達とは違うんだよ。今のAIの真逆をやってるからね(笑)

評価を気にするところから離れないと、自律一人称システムって出来ないよ。だってその中身にベンチマークやスコア、最適化が無いからね。

もう、マジで開発言語自体を作る必要がある段階なんだってばさ。

今のC++とかPythonもJavaScriptは必要なんだよ、神経回路、伝達（インフラ）にはアルゴリズムは必要。でも、半生物の記憶はアルゴリズムじゃない。引きずる偏りバイアスってのは想起と同時に動くから分ける必要があるし、競争させるものでもないからね。緊急速報だけで地震のトラウマが蘇るじゃん、あれは想起に関係しているけど、心拍が上がる、身体が固まる、周囲を確認する、不安や恐怖が一気に戻る

cue（緊急速報の音）

↓

過去の経験が結びついた想起

↓

身体状態・感情状態が同時に立ち上がる

これって競争して選ばれてるわけじゃないんだよね。
なので、ロボット達はそれぞれの体験によって
臆病な個体
大胆な個体
怒りやすい個体
好奇心の強い個体
のロボットが出来上がる。

ケース・スタディではないんだよ。

© 2026 C-Side Research Laboratory / Yukihiro Watanabe. All Rights Reserved.
No unauthorized reproduction or redistribution.

うちの開発言語について

 とにかく僕は開発言語には拘ってない。
外部の助言はあるけど、やってることを説明するのが大変なので
けっこうスルーしてるかな・・・。

こういうネットでデモやるならJavaScriptみたいのでいいし、
ある程度の骨格がつかめたらPythonに落とす。
普段の実験ならPythonでいいし。

ガンガン回して実験結果を見て判断するのはPythonとC++かな。
C++は大規模ノードでどうなるか、長時間回したときの安定性、数値誤差の影響、つまりは現実条件での検証に最適なんだよね。
今のところ、JavaScriptで思想作って、Pythonで回して、C++が現実みたいな。

Atronは

• 成長

• 不可逆性

• 体験の蓄積

• 長時間の変化

つまり短いテストでは分からないんだよね

Python：探索　　C++：時間を回す

それと、数式をcodeに落とし込むならC++は理想だよ。
ロボット研究者に多い。

例えばAtron的な式：

$$x_i(t+1) = f\left(\sum_j w_{ij} x_j(t)\right)$$

これをC++にすると

--------C++--------

for (int i = 0; i < N; i++) { double sum = 0.0; for (int j = 0; j < N; j++) { sum += W[i][j] * x[j]; } x_next[i] = f(sum); }

ほぼ、そのままじゃん。
微分方程式系もそのまま書ける

$$\frac{dx}{dt} = -x + f(Wx)$$

オイラー法なら

for (int i = 0; i < N; i++) { dx[i] = -x[i] + f(input[i]); x[i] += dt * dx[i]; }

C++は研究者向きなんだよね。

森田先生の非単調
--------C++--------

double f(double x) { if (x > theta) return 1.0; if (x < -theta) return -1.0; return x; }

エネルギー関数

--------C++--------

double energy = 0.0; for (int i = 0; i < N; i++) { for (int j = 0; j < N; j++) { energy -= W[i][j] * x[i] * x[j]; } }

Atronは数式の時間発展が人格になるのでC++は理想かな。
Pythonは使うよ。ただ、長い時間回すとなるとさ、

--------Python--------

for i in range(N): for j in range(N): sum += W[i][j] * x[j]

ループで死ぬ。
このタイプじゃない方法があれば教えてほしいんだけど、C++の 10〜100倍遅くなる。
（マジで誰かいい方法あったら教えて）

いきなり完成品を作れよ！とか言われたらそりゃCとか選ぶんだろうけど、研究室で試行錯誤を回すための言語とは思えない。今から畑耕して土触って今年の気候判断して「植えるもの変えよう！」とか、やってられない。

けっこうCを助言してくる人多いけど、
ほれ、こういうの説明するのめんどくさいから「流石ですね、そうですね」で終える。

C / C++ / Python の思想比較

言語	世界観
C	自由。責任は全部あんたさ
C++	自由＋秩序。選ぶ
Python	秩序。危険はさせない

 

この前、TurboC触った時に計算資源が少ないからさ、「ルールで済ませちゃおうか！」って思考が働くわけよ。あれは危ないと思ったよ。うかうかしてたらアルゴリズムになってしまう。僕の研究はアルゴリズムじゃないからね。3人称とか入れられないのよ。Atronの「一人称の競合・揺れ、正解が無い」なので、それを潰すわけにはいかないのよ。デバックが大変だしね。
ただ、あれのいいところは"何が本質か"がはっきり出るところだよね。

なので、場面場面で使う言語は変わる。

本当はさ、昔のHypercardみたいのでもいいと思ってるだ。
漢字talk6.7くらいの覚えてるけど、めちゃくちゃ楽しかった。
大規模数値計算つーか、ポッピーみたいな（Hopfield的な連続計算）ものとか、
行列演算・エネルギー最小化、高速な反復シュミレーションが出来ないだけで、それが出来たら、全部やめてHypercardでいいと思うくらい(笑)

スタックという概念が最高にいい
stack＝経験
script＝内部力学
card＝状態
button＝行動
Link＝連想
とか出来るじゃん。

本当は、こういうのでガンガン回して収束比較とかしたい。
たぶん実験成果が上がると思うんだよね
でも、カメラ駄目、センサー駄目、外部危機駄目じゃん。
だから、本当にオシイと思う。
あんないいものを、なんで終わらせたのか、よく分からない。
CPUやGPUを意識せず、世界と記憶だけを作れるHyperCardあったら買います！

開発言語とは関係ないけど、FileMakerも実験室のように、ある程度外部データを送り込むものに使っているけど、Webビューアーのボトルネックとか、なんかクラリス・スタジオとか更新される機能がよく分からなく、かえってPython単体より構造が複雑になる傾向があるので少し離れてる。だから、FileMakerはGanttと論文や資料のPDFのフォルダ管理、文献管理、気になったらFMから立ち上げて・・・みたいな。
頭の整理にはObsidianと両方使ってる

普段使うエディタなんてnotepad++とかVSとか
共同研究者とまではいかないけど、テキスト書くのもnotepad++使ってるよ。
Emacsまでは要らないし・・・


でも、ゆくゆくは3Dゲーム屋さんとの連携があるので、

ゲームエンジンとIDE

3Dワールド（Unity / Unreal）
↓ センサー情報
Atron Core（Python / C++）
↓ 行動決定
3Dワールドに返す

つまりは、３Dがシーンによって外界になるってこと。

アソシアトロンと3Dは、一体化させるつもりはないよ。
だって別物だもの。3人称に引きずられたら、Atronは終わるからね。
NavMeshで最短経路とかState Machineで行動制御とかやっちゃったらもう僕の研究じゃなくなる。

Atron = 内部（意味・記憶）で、外界（３D）の中で経験を積むみたいなシーンもあれば
現実の映像や風景、人の会話での経験も積む。

これを守れてるかで、一人称か三人称かが分かれる。

• 3D側に「賢さ」が入ってないか？

• 3D側が「正解の行動」を持ってないか？

• Atronが迷ってる時に、3Dが助けてないか？

• 行動が“目的最適化”に寄ってないか？

• 誤学習や固執が、そのまま世界に出ているか？

だから、自律が完成しても自律はスタートであって、その先を間違えたらただの鉄屑で終わってしまうわけ。

---------------追記----------------

Pythonは　NumPyだ。これで速くなる

x = np.array(現在の状態ベクトル, dtype=np.float32)
new_x = W @ x 

ふんわり説明 その１

 やったー２月だ！
特に意味はありませんが・・・

なるべく難しいものを省いて説明します。

なぜ JavaScript ではなく Python か

今まで、公開したものは非常に簡単なデモ、構造的に理解するために
index.html一発で開ける軽めのものを作ってきましたが、
実験のプロセスや結果によって今後改良を加えるとなると、
配列というものを主語にしていかなくてはいけなくなります。

今回のAssociatronのコアは64×64 の uint8　です。

それを（できれば）ベクトル化して内積・閾値・更新・反復（steps）が必要になり、配列演算が中心となります。

Python + NumPy はここが「標準装備」で、

●速い（C実装のNumPyに乗る）

●書くコードが短い

●形（dtype/shape）を固定しやすい

●npz/npy が自然に扱えるという利点があります。

JavaScriptでも typed array ではできるけど、

▲行列/配列の演算を自前で組む量が増える

▲精度・速度・バグ混入の管理が難しくなる

▲保存形式（npy/npz）との相性が弱い

という“遠回り”が出やすい。
別な言い方をすると、実験結果によって改良をするのに結果が出るまで開発労力がかかります。

ですから、研究、定義、ざっくりJavaScript、それを元にPythonで研究ソフトを作り実験をしまくり、実装はPythonとCで組立てる。　　みたいな感じです。

assoc/

├─ .venv/                         # Python 仮想環境（実行専用・研究対象外）

├─ __pycache__/                   # Python キャッシュ（無視してよい）

│

├─ app.py                         # API司令塔（LLM / ルーティングのみ）

│

├─ learn64.py                     # Learnエンジン（入力→64x64パターン生成）

├─ recall_engine.py               # Recallコア（連想収束・アトラクタ計算）

│

├─ recall_to_png.py               # Recall結果のPNG可視化アダプタ

├─ recall_from_memory_to_png.py   # 既存メモリのPNG化（確認・展示用）

│

├─ room_manager.py                # room / scene 管理（場所の台帳）

├─ year_key_logic.py              # 年代キー推定（外輪ロジック・意味寄り）

├─ ensure_scene_storage.py        # 保存先ディレクトリ整備（OS寄り）

│

├─ mem/                           # 記憶本体（npy / npz / パターン）

│   ├─ year_xxxx/

│   │   ├─ scene_xxxx/

│   │   │   ├─ patterns.npz

│   │   │   └─ meta.json

│   │   └─ ...

│   └─ ...

│

├─ web/                           # UI・表示用生成物

│   ├─ png/

│   │   ├─ original.png

│   │   ├─ cue.png

│   │   └─ recalled.png

│   └─ index.html                 # UI（JavaScript側）

│

├─ rooms.json                     # 現在の room / scene 定義

├─ 

├─ 

│

├─ tmp_recall_log.txt             # Recall一時ログ（デバッグ用）

├─ start.ps1                      # 起動スクリプト（Windows）

そこに、今後、音声、カメラ、匂いセンサーが追加されていくわけですが、各チャネル → 64×64（または固定次元）の0/1（またはuint8）に落としそれを learn64 / recall_engine に渡す・・・

つまり、コアは変えない！　「えーーー！」
アトラクタ／エネルギー最小化／収束などの同じ性質をもつアソシアトロン系じゃないと、その構造は難しい話なのかもしれません。

音声・映像・匂いって、入力の性質が全部違うもので、通常は次元数もスケールも違うし、ノイズの入り方も違う、時系列か静止かも違います。普通の機械学習だと、入力が変わるたびにモデル構造、学習方式、表現（embedding）、正規化をモデル側で吸収しないといけないですよね。

そうなるとコアが入力に依存になってしまう。

アソシアトロン（アトラクタ系）が強い理由
コアが要求するのは 同じ型の状態（state）だけなんです。

fixed size（例：64×64）
fixed dtype（uint8 / 0-1）
fixed update rule（収束則）

だけで、音声だろうが映像だろうが匂いだろうが関係ない。
違いはすべて 前段（adapter）で吸収できるんです。

「嘘だぁ・・」

いや、ほんと。
じゃなきゃ、アソシアトロンの研究は最初からやってないです。

Hopfield系（1982）は？
アソシアトロンの弟みたいな存在ですが、「コア不変」を長期に守るのは厳しいんじゃないかと思います。

現代 Hopfield（Dense / Attention型）は？
容量が事実上増える、Transformerとの理論的接続、高次元埋め込みに強い、ノイズ耐性が高い。内部が「意味空間」になると負荷になる。ベクトル空間が 意味分布依存。アトラクタに入るために、最初から“意味を持った表現”を要求する。

ここがアソシアトロンと大きな違いなので後で話しますね。

Associatron(1972)的発想

「入力は雑でもいい。同じ型の state にさえなれば、あとはコアが責任を持つ」
表現は粗くていい、意味は要らない、分布が変わっても、コアは見ない、state だけ見る。

（初めは僕も意味を持たせてましたが、これはアソシアトロンから一脱してる。というより、そこの境界を越えると全て外部命令に占領され、後に気づいた一人称から外れてしまうということで、実験の結果、少し誘惑に引っ張られましたが全て基本に戻しました。　基本っすよ、基本。ただ、誘惑は半端なく多いです）

簡単に言うと実験の結果が出ずらいので、誘惑に負けるんです。
このくらい、いいよね・・・という発想だと、必ずコアが歪み拡張で破綻します。
別名「誘惑耐性のテスト装置」みたいなものなので・・・

assoc_stage2/

├─ app.py

├─ learn64.py

├─ recall_engine.py

├─ room_manager.py

├─ ensure_scene_storage.py

├─ year_key_logic.py

│

├─ sensors/                       # ★追加：入力チャネル（外付け）

│   ├─ audio_capture.py           # 収録（マイク→wav等）

│   ├─ audio_embed.py             # 特徴抽出→固定次元化

│   ├─ camera_capture.py          # 撮影（カメラ→jpg/png等）

│   ├─ camera_embed.py            # 特徴抽出→固定次元化

│   ├─ odor_capture.py            # 匂いセンサー値取得

│   ├─ odor_embed.py              # 正規化→固定次元化

│   └─ fuse.py                    # ★融合：複数チャネル→1つのcue

│

├─ adapters/                      # ★追加：共通変換

│   ├─ to_pattern64.py            # embed（ベクトル等）→64x64 uint8

│   └─ io_formats.py              # npy/npz保存・読み出し共通化

│

├─ mem/

└─ web/

バカだろ？
と思うかもしれませんが、いや、これがアソシアトロンなんですよ。

赤ちゃんが、「ママ」と発する言葉に意味をいれたら、
育つんじゃなく、飼育になるって話。
そもそものスタートに違いがあるんです。