orange @[email protected]

英語版の記事は最後までただで読めた＞＜
Jumbled-up sentences show that AIs still don’t really understand language | MIT Technology Review https://www.technologyreview.com/2021/01/12/1016031/jumbled-up-sentences-ai-doesnt-understand-language-nlp-bert-fix/

中国語の部屋を見て「この部屋は中国語を理解しているのだろうか？」は、そのまま元の思考実験かも＞＜
『中国語を話せない部屋』を目の前に「この部屋は中国語を理解しているのだろうか？」って、内部的には理解しているという可能性の話を別として、客観的には「理解しているわけないやろ」(なぜかインチキ関西弁)かも感＞＜

勿論、命令を理解できないポンコツな人は多々居るけど、命令を理解できる人もいるわけで、今回の話で言うと、それで言う命令を出来る人の水準に達していないということで、
中国語の部屋の例えで言うと、そのAI()は『中国語が話せない部屋』であるって話であって、「中国語を話せない人だっているじゃん！」って言っても「それはそう＞＜；」
かも？＞＜；

無粋にマジレスすると、この話自体はそこまでいく以前の、人間の言葉を解釈して行動するマシンが、人間が言葉を解釈し命令通りに行動する程度の十分な柔軟性を現時点では持ち合わせていない(学習されていない)ってことでは感＞＜

ていうか、Googleのいくつものサービスがnotを無視して逆の意味に解釈したりするのも、結局の所、文中のどこをnotで否定してるのかちゃんと解釈できてないみたいな感じとかなのかも？＞＜

それはそう＞＜(？)

語順を理解してないっぽい？ということは人工無能のすごいやつのままってことかも？＞＜

.NetのVMとか(たしか)JavaのVMもスタックマシンなので、中でこれと同じようなことしてるはず＞＜

(関数)電卓の作り方の一番メジャーなやり方がこれかも＞＜

普通の記法からRPNへの変換は、各要素に重みをつける＞＜
重みは数値の方が重くて演算子が低い、演算子同士は優先する演算子が重い、括弧の中身はさらに重く＞＜
で、重みでソートするとRPNになる＞＜
(リバースじゃないポーランド記法への変換はやったこと無いので知らない＞＜；(計算機上での実用上はRPNの方を使うのが有利すぎてリバースじゃないポーランド記法ってまず使わない気がする＞＜))

普通の(？)記法: 1+4*(1+2)
RPN: 1 1 2 + 4 * +
1積む1積む2積む、+が来たので2個取り出して(2と1)足して結果(3)積む、
4積む、*が来たので2個取り出して(4と3)掛けて結果(12)積む、
+が来たので2個取り出して(12と1)足して結果(13)積む

あってる？＞＜；

RPN、スタックに積んでって演算子(命令)が来たらスタックから取り出して計算してまた積むって繰り返すだけで処理できちゃう＞＜
ので処理する計算機(スタックマシン)もかなり単純な構造で作れちゃう＞＜

RPNの処理は超簡単だけど(関数電卓アプリを作ろうとすると実装することになる)、
ポーランド記法からRPNの変換もかなり単純にできたような気がしなくもない＞＜(自信無い)

この系統の配信で歌を通しで聴けたの初めて(いつもは「うん＞＜；」って閉じちゃう)という意味でも、あれだけど、1曲目は生かもしれないけど2曲目先に録った音だよね感＞＜
(歌う前に下手って言ってたから「おう？＞＜；」って思ったけど、超上手いわけではないけどこれを下手って言ったら他の方々の立場が＞＜；)