1read 100read
2012年07月プログラム58: 【論理】Prolog【初心者】 (606) TOP カテ一覧 スレ一覧 2ch元 削除依頼
C/C++の宿題片付けます 160代目 (615)
【Delphi互換!?】FreePascal/Lazarus その2【GPL】 (288)
Java系スクリプト言語Groovy (845)
Lisp Scheme Part35 (202)
正規表現 Part10 (365)
【肥大化】C++ を見捨てたヤシ 2人目【複雑化】 (926)

【論理】Prolog【初心者】


1 :2010/11/06 〜 最終レス :2012/11/04
Prolog初心者のスレ
これは良い言語だ…

2 :
ただでさえ過疎スレなのに初心者スレが必要なのか?

3 :
>>1


4 :
>>2
初心者を増やしていきたいじゃないか
いい言語だし、もっと使われてもいいはず

5 :
Prolog初心者があそびにきました
1. 日本語の通る無料の処理系
2, 初心者向けチュートリアル
3. 初心者向けおすすめ書籍(いまでも容易に手に入るもの)
あたりがテンプレにあると助かります
ご一考いただれば幸いです

6 :
このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
                  京都大学霊長類研究所

7 :
.NETで動く、あるいはC#コードに埋め込めるPrologがあればいいのだが

8 :
Prolog#
IronProlog

9 :
>>8
おぉ、d

10 :
>>8
p# ではなくて、prolog# か。
別のものかな。

11 :
>>5
2, これはSWI-Prolog でいいでしょう。
3, http://www.amazon.co.jp/dp/4303716901 

12 :
ごめん処理系だから、 1, でした。
2, は素っ気ないのが多くて難しいな。

13 :
>>2
これからが、Prologの時代だ。

14 :
考えてみると、Prologチュートリアルはこのスレ(別スレ立ててもいいけど)でこれから始めればよい。

15 :
「Prologの宿題片付けます」の方は、凝った問題が多くて初心者向けとは
いえないから、ここは思い切りやさしい課題満載のスレになるといいね。

16 :
prologこそクラウドを制することの出来る言語

17 :
つーかPrologは何に向いてるのかが初心者を惑わすのだと思ふ

18 :
Prolog 百夜話
引数がリストかどうか判定する述語 list/1 の定義は、
list([_|_]).
です。
?- list([1,2,3]).
yes
?- list([1,2|R]).
R = _13353
yes
?- list([1,[a,b],3]).
yes
?- list(3).
no
ところで、
?- list([]).
no
?- 空リストはリストではありません。アトムです。

19 :
>>17
はっきり向いていない分野がいくつかあり、
それ以外はどんな分野でも「大変に」向いている。
そういう言語です。

20 :
>>17,19
はっきり向いていない分野が大半だけど、
ごく一部の分野に限れば「大変に」向いている、ではないかと思う。

21 :
>>20
多分、定理証明のような分野を念頭に置いての書き込みだろう。
現在のPrologの衰退ぶりから見て、それが常識化しているのかも
知れない。
このスレの中でその常識が誤謬であることを証明しよう。
ありとあらゆる分野のコードを示すことで。

22 :
>>18
こういう出鱈目を書く人がもう居着いてるから難しいw
という冗談はともかく。
普通、空リストを含めてリストと呼ぶ。
[_|_]に適合するのはconsとか言って区別する。
よね。

23 :
>>22
そうだったか!
私は20年以上、空リストはリストではないと思っていた。
list([]).
list([_|_]).
これが定義ですか。
アトムでかつリストというのはちょっと腑に落ちないが。

24 :
一応参考まで
http://www.google.com/codesearch
lang:prolog ^(is_?)?list\(\[

25 :
完全な定義は、
list(V) :- var(V),!,fail.
list([]).
list([H|T]) :- list(T).
'.'(3,5) はリストではない。

26 :
ぶっちゃけリストの定義なり扱いなりは、歴史的には処理系によりけりなりけり。
[]がアトムでなくてもあまり困らないし。

27 :
>>26
そういうことのようですね。

28 :
初心者にとっては難解なやりとりだったと思いますが、
list/1 という述語は integer/1 と同じく検査用の述語として使おうとしています。
?- list([1,2]).
yes
?- list(8).
no
?- です。典型的な使われ方としては、
加算([],0).
加算([L|R],S) :-
    list(L),
    加算(L,S1),
    加算(R,S2),
    S is S1 + S2.
加算([A|R],S) :-
    number(A),
    加算(R,S1),
    S is A + S1.
?- 加算([3,4,[1,2,3],2],X).
X = 15
?- となります。

29 :
>>26
そりゃ、困るだろう。リスト項という型があるわけでもないし。
それなら[]は何に帰属するんだい?

30 :
アトムでも複合項でもない「文字列」の型を導入している処理系だってあるし、
別に何でもいいのでは

31 :
もちろんISO準拠にはならないという意味では困るけど

32 :
>>29
横レスだけど、Prologの[]は、LISPでいうところのNILに相当するのではないかと
?- X=[a|[]].
X = [a].
?- X=[she | [is | [25 | []]]].
X = [she, is, 25].

33 :
そういえば、Schemeの空リスト () は型が独立している…よね?

34 :
>>30
単純項と複合項 しかない というのがPrologの値打ちだったのではないかな。

35 :
よくわからんけど、その「単純項」とやらの仲間に入れてやればいいじゃん
数のことを考えてあえて「アトム」とは書かなかったんでしょ

36 :
>>35
単純項というのは
単項 + 変数 のことだよ。

37 :
また誰も使っていない用語をw

38 :
>>37
単項はさすがに無理かw
定数 + 変数 だね。

39 :
その場その場で言葉を類推して作ってるんですねw

40 :
>>39
うん。言葉の選択は大事だからいつもわかりやすい言い方が
ないか探してはいる。単項はアトムを言い換えたのだけれども、
ここは変数との対比になるから定数でなくてはいけない。
単純項という言葉は Prolog-KABA のリファレンスマニュアルが
初出かも知れない。後に出版された単行本にも出てくるはず。
Prolog講座などの単一化の授業以外では使われないと思う。

41 :
プロログ講座実施規程
第一条 JIS用語は、これを無視する。

42 :
毎日がプロローグ。だからいつも新鮮

43 :
ここまでの内容をふまえて、初心者向けに
・PrologのISO規格は1995年以降。不統一な用語の亡霊が君に新鮮な毎日をもたらさんとす。
・「アトム」は整数などを含まない。(Common Lisp用語との違い)

44 :
Prologの世界は用語には無頓着で20年くらい前の話になるけど
ISO規格の日本側委員だった中村克彦先生がunificationを
融合、融合とおっしゃるから、我が意を得たりで、「やはり、
融合で統一のお考えですか」と訊いたら、
「あ、全然そんなことないです。なんでもいいんです。」
だと。

45 :
unificationを融合?w
resolutionと混同してませんか、それ

46 :
>>45
いいえ、unificationですw

47 :
「なんでもいい」というのは「統一されていれば、」というふうに解釈しますけどね私はw

48 :
>>47
まあ、そうでしょう。

49 :
unificationの訳語は「単一化」じゃないの?

50 :
>>49
悔やまれるのは、「先生ぜひ融合で統一しましょう」と尻を押さなかったこと。その場に
いたProlog協会の面々を扇動して、このように強く働きかければ、中島、後藤、古川氏等は
中村先生が説得可能だったでしょう。当時はメジャー言語の尻尾くらいにいたから、考えも
しなかったけど、今思えば、単一化なんて変な用語はまずかった。
単一化しかない言語ですから。

51 :
>>49
JISでは。
というか、Prolog界だけでわめいてもダメでしょう。
ISOがunificationという(論理学かぶれの)言葉を選んだ時点で。

52 :
やばい、なんか気持ちが入って混乱気味の発言になった。

53 :
ISOでいう「compound term」(複合項。これも論理学風)と同じ意味の「structure」の訳語としては、
「構造」より「構造体」の方がわかりやすいというか、正しいというか、そんな気がする。
少なくとも日本語では「構造物」を単に「構造」と言ったら分かりにくいんじゃないか、
というような意味で。今さらだけどw

54 :
用語ばなしの続きですが、これまで何度も使ってきた例の述語、
親子(頼朝,義朝).
親子(義朝,為義).
先祖(A,B) :- 親子(A,B).
先祖(A,B) :- 親子(A,C),先祖(C,B).
でなぜ、親子にはルールがないか、という問題です。親子/2は英語で
いうところのprimitiveな情報ということになります。まあ、最後に
行き着くところ、ですね。このような情報を何と呼ぶか、25年くらい
悩んできたのですが、最近これを、基(もとい)と表現することにしま
した。ここで、親子/2はもといである、という風に使います。
「単一化」以上に日常から離れますが、やまと言葉に潜む力に賭けたい
と思います。

55 :
実は>>26を書いたとき、「[]を「(リストの)けり」と呼ぶことを今思いついた」と
よほど付け加えようと思いましたが、やめてよかったと思いますw

56 :
親子/2は、単純に「命題」という用語でいいんじゃないのかな。
命題は西洋哲学から生まれた概念だから、やまと言葉には
そぐわないかもしれないけど。
ところで、数学だと和算という言葉はあるけど、論理学には対応する
やまと言葉はあるのかな?哲学は「問答(もんどう)」でいい気はするけど。

57 :
>>56
命題に行き着く。それでよい。とりわけ、私が>>54で書いた「ここで、親子/2はもといである」
では命題とほとんど同義です。ただ命題、親子/2 は頼朝と義朝が親子関係にあることは
明々白々であることを述べている。一方、私が「もとい」として拘っているのは、
親子はDNAだの、両性のRの結果女性が妊娠して・・・等、さらに具体的にルール化できない
ことはないが、ここで止めておく。この親子のように外延として記述する場合もあるが、それも
放棄して、組み込み述語を書きっぱなすにとどめることもある。そういう命題の措定のされ方に
ついての意を含みたい、そういう部分です。

58 :
prologは業務処理に向いているだろうか?

59 :
>>58
現在のPrologは32bit以上の整数を自動で扱えますから、障碍になる
部分はありません。ライブラリを作らないコミュニティなので、
基本的に自前の必要はあります。COBOLのDATA DIVISION を解析して、
Prologに変換的なことを最も得意とする言語です。ということは、
すべてのデジタル化可能な業務文書の解析を得意とするということで
あり、なぜこれまで業務処理に積極的に使われてこなかったのか、
不思議ですね.

60 :
>>59
ライブラリ作ろうぜ
それがないと広まらんだろーJK

61 :
本格的な業務プログラムとなると、10万述語程度の定義が
必要になる。一人のPrologプログラマの一ヶ月に定義でき
る限界は、1500述語程度だから、六ヶ月でプロジェクトを
終えることを目標にすると、10人以上のPrologプログラマ
を確保しなくてはならなくなる。現時点ではこれはまったく
不可能。Prologの過去の例ではICOTでのESPの開発しかない。

62 :
ESP開発はもちろん業務処理ではない。

63 :
ようするに、企業側からいうと、
一流大学卒のPrologプログラマをそんな業務開発などに
回せるか。という論理になる。一方、ある時期からは
学生の方も、Prologプログラマとして就職なんかして、
大丈夫かということになったから、現時点ではProlog
プログラマを業務開発用に確保することは至難となって
いる。

64 :
>>63
向き不向きでいうと、向いていると?

65 :
>>64
はい。少なくともCOBOLやPHPよりは遙かにね。
言語自体がオンメモリ・データベースですから。

66 :
Prolog本スレに大規模な業務処理に使われなかった理由がありました。
Prologでまったり Part3
http://pc11.2ch.net/test/read.cgi/tech/1193354806/115
> 115 :デフォルトの名無しさん [↓] :2008/04/26(土) 18:08:59
> COBOLを代替できなったという点は、>>83にちょっと出てきているが、
> アトムの爆発ということだとおもう。Prologではアトムをヒープエリア
> 内に一旦記述して処理する戦略をとる。極めて大きな記号間の連鎖を表現しよう
> とする記号処理言語ではどこかに対象となる情報すなわちアトムを保持せざるを
> えない。この場合、初出のアトムに対し必ずメモリ内を検索し、無い事を確認して
> 新たに構造体を追加する。業務処理で一日一億のトランザクションを処理する
> ケースだとこの参照時間だけで相当のものだ。やはり破壊代入だけで済ませる
> 言語には太刀打ちできない。さらに再帰で処理した場合はオーバーフローの危険が
> あるし、バックトラックして再束縛する場合でも、ヒープエリアのGCは必ず
> 必要になる。実際、保険業務などをPrologで処理することを想定すると、すぐに
> 電話帳一冊分くらいの量のアトムが発生してしまう。
> 企業業務はほとんどが記号処理、シンボル処理であり、Prologはそういう意味では
> 極めて適した言語なのだが、残念ながら以上のような理由から、大規模な業務処理
> には向いていない。

67 :
>>66
はい。そうだと思いますw
実はこれは私の書き込みです。私はPrologの適性領域と限界という
ことをずっと考え続けてきたので、この書き込みの内容もまた真
ではないかとぶつけました。これからのPrologは20GBを超えるメモリ
での実行が当たり前のことになるでしょうし、オンメモリデータベース
としても最速クラスに近いメモリ管理・データ管理が要求されること
になるでしょう。

68 :
話は逸れますが、過去の業務処理を調べると、古いシステムほど、
入力検査を厳しくやっています。入力がカードや紙テープですと、
どんなとんでもないエラーが入り込むかも知れないからと、一項目
一項目、いろんな角度から検査し、どこかにエラーが見つかれば、
入力の対象とはしない。そういう設計にしました。その後POSの
ような部分的に入力検査済みの装置を経るのが当たり前になり、
さらに、RDBの登場あたりからともかく入力させてしまって、削除、
修正はSQLでやればよい、と大分おおらかになったようです。
何でこの話をするかというと、COBOLだと100行以上の連続したIF文
など珍しくなかったのですが、これをPrologに移植すると100節では
なくて、100述語以上に変換されるかも知れないということがある
からです。
これこれこういう場合は(_検査対象,_診断) :- ...
がPrologの標準スタイルであり、あっという間に10万述語なんて
いってしまう理由がこんなところにもあります。

69 :
結局、現在のPrologの最大の問題は
100万節以上のデータベースを持つ場合、一節づつassertz
で追加する時に、各項のアトムの既出検査で、平均すると
アトム総数の半分のリンクを辿ります。いくらCPUのサイクル
が高まってもこれでは時間がかかり過ぎということです。

70 :
Prolog の入力述語について、
項の入力にはread/1が使われてきましたが、これは、
・ ピリオドで終わらなくてはならない。
・ シンタックス的に正しい項以外はエラーとなってしまう。
など、実務での使用に適しません。それで改行までの文字列を
入力として受け取る、get_line/1の定義をしておくのが普通です。
get_lineはget_char/1 または get_code/1を改行がくるまで、
繰り返し使うことによって定義します。例えば、
get_line(Line) :-
get_char(Char),
get_line_2(Char,L),
concat_atom(L,Line).
get_line_2('\n',[]) :- !.
get_line_2(A,[A|R]) :- get_char(B),get_line_2(B,R).
concat_atom([],'').
concat_atom([A|R],S) :- concat_atom(R,S1),atom_concat(A,S1,S).


71 :
ちょっと読みにくかったですね。すみません。
<Prolog の入力述語について>
項の入力にはread/1が使われてきましたが、これは、
・ ピリオドで終わらなくてはならない。
・ シンタックス的に正しい項以外はエラーとなってしまう。
など、実務での使用に適しません。それで改行までの文字列を
入力として受け取る、get_line/1の定義をしておくのが普通です。
get_lineはget_char/1 または get_code/1を改行がくるまで、
繰り返し使うことによって定義します。例えば、
get_line(Line) :-
        get_char(Char),
        get_line_2(Char,L),
        concat_atom(L,Line).
get_line_2('\n',[]) :- !.
get_line_2(A,[A|R]) :- get_char(B),get_line_2(B,R).
get_line_2は引数が違いますから、get_lineでもいいのですが、
ちょっと理由があってこうしました。これについては後に。

72 :
ストリーム付きのget_line すなわち get_line/2
>>71 でget_line/2を使わなかったのは、この述語定義のために
残して置きたいという理由からでした。
get_line(Stream,Line) :-
        get_char(Stream,Char),
        get_line_3(Stream,Char,L),
        concat_atom(L,Line).
get_line_3(Stream,'\n',[])..
get_line_3(Stream,A,[A|R]) :- get_char(Stream,B),get_line_3(Stream,B,R).
という定義であり、
?- open(File,read,Instram),get_line(Instream,Line),close(Instream), ... の
ように使います。

73 :
タブで終了させたい場合もあるでしょう。
get_line(Line) :-
get_char(Char),
get_line_2(Char,L),
concat_atom(L,Line).
get_line_2('\t',[]) :- !.
get_line_2('\n',[]) :- !.
get_line_2(A,[A|R]) :- get_char(B),get_line_2(B,R).
のように終止節を追加します。OSによっては、入力に
newline の他にキャレッジリターンフィールが入力される
ことがあり、これは無視するために、
get_line_2('\t',[]) :- !.
get_line_2('\n',[]) :- !.
get_line_2('\r',R) :- get_char(B),get_line_2(B,R),!.
get_line_2(A,[A|R]) :- get_char(B),get_line_2(B,R).
のように一節挿入します。

74 :
業務用途ではないけどミドルウエアでは使われているよ。
あと、なぜ殆どの人はprologを言語上の述語理論でしか考えてない/られないのかね。
まるで判ってないと思う。

75 :
>>74
(工夫して)書いてみる前に判った気がしてしまう。これも、述語理論の所為から
知れないよ。

76 :
入力はなしの続きです。
Prologでは引数で値を渡す定義が普通で、標準入力からデータ受け取って、
その後の処理をするプログラムはあまりありません。しかし、C/C++の宿題は
ほとんどすべてこの形式で出題されていて、このようなスタイルのPrologに
ついて整理する機会を得ました。それで、次からは入力検査についての話を
します。

77 :
>>74
うちもWebサーバ、Proxy、メールサーバ、などはPrologだけど、
Prolog だからというよりは、自前だから便利というところだな。

78 :
CGIでなくダイレクトにアプリが応答できるのはもちろん便利だけど。

79 :
最近は、原則として以下のような入力検査を必ずすることにしている。
例として、入力データが整数であることを要求されているとする。
整数データの入力(N) :-
write('整数を入力してください : '),
get_line(Line),
整数データの入力診断(Line,N),!.
整数データの入力(N) :- 整数データの入力(N).
整数データの入力診断(Line,N) :-
atom_to_term(Line,N,_),
integer(N),!.
整数データの入力診断(Line,N) :-
write_formatted('入力された %t からは整数が得られませんでした。再入力をお願いします\n',[Line
]),
fail.
ポイントは、
・ 整数以外のデータが入力されたら、それは捨てて、再入力を要求する。
・ 入力のトップレベルつまりget_lineのある述語定義では診断をしない。

80 :
最近は、原則として以下のような入力検査を必ずすることにしている。
例として、入力データが整数であることを要求されているとする。
整数データの入力(N) :-
        write('整数を入力してください : '),
        get_line(Line),
        整数データの入力診断(Line,N),!.
整数データの入力(N) :- 整数データの入力(N).
整数データの入力診断(Line,N) :-
        atom_to_term(Line,N,_),
        integer(N),!.
整数データの入力診断(Line,N) :-
        write_formatted('入力された %t からは整数が得られませんでした。再入力をお願いします\
n',[Line]),
        fail.
ポイントは、
・ 整数以外のデータが入力されたら、それは捨てて、再入力を要求する。
・ 入力のトップレベルつまりget_lineのある述語定義では診断をしない。

81 :
入力のトップレベルと診断してしまうと、そこでfailになった場合、
get_line/1でせっかく入力された文字列とLineの束縛がそこで解かれて
しまって、
整数データの入力(N) :- 整数データの入力(N).
の引数を増やしてみても、Lineを受け取ることはできません。このため、
診断結果の表示はLineを渡された述語の中で行います。
atom_to_term は parse_atom という処理系もあり、文字列からPrologで
認識できる項を切り出す述語です。第三引数については後に説明します。

82 :
表現が適切でない部分があったため、重複しますが、書き直しました。
ポイントは、
・ 整数以外のデータが入力されたら、それは捨てて、再入力を要求する。
・ 入力のトップレベルつまりget_lineのある述語定義では診断をしない。
入力のトップレベルで診断してしまうと、failになった場合get_line/1で
せっかく入力された文字列とLineの束縛がそこで解かれてしまって、
整数データの入力(N) :- 整数データの入力(N).
の引数を増やしてみても、Lineを受け取ることはできません。このため、
診断結果の表示はLineを渡された述語 整数データの入力診断/2の中で
行います。
atom_to_term は parse_atom という処理系もあり、文字列からPrologで
認識できる項を切り出す述語です。第三引数については後に説明します。

83 :
ちょっとしたシナリオの検証をするのに役に立つなー

84 :
>>58
この問題を蒸し返しますが、今日、私が要求されている
業務処理の大半が、Webからの情報の安定した抜き取りで
あり、そこで得られた情報の組み合わせを、保存する
ことです。いわゆる、計算はほとんどありません。
このような業務処理への適性では Prolog はスーパーの
クラスの中にいることは間違いありません。

85 :
昨日から Prolog を始めた初心者です。まるきり興味本位でやっています。
環境は Java6+PrologCafe1.2.5 です。
宿題スレにあった設問を自分なりに解いてみました。
http://www.dotup.org/uploda/www.dotup.org1263511.txt.html
パターンの数え上げ手法はあるソースを参考にしました。
あんまりあちこち見てて、どこだったかは分からなくなってしまいました。
その他いろいろ資料をあさってやってみたのですが、
switch文だの3項演算だのが頭にちらついて、どうも汚い感じにしか組めません。
とてもじゃないけどこれを「宿題だ持って行け」とは言えない・・・
メモリ足らずで JVM様が例外はいたりするので、
計算回数減らすための処理もこちょこちょ書いてるんですが、
たぶんすごく回りくどいことしてるんだと思います。
! もよく分からないので避けちゃってます。
もし簡単に改善できるところがあれば教えていただけると幸いです。

86 :
>>58
わが社の業務処理時の手動でのPrologインタプリタの負節入力(?- から始まる質問)の
累積数は18年間に70万を超えています。ほとんどが売上伝票入力ではありますが、
不自然さは全くありません。トランザクションとしては、別にPOS経由のものがあり、
こちらの累積は21年間で3000万くらいになります。Prologとの相性という点では、
従業員30-60名くらいの小企業だからこそと言うことができるかもしれない。よくぞ
小企業でいてくれた!,が正直な感想ですね。

87 :
>>85
恐縮ですが、書き込まれた解答を、
http://nojiriko.asia/prolog/prolog_177_1.html に勝手に転記させていただきました。
uploadサイトの掲載時間に制限があるためであり、著作権については可能な処置を
したつもりです。

88 :
>>85
ストレートフラッシュを除くフラッシュが一回目の配札で出現する確率は
_確率 is 4 * (13/52) * (12/51) * (11/50) * (10/49) * (9/48).
ですよね。仮に、全知全能というよりも予言者的なプレーヤーがつぎに
配られる5枚のカードを分かってしまって、フラッシュになるに相応しい
手札の取り替え戦略をとったとすると、確率はどうなるんですか?

89 :
ごめん、ストレートフラッシュを含んだでした。

90 :
4枚同じマークが配られて、一枚交換して、フラッシュになる確率は、
_確率 is 4 * ((13/52) * (12/51) * (11/50) * (10/49) + (1/47)).
でいいのかな?

91 :
あ、大間違いw
これから、夕方まで出かけるから、
その後で直します

92 :
_確率 is 4 * ((13/52) * (12/51) * (11/50) * (10/49) * (39/48) * (9/47)).
となるのかな? これを2-5枚とやっていって、合計がフラッシュの確立かな。
本当かね。

93 :
>>92 これまた、大間違い。判りません。

94 :
論理プログラミングに最近強い関心があるので質問
1.学ぶ際にPrologを選んでも大丈夫?(念の為)
2.Wikipediaに目を通した感じではAZ-PrologやSWI-Prologが良さそうだけど、お勧めの処理系は?

95 :
1..それ以外の選択はむずかしいのではないかな。
2.. 日本語マニュアルが必要なら、AZ=Prolog。この処理系は1980年代に一世を風靡した
  Prolog-KABAの後継を目指して開発されたもので、オンラインマニュアルの他、
  Prolog-KABAの解説本も参考書になります。
  今後、多くの仲間とライブラリを分け合ったりしながら発展していくには、
  SWI-Prologがお勧めです。2000年代に入って最も活性のある処理系だと思います。
  以前はバージョンによっていろいろ問題がありましたが現在は日本語も制限なく使えます。
おまけ.. Prologに慣れたら、Progol(誤植ではない)という処理系をインストールて
  機能論理Prologで遊んでみるといいと思います。すでに定義された節から、
  どうやったら新しいルールをProgolに生成させることができるか。大変興味い
  テーマを楽しめます。

96 :
機能論理Prolog は 機能論理プログラミングの間違いでした。

97 :
それから AZ=Prolog -> AZ-Prolog

98 :
>>95
もしProgolに手を出すなら
帰納論理プログラミングの入門書もどうぞ。
帰納論理プログラミング
http://furukawa.sfc.keio.ac.jp/book/
http://www.amazon.co.jp/dp/4320120140/

99 :
大変! ^ wwww
機能論理プログラミングになっている。
帰納論理プログラミングの間違いです。

100read 1read
1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼
Visual Studio IDE環境 (550)
■暗号技術【ROUNDsurea】■ (542)
***Javaのオススメ入門書*** 『創るJava』 3.0 (563)
電卓作る (223)
MVVMについて語ろう (398)
エスパーが質問に答えるスレ (309)
--log9.info------------------
【国産】レア車発見したら報告スレ 23台目【輸入】 (468)
【Low】ローライダー 15バッテリー【Rider】 (519)
【旧車】イベント情報 2【大好き】 (546)
BBCトップ・ギア-TopGear41 (670)
MT車乗りたいんだけど自信が無い 65 (451)
【通報しろ】朝から晩までみんカラ110【←番号】 (964)
【みんカラ】石健徹底的に撲滅【フリ絆スタ】 (389)
【国内専用】ドライブレコーダー映像に意見する1 (223)
【取手から】茨城の車窓から 31【北茨城まで】 (645)
【カロッツェリア】サイバーナビ Part2【初心者】 (407)
【レイたん】Lei01/Lei02を語るスレ12【霧島レイ】 (768)
 本当の金持ちほど車は安いもの      (955)
ネコ被害対策2 (505)
【U97,77,76,75】 SONY nav-u 40台目【U37,35,3】 (311)
ミニバン乗りを勝手にミニバン一台と決め付ける低脳 (281)
__|/ ワイパーメンテナンス 12本目 (785)
--log55.com------------------
40過ぎても就職出来なかった男
入院について語る40代
痒い
インキンタムシ
頭痛い
40代で未亡人になった
脱走したペンギンってどうなったの?
モテモテの40代だけが書き込めるスレ