Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide Atomese wrapper #1

Open
linas opened this issue Dec 3, 2022 · 6 comments
Open

Provide Atomese wrapper #1

linas opened this issue Dec 3, 2022 · 6 comments

Comments

@linas
Copy link
Member

linas commented Dec 3, 2022

Provide an Atomese wrapper for Unify.

So, here's the deal: (Unify A B) is more or less the same thing as (Meet (Identical A B)) . However... There are some conceptual differences. Unify allows the form:

  (Unify
     (VariableList left-vars...)
     (VariableList right-vars..)
     left-expr
     right-expr)

where left-vars... are the things to be taken as variables in left-expr. There's nothing like this for IdenticalLink or MeetLink. We can almost get the same thing by writing

  (Meet
     (VariableList left-vars... right-vars..)
     (Identical left-expr right-expr))

except that this can fail if (Variable "$X") appears in left-vars, and also appears in right-expr, but not in right-vars. There is no way to handle this case in any kind of easy or natural way using MeetLink. And that is how Unify is different from (Meet (Identical ..))

The proposal is then to provide two forms: either a simple form, with no vardecls

  (Unify
     left-expr
     right-expr)

or the full form, with vardecls.

  (Unify
     (VariableList left-vars...)
     (VariableList right-vars..)
     left-expr
     right-expr)

Maybe also provide (VariableListAuto) which means "yank them out for me".

What about the output? (next post)

@linas
Copy link
Member Author

linas commented Dec 3, 2022

For the output, the "full form" would be

(LinkValue  ; set of all results...
   (List  ; list of left-right pairs
      (List  ; list of all left-var groundings
         (List (Variable $left-var-1") (Atom gnd-in-right))
         (List (Variable $left-var-2") (Atom another gnd-in-right)))
      (List  ; list of all right-var groundings
         (List (Variable $right-var-1") (Atom gnd-in-left))
         (List (Variable $right-var-2") (Atom another gnd-in-left)))))

This seems terribly verbose. Nasty-ugly verbose. Unusable from the usability perspective. So, a better variant would be to make it rewrite, just like a rule would:

  (UnifierLink
       (VariableList left-vars...)
       left-expr
       (VariableList right-vars..)
       right-expr
       result-expr)

where result-expr can use any of the variables appearing in left-vars or in right-vars. Perhaps an even more natural form would be

  (UnifierLink
       (Lambda
           (VariableList left-vars...)
           left-expr)
       (Lambda
           (VariableList right-vars..)
           right-expr)
       result-expr)

The above seems to match what conventional books on proof write for a typed rule ... @ngeiswei any comments or corrections?

linas added a commit that referenced this issue Dec 3, 2022
This is my first naive stab at doing what's described in issue #1
@linas
Copy link
Member Author

linas commented Dec 4, 2022

I do not understand the use-case for the unifier. I am guessing that it is this: There are two rules, written as RuleLinks of the form

(Rule
   (VariableList X ...)
    (And
        (Premise A)
        (Premise B)
        ...)
   (Conclusion F))

and similarly (Rule (VariableList Y...)(And (Premise C) (Premise D) ...) (Conclusion G))

Now, (I am guessing) you want to see if these two rules can be joined together. The chainer(s) try to figure out if (Conclusion F) can be unified with (Premise C) and use the unifier to try to figure this out, right?

The corresponding Unifier then has the form

(Unifier
   (Lambda
       (VariableList vars X ... that are in F)
       (Conclusion F))
   (Lambda
       (VariableList vars Y... that are in C)
       (Premise C))
   (Rule
      (Varible List X... Y...)
     (And
        (Premise A)
        (Premise B)
        ...
        (Premise D)
        ...))
    (Conclusion G)))

So that a new RuleLink is constructed, without (Conclusion F) or (Premise C) in it, any more; but all the others remain, as before. Is this correct? Is this how the URE actually uses the unifier?

@linas
Copy link
Member Author

linas commented Dec 6, 2022

FYI @ngeiswei the demo https://github.com/opencog/unify/blob/master/examples/unifier-tree.scm provides an example of chaining together two rules, using "pure Atomese" (no C++ or scheme code). Note the chaining direction is ambiguous: it can be read as going either "forwards" and "backwards" .

@ngeiswei
Copy link
Member

Very cool work!

@linas
Copy link
Member Author

linas commented Jan 27, 2023

Thank you!

@linas
Copy link
Member Author

linas commented Jan 27, 2023

I mean, @ngeiswei you did all the hard work of making the unifier actually work. I did the easy part of slapping a coat of paint on the thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants