sazare / cheaplogic Goto Github PK

ビューがおかしいかどうかはわからないが、GLID: L31_R1のビューで
{X=x_C14, Y=y_C14}
になり、値を入れてconfirmすると

2019-07-21 10:08:45:ERROR:Main: ICMP(:x_C14, 8, :unify0sn)
2019-07-21 10:08:45:ERROR:Main: /go?op=postview&X=8&Y=2&how=confirm 500

2019-07-21 10:08:45:CRITICAL:Main: ICMP(:x_C14, 8, :unify0sn)
unify0(::Array{Symbol,1}, ::Symbol, ::Int64) at /Users/shin/Projects/github/cheaplogic/Prover/unify.jl:34
unify0(::Array{Symbol,1}, ::Expr, ::Expr) at /Users/shin/Projects/github/cheaplogic/Prover/unify.jl:67
unify1(::Array{Symbol,1}, ::Expr, ::Expr, ::Array{Symbol,1}) at /Users/shin/Projects/github/cheaplogic/Prover/unify.jl:215
unify(::Array{Symbol,1}, ::Expr, ::Expr) at /Users/shin/Projects/github/cheaplogic/Prover/unify.jl:302

🎂 x_C14とかが変数になっていないのではないか

1. evaluatable?
2. resolution wituh base
3. ask with View
4. or, another literal

this is the order

Non procedural, something special for prover.

Propと同じか

they are same lid?

とにかくconfirmしたらliteralは消えてしまう。
入力のなかった項目は、別のliteralで入力されることもあるが、そうでないこともあるのだから、未定義のままでFactになってしまい、confirmする人間の責任が大きすぎるような気がする。

これは成り立たないと思うが、どうか

作る

evalは自動的にground

May it be clear the result?

とはいえ、fp_substをclosure_substにすると関数名が長くなりすぎる。
かといって、closureにするとあのclosureとまぎらわしいのでだめ。
close_substでも長い

ということでおあずけ

いろいろ修正したので、一度、動作が正しいか確認しておく

vdata/vcirc003.cnf

sw=on, lamp=light,
then
pow=chaged, wire=conn

after [],

julia> printmgus(core)

R1:L3:L3=x/light;y/on;ERROR: BoundsError: attempt to access 4-element Array{Symbol,1} at index [5]

1. proofの(検索空間の?)大きさ

• 幅と深さ
• パス上のliteralの根の出現回数(だいたいループの回数)

2. □の数
3. パス上の同じ形のmguの数

補足

• mguの比較(変数を無視しての同一性)
• literalの根とは、入力集合でのliteralのこと(この実装ではlidで判別できる)

good tool.
it may be good to enhance it.

cmd=open -a "Google Chrome.app" http://localhost:8000/go?op=start
run(cmd)

While testing, what functions are useful?
@test size(contradictionsof(core)) == 1
is available now. But more.

after new readcore, happen r1 occured.
it may be some variablename miss.

move global to Dict{session id, prover info}
prover info is the vars now global.

View should be treated as axiom.
But it has no lid.
How I treat it?

Now, web application control rules the flow.
But It makes the figure unclear. I feel so at least for me.

route("/go") is the web control between targets.
But I think eval loop , view or reso loop following.

今は、(x,y)<-(x, f(x)) があったとき、うかつにも(y)<-(f(x))にしてしまったので、xが定数扱いになっている。
呼び出し側でこの関数を使わないように修正したが、ちゃんと(x,y)<-(x,f(x))のままにしないとならぬ

View interface
i make it

don’t find same steps, but find same trials.
it is’nt a mgu.
it should be a literal pair.

An information of a proof is the whole mgu of the proof.
I need the mechanism for tests and proof analysis.

input litid のベクトルは普遍
NLPみたいなことできるか

kpreso.jlにたいして、reso.jlをreso.jl+unify.jl+αにした修正を反映
できるか?
resoの部分とkpunifyの部分とsapplyとかいろいろわける

気がする

it should treated as fail to resolution

For searching all proofs, how many poofs are needed, when terminate to searching are required.
How to estimate it?

A quantifier variable indicate a place.
Variables in formula refer the places.
In this context, substitution and mgu are how are interpreted.

なぜ? REPL上に複数のcoreを作っていたとき、同じ名前で置き換わっているかどうかわからなくなるので

・resoをresoとunifyにわけたあとで発見した
・条件が足りなくなっているのかも
　出力変数を初期化するという対処だと、これが原因のとき間違った修正になる

clause setが複数あって、証明がずるずる進んでいかないようにしたほうがよくないか?
そのときのストッパーはCanoになるだろう。

about Genie

1. search contradictions for every clause.
   every proving environments are disjoint and commons.
2. cnf converter may useful

the order of vars is not the order of args.
automatic vars generation of cano is not correct.

data/rundata.jlを実行してできるcoreのresolvent数を比較すると、一部のdataでresolent数が異なる。
ml007の場合、naiveでは[]ができていないが、cheapではできている。
なぜだろうか

参照: docs/comparison_naive_cheap.txt

P(a=x,b=y) with -P(b=1,a=2) cant resolved

同じlitralのViewにもどってしまい、confirmしないと先に進まない。
あるliteralのViewでabortしたら、次はviewでもresoでも別のliteralにしてほしい

addnewclause()のコードがあちこちにある。
eval,view,resoの違いをはずして共通化する。

f(x) = f(x-1) の定義があるとIDaxiomと判定してしまう。
明示的にIDAxiomを指定すべきかな

symbol, number and more constants exists.

It allows to write something like Japanese joshi as keywords.
And I hope the keywords opens the other possible expression.
In this point of view, DB's SQL statement assumes many conditions over Logic. It seems interesting.

abortは何も消さない

その場合、どうやってprogressすればいいのか
それとも1つ[]がみつかればそれでいいのか