弱いＡＩ（人工知能）

クズは自分では何もできない。これは昔から同じってことｗｗ

やっと、規制解除されたみたいなんで、今年の初書き込み

自己組織化マップについて自分なりに、まとめたので
暇なら読んで意見くれると嬉しい。
http://www.ff.iij4u.or.jp/~ranmaru/ai/neural_memo/ai_memo04.html

ソースの方はGUIが絡むのでRuby単品では動かなくなったのだが・・・どうしようかね？
希望者が一人でもいれば、UPしようかな（コメントない、未整理のやつだけど）

>・「自然言語処理ことはじめ」荒木健治著  
>・「ヴァーチャルインファント」須賀哲夫・久野雅樹著  
この２冊、買いました
「ヴァーチャルインファント」はアマゾンの中古屋で４５円で手に入ったのが幸運でした・
オレの処理能力が低いので、少しづつよんでいます。

「自然言語処理ことはじめ」の「かな漢字変換」のところまで読んでて
日本語っていうか言語の基礎って「音」だよな？
日本語の場合だと、平仮名で「音」をすべて表せる
もうちょっと砕くと、母音と子音の組み合わせて「音」を表現できるから
「かな漢字変換」と組み合わせると別なアプローチが出来るんじゃないかと考えてる。
赤ん坊も「言葉」はしらないが「音」は常に情報として入手していることから
自然言語の基礎となる「プリミティブ」の一つにとして「音」のアプローチは有りじゃないかな？

この本に書かれてる「同じものを見つける」ことが言語獲得の基礎の１つであることは
オレも間違が無いと思っている。
あとは、経験則を適用してやると、かなりよくなる気がするのだが、
経験則の適用っていうのが、すごい難問だよな。
コンピュータ自身が経験則を発見して、適用するのがベストだと考えるけど
その手前の段階として、人間の経験則を「プリミティブ」として与えらるのがいいだろうか？

>>142
人間が短時間で自然言語を学習できるのは人間の言語獲得装置が
少ない入力から自然言語の文法を組み立てるからだと考えられています。
任意の自然言語が先にあるのではなく言語獲得装置が先にあるのです。
ですから経験則ではなく普遍文法を組み込む方が汎用性があると思います。

普遍文法
http://ja.wikipedia.org/wiki/%E6%99%AE%E9%81%8D%E6%96%87%E6%B3%95
生得論
http://ja.wikipedia.org/wiki/%E7%94%9F%E5%BE%97%E8%AB%96

クズは自分では何もできない。これは昔から同じってことｗｗ

>>143
短時間といっても、人間が１つの言語を片言の会話レベルで使いこなすのに
約２年かかることは、子供を観察していれば見えてくる。
ある程度の専門的な知識を運用、思考出来る段階までにはおよそ１５年かかる。
そう考えると、人間もたいしたことが無いのかもしれん。

＞普遍文法
ずいぶん昔にどこかのTVでこれについて語っていたのを覚えてる
「mama」という言葉を中心にして、脳の中に生まれつきの文法があるという学説だった。
生まれつき耳の聞こえない人に対して読唇術を獲得させるために手話を教えない場合があるときでも
同じ教育を受けてる人どうしで、独自の手話が生まれ、それが既存の言語から大きく離れていないことも
根拠の一つだと言っていたな。
ただ、生得的な文法とか、言語獲得装置の仕様はブラックボックスを外から観察している
オレらには、非常に不可解なもので、未だにその詳細はわかっていないようでもある。

オレが思うに、それがあるとすると、人間が得ることができる情報（音、光等）の基礎的な情報から
生得的な方法での学習で行われているはずなので、オレがやってるアプトーチとそう大きくは離れてないと思う。
生得的な方法っていうのが「同じものを見つける」だけなのか、他にもあるのか
「同じものを見つける」というのも、別なモノの見方があるのかもしれない。

あと、すべてが生得的に備わっていると考えるのも違うとおもう。
自然言語には多くの例外規則があるが、これを例外と捉えるのは
あとから学ぶ経験則に他ならない。
まぁ、オレの場合は「経験則」ってやつを、どうやって表現するかってところでつまづいてるので
こいつを組み込むのには、まだまだ修行がたりないけどね。

>>142
> 日本語の場合だと、平仮名で「音」をすべて表せる 
ちょっと無理がある。例えば「そういう」と書いても「そおゆう」という音になる。
英語等と比べると音との対応はさせやすいけど一対一ではない。

> 自然言語の基礎となる「プリミティブ」の一つにとして「音」のアプローチは有りじゃないかな？ 
「有り」だとは思うけど、そこだけでも一研究テーマになりうるよ。
（McClelland,ElmanのTRACEモデルが近そうな気がするけど）
あんまり凝りすぎると最初にやりたかったことができなくなると思う。

> この本に書かれてる「同じものを見つける」ことが言語獲得の基礎の１つであることは 
> オレも間違が無いと思っている。 
> あとは、経験則を適用してやると、かなりよくなる気がするのだが、 
経験則より先にやることがあると思う。
例えばデータ構造。情報をどのように格納して活用するか。

入力された文字列をどんどん格納していき、
また入力の都度、過去の入力から類似例を検索して出力することを考えてみる。
この時、入力を配列なんかの単純なデータ構造に格納してるようでは話にならない。
何故なら検索時間が全データ量に依存してしまうから。
《知能ある振る舞い》というならそれは全データ量にではなく類似例の量に依存すべき。

>>143
批判や対立する理論があるのに「普遍文法で出来るよ」みたいに一方だけ推すのはどうかと。

>>146
>英語等と比べると音との対応はさせやすいけど一対一ではない。
文語と口語じゃどうしても違うからねぇ
母音と子音の組み合わせまで分解すれば、いいところまで行きそうな気がするんだけどなぁ

>あんまり凝りすぎると最初にやりたかったことができなくなると思う。 
ですよねぇ〜〜

>入力された文字列をどんどん格納していき、 
>また入力の都度、過去の入力から類似例を検索して出力することを考えてみる。 
いま、このモデルを作ってるところ・・・なんだけど
あまり進んでない。
原因は、データ構造をどうするか？ってまさにそれなんだけど・・・

簡単に「単純マルコフモデル」を表現するための辞書っぽいものなら
それっぽいものができるのだけど、
それって、同じものを見つけてルール化したことになるの？って疑問がある。
活用できる方向性も、なんか狭そうな気がする。

>《知能ある振る舞い》というならそれは全データ量にではなく類似例の量に依存すべき。
これができれば理想的なんだけど、類似なのかどうかを調べるための
すべての事例をしらべる必要が出てくるので、まともな方法じゃ無理？
それに前提として、「類似例」をコンピュータ自身が発見、分類できる必要もある。
うまくやらないと、類似例AとBは実は同じルールに基づいたものなのに、
コンピュータは別なルールと思ってしまう。結果として無秩序に新たな類似例をガンガン製造する
なんて結果が見えてくる。

なんか、色々要素があるのはわかってきたけど、まだ表現がまとまらない感じだな
もう少し勉強したら、まとめ方の方向性が見えてくるかな？

4-bit-parity-check 問題とはどういうものなのか
知っている方が居れば簡単にご説明頂ければ幸いです。

>>147
> >入力された文字列をどんどん格納していき、  
> >また入力の都度、過去の入力から類似例を検索して出力することを考えてみる。  
> いま、このモデルを作ってるところ・・・なんだけど 
> あまり進んでない。 
> 原因は、データ構造をどうするか？ってまさにそれなんだけど・・・ 
> >《知能ある振る舞い》というならそれは全データ量にではなく類似例の量に依存すべき。 
> これができれば理想的なんだけど、類似なのかどうかを調べるための 
> すべての事例をしらべる必要が出てくるので、まともな方法じゃ無理？ 
別に無理な話じゃないよ。

>>148
ググった方が早いし正確だと思うよ。


しかし真面目な話が始まり出すと途端に書き込み少なくなるのな。
こっちも質問してみたい事とかあるのに返事が期待できないのが何とも…。

> > すべての事例をしらべる必要が出てくるので、まともな方法じゃ無理？  
> 別に無理な話じゃないよ。 
と言っておいて齟齬があったら嫌だから>146のモデルの動作例を具体的に書いておくw

�@文字列ABCDを入力する
→出力:なし
�A文字列aBCDを入力する
→出力:ABCD（BCDが共通）
�B文字列xBCdを入力する
→出力:ABCD,aBCD（BCが共通）
�C文字列ABxyを入力する
→出力:ABCD（ABが共通）
�D以下（略）

みたいなのを想定。
ABCDは具体的にはそれぞれ[A="犬" B="が" C="歩い" D="た"]とかになる。

>>150
�Cの状態でABCDを出力するためには
ABCD
aBCD
xBCd
の全てとABxyを比較する必要が有ります。
なので、類似例の量に依存する作業ではなく
過去の例全ての量に依存する作業になります。

作業量の話とは変わりますが
>>150のような手順で
�Aで、BCD部分をルール「ｲ」として
Aｲ、aｲ
が成り立ち
�Bの時点では
BCの部分がルール「ﾛ」
AﾛD、aﾛD、xﾛd
が成り立ち
�CでBの部分がルール「ﾊ」
として成り立ち
ルール「ｲ」に「ﾛ」が内包され、「ﾛ」にﾊが内包される
結果として、aBCdも同じルールとして処理できる・・・
って処理とデータ形式を考え中

でも、この方式だと、処理量が指数関数的に増えそうな気もするんだよね

当り前のことを言うなよ龍田君

>>151
いや、メモリは食うけど過去の例全てと比較しなくて良いデータ構造あるよ。
一ヶ所違いだったらポインタ2個辿るだけで一例を見つけられるような。
（但し格納はデータ量に応じて時間がかかるようになるけど）

>>153
君も存外お人好しだな。
君の提案を早速パクって、問題があればそのまま君に丸投げか(笑)
それを、あたかも自分が考えたかのように「考え中」だとさ。

まったく「ご提案ありがとうございます」の一言くらいないものかね。

>>153
完全一致や前方一致だと、全件やらなくてもいい処理は知ってるけど
部分一致だと、そういう処理は知らないです。
なので、いまのところ全部見る方向で考え中

Rubyは元々遅いし、検索関連は、外部のリレーショナルDBに委託できないか？
なんていうのも考え中

脳の方も手続き記憶と意味記憶、エピソード記憶は別々に保管されてるみたいだし
言語的なルール（手続き）とその意味分けた方がいいんじゃね？っていうのも考え中
でも、現状で意味と手続きって分離できる？っていうのも考え中
そもそも、意味を取得できてないんで、分離の必要ないじゃね？とか

考えるばかりで、ちっとも進まないな〜っていうのが現状
まぁ、だいぶ固まってきたんで、もう少しかな
概要としては>>151に書いたもの実装を目指してる

いやまぁお人好しなのは認める。
例えば>>147の、
> >入力された文字列をどんどん格納していき、  
> >また入力の都度、過去の入力から類似例を検索して出力することを考えてみる。  
> いま、このモデルを作ってるところ・・・なんだけど 
で正直、「嘘付け！」とか思った。
僕が>>150書くまで具体的なイメージも持ってなかっただろう、とすら思ってるしw

基本的に>>146の問題提起はある理論の存在を前提としている。
だから仮にそれを自分で考え出せるなら既に一端の研究者な筈なんだよね。
（僕自身は研究活動によって金銭を得ていないアマチュアだけど）

にも拘わらず特に指摘もしていない理由は主に2点。
�@>>139で書いたようにプログラム書いて晒したのが気に入った
�A「>>151のやり方じゃうまく行きっこないしね」と思っているw

おっとニアミス
>156に書いた通り、>151のやり方はダメだと思うよ。
ヒントはあげるから考え直した方が良い。

・類似の判定は検索の都度ルールでやるんじゃなくて格納時に抽象化によって行う
・意味なんて関係なく、字面だけで判定できる

> �@>>139で書いたようにプログラム書いて晒したのが気に入った

逆に俺は呆れたな。

作者は彼自身になっていて・・・それ自体は悪いことじゃないが、
公知のアルゴリズムをコーディングしただけの代物の作者を、自分とするような厚顔無恥な真似は
恥ずかしくて自分ではとても出来ないと思った。

「作成」が彼自身になってる事、それ自体は（多分）嘘ではないだろうし。
同じアルゴリズムでもソースは人によって変わるもんだし、
そこで個性を主張したくなっても非難する程の事でもないと思う…。
ていうか日本の著作権法上、厳密なpublic domainってのも無理だった筈。

>>80の人の良さに免じて俺からもヒントを

結局やるべきことは「キャッシュ」を作ることだ。
つまり、よく使うデータを先頭に配置するようにすればいい。

モデルは意外に身近なところにあるが２ちゃんねるの掲示板だな。
つまり入力データにマッチした過去データを「上げて」やればいい。
さらに頻繁に上がるようなデータには積分を掛けて簡単には下がらないようにすればいい。
俺は積分因子を数種類設定しているが、その主なものを「感情」と便宜的に呼んでいる。

どのような入力に対してどのように感情が遷移するかは
それは知能とは別の枠組で動くようにしているが
俺はそれを便宜上「本能」と呼んでいる。

>>156
>僕が>>150書くまで具体的なイメージも持ってなかっただろう、とすら思ってるしw 
まぁ、言い訳になるが、>>147の時点でこれの雛形（？）は作ってるのよ
データ構造がどうのこうのっていうのも、たぶんそちらが想定しているより低い次元でオレは悩んでる
なにせ「単純マルコフモデルの辞書」っぽいものから、ほとんど進化してないからなぁ

文章から代替えの効きそうな部分バラバラにして格納してるけど
それがルールとして機能するか？といわれると、たぶんしない
じゃぁ、ルールとして機能するための処理と構造ってなによ？ってところなのよ

>>157
>・類似の判定は検索の都度ルールでやるんじゃなくて格納時に抽象化によって行う 
なんか、根本的なところで、オレの考え方のボタンをかけ間違ってる気がしてきた
ナニをドウ抽象化するのか、さっぱりわからないあたりが、ヒントになるんだろうなぁ
オレがルールと呼んでるものとも違うんだろうな、調べ直しだな

>・意味なんて関係なく、字面だけで判定できる 
紹介してもらった2冊でも、言語獲得の初期段階では意味の役割が薄いような印象だった
それよりも単語の獲得、自立語と付属語の判定と分類に力を入れている感じだった

>>158-159
作成の意味はアルゴリズムの作成じゃなくてソースの作成です。
既存の概念やアルゴリズムのソースコード化も立派な仕事だと思うし
そうして出来上がったソースコードはソースコードの作成者のものだとおもう。
そういう仕事をしているプログラマさんのためにも、ここだけは譲れない。
それに、今オレが誇れるのはここだけだしね。

>>160-161
頻繁に使うデータを前方に持ってくることで、全数検索より早く検索できるっていうのはわかる
完全一致がでれば、そこで終了できるから。
類似を探す場合だと、上のほうで候補を見つけたとしても、下のほうにさらに良い候補が潜んでる
可能性を否定できない。
・・・・たぶん、オレが想定してるところと使う場所が違うんだろうな。
このあたりも、宿題だな。

と、ひたすら自己弁護に終始する龍田君であった。

折角のヒントも理解が及ばないがゆえに、想定の範囲を逸脱すると全く応用がきかないようです。
勉強とパクリの区別がつかない方達によくありがちなことです。

>>162-163
> >・類似の判定は検索の都度ルールでやるんじゃなくて格納時に抽象化によって行う  
> なんか、根本的なところで、オレの考え方のボタンをかけ間違ってる気がしてきた 
ルールで思考するってのはヒトの知能の中でも比較的後の方で表れるものなんだよね。
一般的にヒトはルールで世界を捉えようとする傾向があるけど、
それを以て「ルールで全ての知識を表現できる」ってのは間違いだと思う。
そもそもif-thenルールなんてより基本的な16二項命題操作システムの発達で説明できるもんだし。

さらに言うならルールってのは本質的にシリアルなものなので、
超並列マシンでもある脳の処理としては実は馴染まないものだと思う。

> それよりも単語の獲得、自立語と付属語の判定と分類に力を入れている感じだった
今回のモデル化についてはそんな区別すらする必要ないよ

> 既存の概念やアルゴリズムのソースコード化も立派な仕事だと思うし 
> そうして出来上がったソースコードはソースコードの作成者のものだとおもう。 
> そういう仕事をしているプログラマさんのためにも、ここだけは譲れない。 
> それに、今オレが誇れるのはここだけだしね。 
そういう考えは大事だと思うよ。
それに色んな研究者のソースを見てたら分かってくると思うけど、
素晴らしい研究している所のでも正視に耐えないものは多いし。
（コーディング技術にまで頭使ってられないのか、もしくは下っ端に書かせているのか…）

> 頻繁に使うデータを前方に持ってくることで、全数検索より早く検索できるっていうのはわかる 
どっちかというとこれはヒューリスティックに属するもんだと思う。
いずれ必要になる時があるかもしれないけど今は無くても困らないよ。

>>164-165
さすがにそういう煽りは誰の利益にもならないから止めて欲しいかな…

>>166
やれやれ、自分を食い物にしている者を甘やかすとはね、、、君が不愉快な思いをしなければよいけどね。

忠告はしたよ

別に僕オリジナルなことはまだ殆ど言ってないし、元より損は無いよ。
この程度の開示ですごいものが出てくるならむしろ利益だw
まぁそういうのは期待出来なくとも、こっちが行き詰まって質問した時に
違う視点を持ってアドバイスくれそうな人がたまに見てくれればそれでいい。

けど忠告はありがとう。

いろいろ刺激を受けて、イメージがまとまってきた。
こんな感じか？


>オレがガンダムだ
オレがガンダムだ

>私はコンピュータです
オレがガンダムだ
私はコンピュータです

>オレがジャイアンだ
オレが（ガンダム or ジャイアン）だ
私はコンピュータです

>私はガンダムです
オレが（ガンダム or ジャイアン）だ
私は（ガンダム or コンピュータ）です
（オレが or 私は）ガンダム（だ or です）
　（オレが or 私は）（ガンダム or コンピュータ）（だ or です）
　　（オレが or 私は）（（ガンダム or ジャイアン） or コンピュータ）（だ or です）
　　　（オレが or 私は）（ガンダム or ジャイアン or コンピュータ）（だ or です）

>オレはジャイアンだ
（オレ（が or は） or 私は）（（ガンダム or ジャイアン） or コンピュータ）（だ or です）
　（（オレ or 私）（が or は））（ガンダム or ジャイアン or コンピュータ）（だ or です）

>太郎はラーメンが好きです
（（オレ or 私 or 太郎）（が or は））（ガンダム or ジャイアン or コンピュータ or ラーメンが好き）（だ or です）
A=（（オレ or 私 or 太郎 or ラーメン）（が or は））
　A（ガンダム or ジャイアン or コンピュータ or A（好き））（だ or です）

っていう処理をすれば、それらしくなる・・・・のか？
なんか80氏の言ってること微妙に違う気もするけど
まぁ、これで実装してみればわかるか？

イメージつーか外部仕様の話じゃないか…(汗
後、微妙どころか全然違うから。>169で言うなら
一個目はそもそも過去の入力例が無いので出力なし、
二個目も一個目と共通点が全くないので出力なしだ。
三個目は「オレがガンダムだ」と出力していれば良し。

>>170
すまん、こっちで勝手にすごい勘違いをかましていた。
>>150の仕様をやってみようと、実際に組んでみました。

そのソース
http://www.ff.iij4u.or.jp/~ranmaru/ai/sor/MatchOfText.rb
使用する関数
http://www.ff.iij4u.or.jp/~ranmaru/ai/sor/commonCharacterStringExtraction19.rb
使い方は
>ruby MatchOfText.rb 辞書ファイル 入力文字列

出来上がった仕様としては、１文字以上の共通部分を見つけて
共通部分があるなら、過去に入力した文字列から候補を出力する。
字面のみでの判定ってことだから、こういうこと？

ここで作ったものは、単純な全数検索だけど
これを抽象化することで、全数以下（？）にする方法があるってことだよな。
抽象化とかポインタとか、いっぱいヒントがでてるよな

例えば、共通部分が出た文字列毎に、同じ配列に入れる
そいつをインデックスにして、その後ろの文字が共通かを探っていく

ABCDという入力にたいしてAというインデックスからABというインデックスを探す
あれば、つぎにABの中にABCというインデックスがないかを探す
同時にBでも同じことを行う、CでもDでもおこなう
最終的に、ABCDでバラバラに行った結果の中で一番長く共通部分があるものを候補としてあげる

これだと、並列であれば、シリアルでの全数検索より早くなる場合があるな。
しかも、おそらく、文字列が長ければ長いほど、
そして、過去の入力が多ければ多いほど、その傾向が強くなるだろう。
しかも、とりこぼし無しだ。

こっちも、作ってみるかな
でも、並列での実装は難しいから、とりあえずシリアルにしたもので・・・

http://www.ff.iij4u.or.jp/~ranmaru/ai/sor/MatchOfText2.rb

文を貯めこみながら、マッチングするクラスできた〜
データ構造としては以下の構造の配列を持っている
とりあえず、「インデックス型配列」とでも、名前を付ける。

["インデックス", [ [ インデックス型配列1 ], [ インデックス型配列2 ], ... ], [ "該当文1", "該当文2", .... ] ]

インデックスは、そのまま共通する文字列がはいっている。
インデックス＋αの文字列をインデックスにもつインデックス型配列を、配列として格納している
該当文には、インデックスに該当する元となった文字列が配列として格納されている

この構造により、長い文章の部分一致を素早く見つけることができる。
格納するのには、検索より多くの時間がかかる・・・・
そして、大量のメモリを消費する

そして、作ったあと実験してて、気がついた。
共通部分を分類してるだけだと、初期の蓄積文章が少ないことのルールは、信用できない。
ある程度、文章量がたまってくると、信頼性も上がってくるが
全てに通じるルールには、なりそうにないな・・・

同じものをより分けることが基本路線でいいはずなんだけど
ルール化したものを、なんらかの方法で、使えるものと、使えないものに分けないとだめだな
より多くの文章との比較で格付けとかできるか？
いまは、最も大きな共通部分のみに反応してるけど、他の使い方も出来そうな気もするな

で？

>172ではいくつか欠点が。しかも割と致命的。
�@ABCDとAbDで「Aが似ているABCD」「Dが似ているABCD」と重複して判定される。
�AABCDと比較してABCd、abCDのどちらがより似ているか？を判定できない
�B類似例を得るのに、毎回インデックス型配列の個数分文字列比較しなきゃならない。

ある入力からできる抽象物は、例えばそれがABCDだった場合
・Aが任意になったもの（-BC） ex)aBC
・Bが任意になったもの（A-C） ex)AbC
・Cが任意になったもの（AB-） ex)ABc
の4通りがまず考えられる。更に抽象化されたものとして
・ABが任意になったもの（--C） ex)abC
・ACが任意になったもの（-B-） ex)aBc
・BCが任意になったもの（A--） ex)Abc
・ABCが任意になったもの（---） ex)abc
となる。入力がn個の部分に分けられるとすると抽象物はn^2-1個考えられるため、インデックス型配列が元の例より少なくなるとは限らない。
また、�@に関しても「真ん中だけが違う」というルールをそれ自身として捉え切れていないことになる。

おっと、ex)てのは使うところが変だな…

われ思うゆえにわれあい。

われ思うゆえにわれAI。

我思うが故に宇宙あり。＝科学

だってビックバン宇宙の外は観測する対象がないから存在しないって
物理定義だよ。

あ、>174ミスってた
> ある入力からできる抽象物は、例えばそれがABCDだった場合
ABCだった場合、でした。
> の4通りがまず考えられる。更に抽象化されたものとして 
3通りでした。

47氏が戦意喪失してそうな気がするので、多分最後のヒント。
・具体例と抽象物は１つクラスを作って、どちらもそのインスタンスとして表現した方がいい（と言うか配列じゃ表現しきれないと思う）
・具体例から抽象物へは再帰を使ったら十数行で生成できる
ABC→(-BC,A-C,-BC)
-BC→(--C,-B-)
A-C→(--C,A--)
-BC→(--C,-B-)
（但しA-Cからの--Cや-BCからの--C,-B-は既にあるので生成の必要はない）

なるほど、それで終わりか。

>>179
なんか、うまくまとまらん

とりあえずの方向として
ABC
?BC
?B?
A?C
A?
?C
?

みたいなかんじでワイルドカードを挟んだ形式のものをつくる関数を作った
これと、別な文字列比較して、確定部分が最大のものが、最も似た形とする
ような感じつくってみるかなぁ

問題点としては、過去の入力の全数検査になるんだよなぁ
これも、方向間違ってるのかな？

ってわけで、生存報告でした。

>過去の入力の全数検査になるんだよなぁ
ありえねぇｗｗｗｗｗ
まるで素人が行うアルゴリズムじゃないか。

全数て１０００件MAXぐらいだから問題ないんじゃね？

>>183
１０００件程度じゃ、あまり思わしくない結果になりそう
使える単語とか限定すれば、それなりになるかもしれんが
オレの目指すところと大きく離れる

少し形になってきたので、インデックス型配列と組み合わせることにする
これで全件検索よりはまともに動くはず。
入力文字列の文字数に応じて指数関数的に増える似た形にも
ある程度対応可能になるだろう

270だけどもう一つ質問。

単語の相互関係を使って、コンピュータに言葉の意味を分からせようとする研究を良く見るけど
これってかなり良い結果は出せたとしても、絶対どこかで失敗すると思うんだ。

例えば痛みの意味をコンピュータに教えるにはコンピュータに痛みを実感させないとだめだと思う。
それを実現するには強い人工知能がいるんだろうけど。
でも相互関係だけじゃどこかでつまづくと思う。

言語処理を研究している人達はこのへんどう考えてるの？

>>185
すいません最初の一行は無視してください。

>>185
それは記号着地問題として昔から有名な問題つか、疑惑。

だから、最近では肉体を持ったロボットの研究が盛んに行われている。

記号処理だけでは本当の知能が生まれようが無いのは恐らく皆、認識している。

10 DIM WORD$(4,8),QA$(8)
20 FOR C=1 TO 4
30 FOR K=1 TO 8
40 READ WORD$(C,K)
50 NEXT K
60 NEXT C
70 DATA きゅうきゅうしゃ,くるま,おおきめ,しろい,はやい,しかくい,わからない,かんじゃさんをたすける
80 DATA ぞう,けもの,おおきい,はいいろ,のろい,やまみたいだ,くさい,はながながい
90 DATA おかあさん,おかあさん,おおきい,しろい,はやい,うつくしい,いいにおい,やわらかい
100 DATA メルヘンひじきごはん,ばか,ちいさい,ばっちい,のろい,いまいちだ,はながもげる,へんてこりんだ
110 INPUT PROMPT "なにがしりたいの？":A$
120 IF A$(1:8)=WORD$(1,1) THEN GOTO 130 ELSE GOTO 200
130 FOR C=1 TO 8
140 LET QA$(C)=WORD$(1,C)
150 NEXT C
200 IF A$(1:2)=WORD$(2,1) THEN GOTO 210 ELSE GOTO 300
210 FOR K=1 TO 8
220 LET QA$(K)=WORD$(2,K)
230 NEXT K
300 IF A$(1:5)=WORD$(3,1) THEN GOTO 310 ELSE GOTO 400
310 FOR C=1 TO 8
320 LET QA$(C)=WORD$(3,C)
330 NEXT C
400 IF A$(1:10)=WORD$(4,1) THEN GOTO 410 ELSE GOTO 500
410 FOR K=1 TO 8
420 LET QA$(K)=WORD$(4,K)
430 NEXT K
500 IF MID$(A$,CC,4)="ってなに" THEN PRINT QA$(1);"は";QA$(2);"だよ" ELSE GOTO 505
502 GOTO 1500
505 IF MID$(A$,CC,7)="どんなおおきさ" THEN PRINT QA$(1);"は";QA$(3);"よ" ELSE GOTO 600
510 GOTO 1500
600 IF MID$(A$,CC,5)="どんないろ" THEN PRINT QA$(1);"は";QA$(4);"よ" ELSE GOTO 700
610 GOTO 1500
700 IF MID$(A$,CC,6)="どんなはやさ" THEN PRINT QA$(1);"は";QA$(5);"よ" ELSE GOTO 800
710 GOTO 1500
800 IF MID$(A$,CC,6)="どんなかたち" THEN PRINT QA$(1);"は";QA$(6);"よ" ELSE GOTO 900
810 GOTO 1500
900 IF MID$(A$,CC,6)="どんなにおい" THEN PRINT QA$(1);"は";QA$(7);"よ" ELSE GOTO 1000
910 GOTO 1500
1000 IF MID$(A$,CC,8)="どんなとくちょう" THEN PRINT QA$(1);"は";QA$(8);"よ" ELSE GOTO 1100
1010 GOTO 1500
1100 LET CC=CC+1
1200 IF CC>=LEN(A$) THEN GOTO 1300 ELSE GOTO 1400
1300 FOR C=1 TO 1000
1301 FOR K=1 TO 64
1302 NEXT K
1303 NEXT C
1310 PRINT "ねえほかのこと"
1350 GOTO 110
1400 GOTO 500
1500 INPUT PROMPT "もっときいてくれる？":B$
1600 IF B$="うん" OR B$="いいよ" THEN GOTO 1760
1700 IF B$="ううん" OR B$="やめる" THEN GOTO 1800
1750 PRINT "じゃあつづけちゃうよ"
1760 LET CC=1
1770 GOTO 110
1800 END

どうでもいいけど>>147
文語と口語の使い方間違ってるよ

>>187
日本語でおｋ