tenjuu99(天重誠二)

NHKの災害時モード、私の環境では終始こんな感じだった

@pokarim 自分も、関数だろうとOOPだろうと道具立てがそんなに変わるわけではないでしょう、とおもっていたのですが、細かく検証すると意外と関係あるかも...と思ってきました。そもそも、テストコードを「<主語>は<述語>する」みたいに把握していたこと自体が、OOP的カルチャーからでてきたんじゃないかと思いはじめています。

AIに構文ギャップについて聞いてみたら、それは考えられるという話で、関数のほうで考えると verb(subject) みたいな関係になるよね、という話で、こうなると「ドメイン」という言葉も「定義域=関数の引数が取り得る幅」として捉えなおしたほうがいいのではないか...などという話になりました。たしかに、これは「パラダイムが異なる」と言うにふさわしいなと、いまさら考えています。

@pokarim はい。あと、テストが「テンプレートマッチャーはxxxできる」みたいな「<主語>は<述語>できる」みたいな構文があるとして、これをOOPであれば「<クラス名>は<メソッド>できる」に変換できますが、関数だと「<関数名>は<述語>できる」の述語の置き場がないか逆に「<主語>は<関数名>できる」となって主語の置き場がないかになる、という構文のギャップもあるかもしれません。実装に意図があって関数を選んでいるわけじゃないのですが。

@pokarim そうですね、たぶん意味を欠いた状態でプログラムを過剰に学習しているからこうなるんだろうという気はします。

@pokarim いまの構成としては、辞書ファイル、テストコード、実装という3層でやっていて、意図としては、それぞれ実装(コード)の指示対象がテストコード、テストコードの指示対象が辞書内語彙、みたいな関係でやっています。それで、辞書とテストを繋ぐことはできるんだけど、実装とテストの関係の調整がいまいち難しいなと感じています。 「テンプレートマッチャーはxxxできる」みたいなテストケース名が書かれて、でも実装は matchTemplate という名前でできている、みたいなギャップが発生しがちです。このギャップを埋めるために、日本語じゃなくて英語で 「templateMatcherはxxxできる」って書いて、と指示を出しておいたら、今度はこの templateMatcher の実装の説明しかしない、みたいな感じになります。実装コードへのフォーカスの当たり方が強すぎて、意味把握の領域に至らない。自然言語を操作している段階ではどうみても単語の操作ができているから、語から意味を志向するという作用はあきらかに働いているんですが、対象となる記号がコードとなってみると、この意味への志向性に欠いた振る舞いをしてしまう、みたいな特性があります。

ていうか実装(コード)をシンボルの階層構造と見做してほしいんだ。そういう見方が成立すれば、目の前の記号(コード)から意味を類推していくという理解になっていく。のだが、現状では、目の前の記号/コードをそのままコードとして受け取っていて、だからそのコードがどう動作するかは説明できても、そのコードの意味を説明できない。

AIに思考させるにはシンボルが必要なんだけど、AIは実装としてはシンボルを必要としていない、というギャップがたぶんある。だから、実装上の識別子が具象であると同時にシンボルとして扱われるように理解させたい(?)

@pokarim AIにとって、matchTemplate みたいな関数っていくつかの具象の組み合わせによって再構成できることがわかっているから、 matchTemplate という名付けられた関数自体が不要と判断されたりする。のですが、そうすると、AIが思考の焦点/とっかかりを失ってしまう(スクリプトのなかに埋めこまれた matchTemplate 的な振る舞いをそれとして取り出すことができない)。それで、「先に名付けさせる」という行為を試して、その通りに実装しろ、という手順でやらせてみているんですが、名付けと実装のフェーズが違うと別作業だと認知してしまう。実装上の関数とかオブジェクトとかと、概念との紐付けを行いたい、みたいなのことを最近検証していたりします。

@pokarim まさにそういうことがやりたいんですが、AIにそれを構成させようとすると、実装のような具象物と概念との区別が難しいなと感じているところです。記号が関数に書きおこされると実在化しちゃって、意味の領域が削ぎ落とされてしまう、というか。

名前をつけるのは存在させることと同じだって何回言わせるんだ、既存のものを取ってくるのをやめろ

このやり方ならいけるやろと思っていくつか試している開発フロー、おおむねは上手く動いているんだけど、微妙なところで概念と実装のつながり/差異を処理できない。たとえば「テンプレートマッチャー」という概念が辞書に登録され、実装が matchTemplate になっていると、同一性が認知できず、じゃあといって 「matchTemplate はxxできる」とか辞書に登録させようとすると、matchTemplate の実装上の振る舞いを後追いで説明するだけになる。ていうか、辞書定義するときには名詞(テンプレートマッチャー)なのに、プログラムを書くときには動詞(matchTemplate)になる、というあたりにもう微妙だけどおおきなズレがある。ようするにプログラム側では用途の区分しかされていなくて、名前への拘泥りがゼロになっている。

これちょっと気になるんで見に行っとくかな https://www.tokyoartbeat.com/events/-/Painting-and-Women-in-the-Early-Modern-and-Modern-Eras/B332-C484/2026-06-15

天幕のジャードゥーガルのアニメの宣伝流れてた

やばい

松井氏は長崎県出身。高校卒業後、自民党の麻生太郎副総裁が関係する麻生グループ運営の専門学校でソフトウエア開発を専攻した。卒業後はグループ中核の株式会社「麻生」に入社し、政治への関心を深めていった。「当時は麻生さんが首相になり、盛り上がっていた。民間企業だが、政治イベントや選挙になるとみんなで応援し、日本が変わることを体感した。自分も政治に関わりたいと思った」 https://news.jp/i/1436918911637159966

ルネサンスの画人たちが「遠近法はなんと甘美なものだろうか」とか言ってたとかなんとか、うわ～ヤバい人たちだなとか思ってたけど、いまのAIがほぼそれだな

進次郎が戦艦三笠の模型をインドネシア大統領に送ったの、どうやったらそうなるのかまじでわからない

ていうか小泉純一郎が首相だったときの支持率の高さはわかるというか、そういう空気だったけど、高市にまったくそういう異様さがないのに数字だけ高いっていう意味がまじでわからない。

もうさすがに3%くらいになってるだろうとおもってた

高市の支持率70%くらいあるらしくてすごすぎる

ダン・グレアム展中止、残念すぎたので前ニュースレターで書いたコラムを無料公開します。

【しばらく全文無料公開】遅延派通信番外編：ダン・グレアムについて（キム・ゴードンと共に） https://note.com/imdkm/n/nb34b4992f823?sub_rt=share_pb

別にAIに限ったことではないけど、労働の分業は全体を小タスクに分解して、労働者は「なんかよくわからないが指示通りにハンドルを握っている」みたいなことはたぶんしばしばある。近位項から遠位項が見えていない状態で、キーボードだけみて画面は見ていない、みたいな。近位項と遠位項の配置を整えるというのは、キーボドと画面の関係をセットしてやるみたいなこと。

わたしは結局AIに暗黙知はあると考えていて、AIとの対話がある程度自然な形で成立するのは、文脈(これまでの話の流れとか)という背景(=遠位項)を遠目に見ながら、ある言葉を配置することができるからで、これは近位項を握って遠位項に注意の焦点が当たっている状態である。これはポランニーの言う包括的理解(comprehend)が発生していると言えるとおもう。ハンドルを操作して車を運転することができる、みたいな関係の了解(comprehend)が暗黙知なのであってみれば、AIはこういう関係の了解は可能で、問題はそれを可能にする配置を整えてやることであるとおもう。ハンドルに捉われがちな近視眼性はまだ強いとおもうけど、たぶんモデルの高度さに拠る。

おう…

Statement on the US government directive to suspend access to Fable 5 and Mythos 5 \ Anthropic
https://www.anthropic.com/news/fable-mythos-access

この問題、トリグヴェ・リーンスカウクが、現在のプログラミングパラダイムは、要素を作ることができてもその要素がどう使われるかを記述する場所がない、と批判していたことがそのままあてはまるとおもう。彼は、それでDCIアーキテクチャーを考えて、部品としてのオブジェクトと、それらが相互作用する場(context)をプログラミング上の概念として持ち込もうとしている。関数とかオブジェクトとかは、あるコンテキストにおけるroleとして役割を与えられる。これは部品ではなく全体を記述するための手段を考えたらこうなったんだとおもう。

これ上手くいくかはこれから検証するけど、マイケル・ポランニーの近位項、遠位項、包括(comprehend)という概念を導きの糸にしている。自分の理解が正しいなら、たとえばいまSNSに投稿しようとしているとき、対象として認知している画面内のSNSストリームとか入力欄の文字列とかがあり、手元にキーボードがある。意識の焦点となっているのはこの画面内の文字とかSNSのストリームとかで、こちらが遠位項、これを操作するためのこの手元のキーボード操作が近位項で、人間はこれらを全体として了解している、つまりキーボード操作がなにを意味するか了解している。こういった全体性の把握を comprehend と呼んでいるとおもう。

https://note.com/hiroimasaharu/n/n1783e2ff038c

この記事では「近位項で遠位項をつかまえている、把握している、意味化している、統合的な包括理解を行っている」と書いていて、そういう関係性。

AIが小問題を解決するための道具(ある名付けられた関数とかオブジェクトとか、プログラミング上で名付けうるもの)を案出して、その「関数を使って問題を解く」とき、この問題をとくための機械には名前が付けられていない。このとき、この関数は近位項なんだけど、たぶん遠位項が把握できていなくて、関数はテストを通過するものであるが、それらを合成したときの「何か」みたいなものに名前がついていないと、ずっと関数のほうに着目してしまう。これが、AIが全体を了解していない仕組みではないかと思われる。

そうであるとすると、階層化関係を構築するようにして、近位項・遠位項の関係をつねに意識させれば良いのではないか、というのが、いまのところ考えていること。

コーディングエージェントでの実装、最初はガーっとやってくれていいんだけど、次第に行きづまることがあり、その理由はAIが自力で階層化設計を案出しないことにあるんじゃないかということを検討している。 AIの問題解決方針は、問題を小問題に分解して、その小問題を解くための関数を作り、関数を組み合わせて全体としての問題が解けるかどうか試す(か、人間に試してもらう)、というわりとオーソドックスなものだとおもうけど、「小問題を解くための関数」には名前がつくけど、これを利用する場所はただのスクリプトで、ここに名前がつかない。部品を作るんだけど、部分がつながった状態の全体には名前がないから、全体というものをまず認識していない。それと全体と部分の関係の調整もできないし、全体的な構造を変えたいときに、部品に捉われて全体の構造が以前のものを引き摺りつづける。 で、これは「つくるべき全体」に名前を与えてやれば解決するんじゃないかと考えて、試してみる。全体に名前を与えて、それを構成する部品を案出させる。全体と部品のレイヤー関係を自分で案出するようにすればいいんじゃないか。

画家のデビッド・ホックニーさん死去、88歳　英国現代美術の巨匠
http://www.asahi.com/articles/ASV6D4H41V6DBQBQ1DRM.html?ref=rss

#asahi #朝日新聞デジタル #国際 #ヨーロッパ #文化_芸能 #アート #おくやみ #朝日新聞 #ニュース #新聞

"「政治家を中傷した」との批判に対し、松井氏は「法令違反はなく、欧米では当たり前に行われている『世論操作』の一環だ」と、正当性を主張している。"

……滅んでほしい。

「松井さんのおかげで勝てた」自民総裁選、高市氏秘書から小泉氏批評動画で謝意　衆院選でも「ネガキャン」証言、「世論操作の一環だ」「全て無償」作成者を駆り立てた動機とは… | NEWSjp https://news.jp/i/1436918911637159966

アウラの消失とか、実は文章の中では相対的にどうでも良い要素だったんじゃないかという気もする

明日の授業準備でベンヤミン読み直したけどこれめちゃくちゃ反戦と芸術の論文なんだよな（最後の章で突然ファシズムとマリネッティ批判を行い「共産主義は、これにたいして、芸術の政治主義をもってこたえるであろう。」と言って終わる）