[opencog-dev] Broken master

['Nil Geisweiller' via opencog]

Hi,

according to http://61.92.69.39:8080/job/ci-atomspace-master/222/console 
I've broken the master. Unfortunately I haven't been able to reproduce 
it, even with uncommenting `SET(DB_IS_CONFIGURED 1)` in 
`tests/persist/sql/odbc/CMakeLists.txt` to make sure I compile it.


Any idea?

Nil

--
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/57FE1AFE.2050901%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Broken master

[Linas Vepstas]

I can't reproduce it wither, but the error message is clear:

no known conversion for argument 1 from ‘opencog::NodePtr {aka
std::shared_ptr}’ to ‘opencog::AtomPtr& {aka
std::shared_ptr&}’

It this automatically for us, but not for jenkins .. a different compiler,
maybe? Or a different version of libstdc++ ?

--linas


On Wed, Oct 12, 2016 at 6:14 AM, 'Nil Geisweiller' via opencog <
opencog@googlegroups.com> wrote:

> Hi,
>
> according to http://61.92.69.39:8080/job/ci-atomspace-master/222/console
> I've broken the master. Unfortunately I haven't been able to reproduce it,
> even with uncommenting `SET(DB_IS_CONFIGURED 1)` in
> `tests/persist/sql/odbc/CMakeLists.txt` to make sure I compile it.
>
> Any idea?
>
> Nil
>
> --
> You received this message because you are subscribed to the Google Groups
> "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to opencog+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@googlegroups.com.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/opencog/57FE1AFE.2050901%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CAHrUA37yU_y79EpnJS32HzdbU6LKAKmCOY5ZMM0kD4QTANLXHg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Re: ImplicationLink?

[Linas Vepstas]

No, actually, I worked around that.

The only reason that PutLinkUTest currently passes is because PutLink fails
to treat ScopeLinks correctly.  When that gets fixed, the unit test will
fail ... the issue remains the same.

--linas

On Tue, Oct 11, 2016 at 11:57 PM, Nil Geisweiller 
wrote:

> Are these unit tests still failing?
>
> Nil
>
>
> On 10/11/2016 08:36 PM, Linas Vepstas wrote:
>
>> 47 unit tests fail ... I'm not sure if they all fail for the same
>> reason, though.
>>
>> For example PutLink
>>
>> (PutLink
>>(LambdaLink
>>  (VariableList
>>(TypedVariableLink
>>  (VariableNode "$X")
>>  (TypeNode "PredicateNode")
>>)
>>(TypedVariableLink
>>  (VariableNode "$Y")
>>  (TypeNode "PredicateNode")
>>)
>>  )
>>  (AndLink
>>(EvaluationLink
>>  (PredicateNode "acquainted")
>>  (ListLink
>>(VariableNode "$X")
>>(VariableNode "$Y")
>>  )
>>)
>>(ImplicationLink
>>  (VariableNode "$X")  ; this is alpha-converted to $foo1233
>>  (PredicateNode "is-human")
>>)
>>(ImplicationLink
>>  (VariableNode "$X") ; this is alpha-converted  to $bar456
>>  (PredicateNode "is-human")
>>)
>>  )
>>)
>>(ListLink
>>  (PredicateNode "is-Self")
>>  (PredicateNode "is-Bob")
>>)
>> )
>>
>> So, because the implication link is scoped, the result of the variable
>> substitution is
>>
>> (AndLink
>>(ImplicationLink
>>  (VariableNode "$foo123")
>>  (PredicateNode "is-human")
>>)
>>(ImplicationLink
>>  (VariableNode "$bar456")
>>  (PredicateNode "is-human")
>>)
>>(EvaluationLink
>>  (PredicateNode "acquainted")
>>  (ListLink
>>(PredicateNode "is-Self")
>>(PredicateNode "is-Bob")
>>  )
>>)
>> )
>>
>> which is not what the unit test expects. The problem with using either
>> ScopeLink or LambdaLink is that it becomes impossible to have a stable
>> variable name -- it can be alpha-converted to anything, so any algo that
>> depends on having a fixed, well-known variable name will fail.
>>
>> In this case -- I am not sure -- if you want ImplicationLink to be
>> scoped, then the unit test is wrong.  But is the unit test is right,
>> then implication link must not be scoped.  I cannot tell which one is
>> wanted.
>>
>> --linas
>>
>>
>>
>> On Tue, Oct 11, 2016 at 12:12 PM, Nil Geisweiller
>> > wrote:
>>
>> Linas,
>>
>> I don't have time to get into that right now. If you can point to
>> where exactly it breaks (like a unit test on your branch) it would
>> help. In any case I look carefully into that and reply tomorrow.
>>
>> Nil
>>
>>
>> On 10/11/2016 06:55 PM, Linas Vepstas wrote:
>>
>> You made it inherit from ScopeLink, thus making the variables in
>> it
>> implicitly scoped.  Then you added the file ImplicationLink.cc,
>> and have
>> notes in there, complaining about how variables are implcitly
>> scoped.
>> The wiki page for it, http://wiki.opencog.org/w/ImplicationLink
>>  still
>> says things that are wrong (re alpha conversion -- each lambda
>> gets
>> alpha converted, so the "sugar syntax" section cannot possibly
>> be right).
>>
>> I'm asking, because I'm trying to fix #910 by doing the alpha
>> conversion
>> correctly, and the result of the fix is that unit tests with
>> implication
>> links in them now fail.  The whole thing smells bad.
>>
>> Either ImplicationLinks do inherit from ScopeLink, in which
>> case, there
>> should be no complaints about how the ScopeLink works: it does
>> the right
>> thing.  If you don't like what the scopeLink does, then
>> ImplicationLinks
>> should NOT inherit from it ...
>>
>> In either case, the wiki page needs fixing, because the alpha
>> conversion
>> conversation we had recently renders that page incoherent.
>>
>> I don't really care, one way or the other, but I do need to
>> understand
>> the intended design well enough to be able to fix bugs, and
>> right now, I
>> don't understand what ImplicationLink is, or how its supposed to
>> work.
>>
>> --linas
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 

Re: [opencog-dev] About Attention Values and Truth Values

[vishnu]

>
> Hey Roman,
>

Thanks for the reply :-)

I am not sure what exactly you want to use the AttentionValues for

With attention values, i thought i could do the following:
I have 24x7 tweets coming. So i thought,  I can send them to NLP pipeline 
and get Atoms. Let's say most of the people tweet about Presidential 
Election.  I assumed that,  when feeding these atoms into atomspace, 
somehow atoms related to "Election" will get High STI?. Since they occur 
more often now-a-days. Say, there will be a lot of Trump and Hilary Clinton 
atoms. Somehow they get high STI  (?!!) and i can retrieve those top ranked 
atoms and its related atoms (since STI is also diffused to similar atoms). 

That was the idea. But i don't know, whether Attention values works like 
this for pursuing the above mentioned. :-(.  What am i missing??

Boosting STI/LTI would be done when they become relevant i.e they just 
entered the AtomSpace or NLP found them to be useful.
I could not figure out, on what basis stimulus is given to atom. In 
general, How atoms become important/relevant?





 
 

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/3d361b65-5ab6-448b-9e15-fe59c6151252%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] About Attention Values and Truth Values

[Roman Treutlein]

Hey,

Short explanation first:
STI: This value indicates how relevant this atom is to the currently 
running process/context
LTI: This value indicates how relevant this atom might be in future 
processes/context (Atoms with low LTI have no future use and get delete if 
the AS gets to big)
VLTI: This is a simple boolean that indicates that this atom should never 
be deleted. (Useful for system components that are written in Atomese)

so STI values are only ever useful at the current point in time so storing 
them in a DB makes no sense. Now storing only those Atom which have a high 
STI/LTI in the DB that might be useful but there is no code that does that 
currently. In my opinion just storing the whole AS in a DB works just as 
well.

Now when you load the atoms back into the AS then it might make sense to 
give all those Atoms an LTI boost.

I am not sure what exactly you want to use the AttentionValues for but in 
general they are supposed to speed up other processes like the PLN System 
by restricting their search space to only Atoms with a high STI.

Misgana has a working but experimental implementation for this as far as I 
know.

In regards to using ECAN:
generate fake sentences --> feed atoms in atomspace --> Boost STI/LTI --> 
Set Memory Capacity

I assume you got that from on of the experiments. You obviously don't want 
to generate face sentences so we can ignore that. Feeding Atoms into the 
AtomSpace would be done by the NLP Pipeline. Boosting STI/LTI would be done 
when they become relevant i.e they just entered the AtomSpace or NLP found 
them to be useful. (again ask misgana about his implementation of this). 
Setting the Memory Capacity you probably don't have to do but it's just a 
value in the config file.

If you have some more specific question about how ECAN works (i.e. 
spreading of STI , rent collection , setting of the AFB) i can answer those.

regards
/Roman

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/5c47a39e-e27c-4a75-9572-cd569ab51944%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] About Attention Values and Truth Values

[Roman Treutlein]

Hey vishnu,

what you are suggesting does sound doable.

In your case, you would just want to stimulate atoms every time they have 
been parsed by the NLP pipeline. Something like this might already exist 
not sure ask misgana.

More generally there would be many Mind-Agents that are running in the 
cogserver. And everytime any of those agents deem it useful they can 
stimulate an atom, the actual STI value given to an Atom is dynamic based 
on other variables but you can provide a factor to indicate stimulate this 
Atom a lot or only a little. Examples of this would be that the PLN system 
successfully used an Atom for a deduction it is trying to make so it 
stimulates it so similar atoms come into focus and help the continued 
process. Or some Agents related to perception have just seen X which 
corresponds to one or more Atoms so they stimulated them as they will 
likely be of interest in the moment.

Now for retrieving these values you will probably have to write an 
Cogserver Module that implements a command that gives you the top ranking 
atoms.
If you want this to be done automatically you need to have an Agent. (Which 
are alway part of a Module)

hope that helps.

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/2c2d538f-0549-40b7-bfd9-a242d7df8cd7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Re: ImplicationLink?

[Linas Vepstas]

On Wed, Oct 12, 2016 at 12:53 PM, Nil Geisweiller 
wrote:

>
>
> On 10/12/2016 06:55 PM, Linas Vepstas wrote:
>
>> Well, yes, but Nil,, look at the core issue: the variable X in the
>> Implication link is bound, but the unit test is pretending that its
>> free.  My question is: are you *sure* you really want the
>> implicationLink to inherit from Scope Link (and thus, always bind it's
>> variables)?
>>
>
> X is supposed to be free in the ImplicationLink,


Really?  The C++ code has ImplicationLink inheriting from ScopeLink, thus
making it bound.  Perhaps ImplicationLink should not inherit from ScopeLink?

?


> bound to the PutLink. Yes I am sure I want it free in the ImplicationLink.
> Having ImplicationLink inherit Scope should not prevent that. The syntax
> itself is ambiguity free, if there are ambiguities in the code it's a bug
> and it should be fixed.
>
> Again, I'm happy to fix anything related to that once the issue reappears.
>
> Nil
>
>
>> --linas
>>
>>
>> On Wed, Oct 12, 2016 at 10:39 AM, Nil Geisweiller
>> > wrote:
>>
>> OK, when they fail again I guess you might feel free to push to the
>> master, as we're apparently using as a dev branch, and then I'll fix
>> that.
>>
>> Nil
>>
>> On 10/12/2016 06:17 PM, Linas Vepstas wrote:
>>
>> No, actually, I worked around that.
>>
>> The only reason that PutLinkUTest currently passes is because
>> PutLink
>> fails to treat ScopeLinks correctly.  When that gets fixed, the
>> unit
>> test will fail ... the issue remains the same.
>>
>> --linas
>>
>> On Tue, Oct 11, 2016 at 11:57 PM, Nil Geisweiller
>> 
>> > >> wrote:
>>
>>  Are these unit tests still failing?
>>
>>  Nil
>>
>>
>>  On 10/11/2016 08:36 PM, Linas Vepstas wrote:
>>
>>  47 unit tests fail ... I'm not sure if they all fail
>> for the same
>>  reason, though.
>>
>>  For example PutLink
>>
>>  (PutLink
>>  (LambdaLink
>>(VariableList
>>  (TypedVariableLink
>>(VariableNode "$X")
>>(TypeNode "PredicateNode")
>>  )
>>  (TypedVariableLink
>>(VariableNode "$Y")
>>(TypeNode "PredicateNode")
>>  )
>>)
>>(AndLink
>>  (EvaluationLink
>>(PredicateNode "acquainted")
>>(ListLink
>>  (VariableNode "$X")
>>  (VariableNode "$Y")
>>)
>>  )
>>  (ImplicationLink
>>(VariableNode "$X")  ; this is
>> alpha-converted to $foo1233
>>(PredicateNode "is-human")
>>  )
>>  (ImplicationLink
>>(VariableNode "$X") ; this is
>> alpha-converted  to $bar456
>>(PredicateNode "is-human")
>>  )
>>)
>>  )
>>  (ListLink
>>(PredicateNode "is-Self")
>>(PredicateNode "is-Bob")
>>  )
>>  )
>>
>>  So, because the implication link is scoped, the result
>> of the
>>  variable
>>  substitution is
>>
>>  (AndLink
>>  (ImplicationLink
>>(VariableNode "$foo123")
>>(PredicateNode "is-human")
>>  )
>>  (ImplicationLink
>>(VariableNode "$bar456")
>>(PredicateNode "is-human")
>>  )
>>  (EvaluationLink
>>(PredicateNode "acquainted")
>>(ListLink
>>  (PredicateNode "is-Self")
>>  (PredicateNode "is-Bob")
>>)
>>  )
>>  )
>>
>>  which is not what the unit test expects. The problem
>> with using
>>  either
>>  ScopeLink or LambdaLink is that it becomes impossible
>> to have a
>>  stable
>>  variable name -- it can be alpha-converted to anything,
>> so any
>>  algo that
>>

Re: [opencog-dev] Re: ImplicationLink?

[Ben Goertzel]

Wait ... we can have nested ScopeLinks, so that a variable embedded in
two ScopeLInks can be bound by the outer one or the inner one... no?

On Wed, Oct 12, 2016 at 4:08 PM, Linas Vepstas  wrote:
>
>
> On Wed, Oct 12, 2016 at 12:53 PM, Nil Geisweiller 
> wrote:
>>
>>
>>
>> On 10/12/2016 06:55 PM, Linas Vepstas wrote:
>>>
>>> Well, yes, but Nil,, look at the core issue: the variable X in the
>>> Implication link is bound, but the unit test is pretending that its
>>> free.  My question is: are you *sure* you really want the
>>> implicationLink to inherit from Scope Link (and thus, always bind it's
>>> variables)?
>>
>>
>> X is supposed to be free in the ImplicationLink,
>
>
> Really?  The C++ code has ImplicationLink inheriting from ScopeLink, thus
> making it bound.  Perhaps ImplicationLink should not inherit from ScopeLink?
>
> ?
>
>>
>> bound to the PutLink. Yes I am sure I want it free in the ImplicationLink.
>> Having ImplicationLink inherit Scope should not prevent that. The syntax
>> itself is ambiguity free, if there are ambiguities in the code it's a bug
>> and it should be fixed.
>>
>> Again, I'm happy to fix anything related to that once the issue reappears.
>>
>> Nil
>>
>>>
>>> --linas
>>>
>>>
>>> On Wed, Oct 12, 2016 at 10:39 AM, Nil Geisweiller
>>> > wrote:
>>>
>>> OK, when they fail again I guess you might feel free to push to the
>>> master, as we're apparently using as a dev branch, and then I'll fix
>>> that.
>>>
>>> Nil
>>>
>>> On 10/12/2016 06:17 PM, Linas Vepstas wrote:
>>>
>>> No, actually, I worked around that.
>>>
>>> The only reason that PutLinkUTest currently passes is because
>>> PutLink
>>> fails to treat ScopeLinks correctly.  When that gets fixed, the
>>> unit
>>> test will fail ... the issue remains the same.
>>>
>>> --linas
>>>
>>> On Tue, Oct 11, 2016 at 11:57 PM, Nil Geisweiller
>>> 
>>> >> >> wrote:
>>>
>>>  Are these unit tests still failing?
>>>
>>>  Nil
>>>
>>>
>>>  On 10/11/2016 08:36 PM, Linas Vepstas wrote:
>>>
>>>  47 unit tests fail ... I'm not sure if they all fail
>>> for the same
>>>  reason, though.
>>>
>>>  For example PutLink
>>>
>>>  (PutLink
>>>  (LambdaLink
>>>(VariableList
>>>  (TypedVariableLink
>>>(VariableNode "$X")
>>>(TypeNode "PredicateNode")
>>>  )
>>>  (TypedVariableLink
>>>(VariableNode "$Y")
>>>(TypeNode "PredicateNode")
>>>  )
>>>)
>>>(AndLink
>>>  (EvaluationLink
>>>(PredicateNode "acquainted")
>>>(ListLink
>>>  (VariableNode "$X")
>>>  (VariableNode "$Y")
>>>)
>>>  )
>>>  (ImplicationLink
>>>(VariableNode "$X")  ; this is
>>> alpha-converted to $foo1233
>>>(PredicateNode "is-human")
>>>  )
>>>  (ImplicationLink
>>>(VariableNode "$X") ; this is
>>> alpha-converted  to $bar456
>>>(PredicateNode "is-human")
>>>  )
>>>)
>>>  )
>>>  (ListLink
>>>(PredicateNode "is-Self")
>>>(PredicateNode "is-Bob")
>>>  )
>>>  )
>>>
>>>  So, because the implication link is scoped, the result
>>> of the
>>>  variable
>>>  substitution is
>>>
>>>  (AndLink
>>>  (ImplicationLink
>>>(VariableNode "$foo123")
>>>(PredicateNode "is-human")
>>>  )
>>>  (ImplicationLink
>>>(VariableNode "$bar456")
>>>(PredicateNode "is-human")
>>>  )
>>>  (EvaluationLink
>>>(PredicateNode "acquainted")
>>>(ListLink
>>>  (PredicateNode "is-Self")
>>>  (PredicateNode "is-Bob")
>>>)
>>>  )
>>>  )
>>>
>>>   

[opencog-dev] Re: ImplicationLink?

[Linas Vepstas]

Well, yes, but Nil,, look at the core issue: the variable X in the
Implication link is bound, but the unit test is pretending that its free.
My question is: are you *sure* you really want the implicationLink to
inherit from Scope Link (and thus, always bind it's variables)?

--linas


On Wed, Oct 12, 2016 at 10:39 AM, Nil Geisweiller 
wrote:

> OK, when they fail again I guess you might feel free to push to the
> master, as we're apparently using as a dev branch, and then I'll fix that.
>
> Nil
>
> On 10/12/2016 06:17 PM, Linas Vepstas wrote:
>
>> No, actually, I worked around that.
>>
>> The only reason that PutLinkUTest currently passes is because PutLink
>> fails to treat ScopeLinks correctly.  When that gets fixed, the unit
>> test will fail ... the issue remains the same.
>>
>> --linas
>>
>> On Tue, Oct 11, 2016 at 11:57 PM, Nil Geisweiller
>> > wrote:
>>
>> Are these unit tests still failing?
>>
>> Nil
>>
>>
>> On 10/11/2016 08:36 PM, Linas Vepstas wrote:
>>
>> 47 unit tests fail ... I'm not sure if they all fail for the same
>> reason, though.
>>
>> For example PutLink
>>
>> (PutLink
>> (LambdaLink
>>   (VariableList
>> (TypedVariableLink
>>   (VariableNode "$X")
>>   (TypeNode "PredicateNode")
>> )
>> (TypedVariableLink
>>   (VariableNode "$Y")
>>   (TypeNode "PredicateNode")
>> )
>>   )
>>   (AndLink
>> (EvaluationLink
>>   (PredicateNode "acquainted")
>>   (ListLink
>> (VariableNode "$X")
>> (VariableNode "$Y")
>>   )
>> )
>> (ImplicationLink
>>   (VariableNode "$X")  ; this is alpha-converted to
>> $foo1233
>>   (PredicateNode "is-human")
>> )
>> (ImplicationLink
>>   (VariableNode "$X") ; this is alpha-converted  to
>> $bar456
>>   (PredicateNode "is-human")
>> )
>>   )
>> )
>> (ListLink
>>   (PredicateNode "is-Self")
>>   (PredicateNode "is-Bob")
>> )
>> )
>>
>> So, because the implication link is scoped, the result of the
>> variable
>> substitution is
>>
>> (AndLink
>> (ImplicationLink
>>   (VariableNode "$foo123")
>>   (PredicateNode "is-human")
>> )
>> (ImplicationLink
>>   (VariableNode "$bar456")
>>   (PredicateNode "is-human")
>> )
>> (EvaluationLink
>>   (PredicateNode "acquainted")
>>   (ListLink
>> (PredicateNode "is-Self")
>> (PredicateNode "is-Bob")
>>   )
>> )
>> )
>>
>> which is not what the unit test expects. The problem with using
>> either
>> ScopeLink or LambdaLink is that it becomes impossible to have a
>> stable
>> variable name -- it can be alpha-converted to anything, so any
>> algo that
>> depends on having a fixed, well-known variable name will fail.
>>
>> In this case -- I am not sure -- if you want ImplicationLink to be
>> scoped, then the unit test is wrong.  But is the unit test is
>> right,
>> then implication link must not be scoped.  I cannot tell which
>> one is
>> wanted.
>>
>> --linas
>>
>>
>>
>> On Tue, Oct 11, 2016 at 12:12 PM, Nil Geisweiller
>> 
>> >
>> >> wrote:
>>
>>  Linas,
>>
>>  I don't have time to get into that right now. If you can
>> point to
>>  where exactly it breaks (like a unit test on your branch)
>> it would
>>  help. In any case I look carefully into that and reply
>> tomorrow.
>>
>>  Nil
>>
>>
>>  On 10/11/2016 06:55 PM, Linas Vepstas wrote:
>>
>>  You made it inherit from ScopeLink, thus making the
>> variables in it
>>  implicitly scoped.  Then you added the file
>> ImplicationLink.cc,
>>  and have
>>  notes in there, complaining about how variables are
>> implcitly
>>  scoped.
>>  The wiki page for it,
>> http://wiki.opencog.org/w/ImplicationLink
>> 
>>  > > 

Re: [opencog-dev] Re: ImplicationLink?

[Ben Goertzel]

Potentially Atomspace could host other sorts of variables  But,
since ImplicationLink is a PLN (or other formal logic) thing, it makes
sense to have the variables involved with implicationLink bound
somewhere, since that is how formal logic works, right?

Potentially this quantification could be left implicit sometimes.  But
I recall we decided a year or so ago that "implicit quantification"
was causing too much confusion, and we wanted all VariableNodes to be
bound somewhere or other in the Atomspace 

So I think the above is the backdrop for making ImplicationLink a kind
of ScopeLink...

There may be some technical detail I am overlooking though...

On Wed, Oct 12, 2016 at 8:55 AM, Linas Vepstas  wrote:
> Well, yes, but Nil,, look at the core issue: the variable X in the
> Implication link is bound, but the unit test is pretending that its free.
> My question is: are you *sure* you really want the implicationLink to
> inherit from Scope Link (and thus, always bind it's variables)?
>
> --linas
>
>
> On Wed, Oct 12, 2016 at 10:39 AM, Nil Geisweiller 
> wrote:
>>
>> OK, when they fail again I guess you might feel free to push to the
>> master, as we're apparently using as a dev branch, and then I'll fix that.
>>
>> Nil
>>
>> On 10/12/2016 06:17 PM, Linas Vepstas wrote:
>>>
>>> No, actually, I worked around that.
>>>
>>> The only reason that PutLinkUTest currently passes is because PutLink
>>> fails to treat ScopeLinks correctly.  When that gets fixed, the unit
>>> test will fail ... the issue remains the same.
>>>
>>> --linas
>>>
>>> On Tue, Oct 11, 2016 at 11:57 PM, Nil Geisweiller
>>> > wrote:
>>>
>>> Are these unit tests still failing?
>>>
>>> Nil
>>>
>>>
>>> On 10/11/2016 08:36 PM, Linas Vepstas wrote:
>>>
>>> 47 unit tests fail ... I'm not sure if they all fail for the same
>>> reason, though.
>>>
>>> For example PutLink
>>>
>>> (PutLink
>>> (LambdaLink
>>>   (VariableList
>>> (TypedVariableLink
>>>   (VariableNode "$X")
>>>   (TypeNode "PredicateNode")
>>> )
>>> (TypedVariableLink
>>>   (VariableNode "$Y")
>>>   (TypeNode "PredicateNode")
>>> )
>>>   )
>>>   (AndLink
>>> (EvaluationLink
>>>   (PredicateNode "acquainted")
>>>   (ListLink
>>> (VariableNode "$X")
>>> (VariableNode "$Y")
>>>   )
>>> )
>>> (ImplicationLink
>>>   (VariableNode "$X")  ; this is alpha-converted to
>>> $foo1233
>>>   (PredicateNode "is-human")
>>> )
>>> (ImplicationLink
>>>   (VariableNode "$X") ; this is alpha-converted  to
>>> $bar456
>>>   (PredicateNode "is-human")
>>> )
>>>   )
>>> )
>>> (ListLink
>>>   (PredicateNode "is-Self")
>>>   (PredicateNode "is-Bob")
>>> )
>>> )
>>>
>>> So, because the implication link is scoped, the result of the
>>> variable
>>> substitution is
>>>
>>> (AndLink
>>> (ImplicationLink
>>>   (VariableNode "$foo123")
>>>   (PredicateNode "is-human")
>>> )
>>> (ImplicationLink
>>>   (VariableNode "$bar456")
>>>   (PredicateNode "is-human")
>>> )
>>> (EvaluationLink
>>>   (PredicateNode "acquainted")
>>>   (ListLink
>>> (PredicateNode "is-Self")
>>> (PredicateNode "is-Bob")
>>>   )
>>> )
>>> )
>>>
>>> which is not what the unit test expects. The problem with using
>>> either
>>> ScopeLink or LambdaLink is that it becomes impossible to have a
>>> stable
>>> variable name -- it can be alpha-converted to anything, so any
>>> algo that
>>> depends on having a fixed, well-known variable name will fail.
>>>
>>> In this case -- I am not sure -- if you want ImplicationLink to
>>> be
>>> scoped, then the unit test is wrong.  But is the unit test is
>>> right,
>>> then implication link must not be scoped.  I cannot tell which
>>> one is
>>> wanted.
>>>
>>> --linas
>>>
>>>
>>>
>>> On Tue, Oct 11, 2016 at 12:12 PM, Nil Geisweiller
>>> 
>>> >>
>>> >> wrote:
>>>
>>>  Linas,
>>>
>>>  I don't have time to get into that right now. If you can
>>> point to
>>>   

[opencog-dev] Contributing to OpenCog

[Vineet Parikh]

Hi there,

I recently completed my open source project that I started in Summer 2016.  
The project involved documenting a core feature of Linux XIA, specifically 
the Longest-Prefix-Matching principal  where I helped experiment/verify all 
relevant constructs - including installing virtual machines, downloading 
code from GitHub, compiling Linux kernel with new code from XIA's 
repository, deploying the new Linux kernel, testing this new functionality 
and writing pertinent documentation (as well as a short experiment on how 
LPM works).  Although my love for writing code started a while ago, taking 
an intensive programming course at Harvard Extension Summer School (Summer 
2015) helped me a lot.

I have received awards for a research project on AI theory from Intel and 
the ACM.

I am an enthusiastic high school senior with a lot of value to offer. 

My Linkedin profile can be found here. 


I am interested in working on a pertinent initiative at OpenCog. Is there a 
project I can work on?

Thanks for your time,
Vineet Parikh
(732) 331.6409

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/1f994326-789c-4824-94c3-443d275151e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: ImplicationLink?

['Nil Geisweiller' via opencog]

On 10/13/2016 02:38 AM, Ben Goertzel wrote:

Wait ... we can have nested ScopeLinks, so that a variable embedded in
two ScopeLInks can be bound by the outer one or the inner one... no?


Yes, no problem, if a variable is scoped by both then the inner one will 
cover the outer one.


Anyway, I don't see a problem with having a C++ ImplicationLink class 
inherit the ScopeLink class. The only think to take care of is to have 
no variable extracted when there are 2 arguments, that is when using the 
non sugar for of the ImplicationLink


ImplicationLink
  P
  Q

I think that is what the code does, but if it doesn't or its buggy it 
should be fixed, I'm happy to fix it as soon as unit test fails because 
of it.


Nil



On Wed, Oct 12, 2016 at 4:08 PM, Linas Vepstas  wrote:



On Wed, Oct 12, 2016 at 12:53 PM, Nil Geisweiller 
wrote:




On 10/12/2016 06:55 PM, Linas Vepstas wrote:


Well, yes, but Nil,, look at the core issue: the variable X in the
Implication link is bound, but the unit test is pretending that its
free.  My question is: are you *sure* you really want the
implicationLink to inherit from Scope Link (and thus, always bind it's
variables)?



X is supposed to be free in the ImplicationLink,



Really?  The C++ code has ImplicationLink inheriting from ScopeLink, thus
making it bound.  Perhaps ImplicationLink should not inherit from ScopeLink?

?



bound to the PutLink. Yes I am sure I want it free in the ImplicationLink.
Having ImplicationLink inherit Scope should not prevent that. The syntax
itself is ambiguity free, if there are ambiguities in the code it's a bug
and it should be fixed.

Again, I'm happy to fix anything related to that once the issue reappears.

Nil



--linas


On Wed, Oct 12, 2016 at 10:39 AM, Nil Geisweiller
> wrote:

 OK, when they fail again I guess you might feel free to push to the
 master, as we're apparently using as a dev branch, and then I'll fix
 that.

 Nil

 On 10/12/2016 06:17 PM, Linas Vepstas wrote:

 No, actually, I worked around that.

 The only reason that PutLinkUTest currently passes is because
 PutLink
 fails to treat ScopeLinks correctly.  When that gets fixed, the
unit
 test will fail ... the issue remains the same.

 --linas

 On Tue, Oct 11, 2016 at 11:57 PM, Nil Geisweiller
 
 >> wrote:

  Are these unit tests still failing?

  Nil


  On 10/11/2016 08:36 PM, Linas Vepstas wrote:

  47 unit tests fail ... I'm not sure if they all fail
 for the same
  reason, though.

  For example PutLink

  (PutLink
  (LambdaLink
(VariableList
  (TypedVariableLink
(VariableNode "$X")
(TypeNode "PredicateNode")
  )
  (TypedVariableLink
(VariableNode "$Y")
(TypeNode "PredicateNode")
  )
)
(AndLink
  (EvaluationLink
(PredicateNode "acquainted")
(ListLink
  (VariableNode "$X")
  (VariableNode "$Y")
)
  )
  (ImplicationLink
(VariableNode "$X")  ; this is
 alpha-converted to $foo1233
(PredicateNode "is-human")
  )
  (ImplicationLink
(VariableNode "$X") ; this is
 alpha-converted  to $bar456
(PredicateNode "is-human")
  )
)
  )
  (ListLink
(PredicateNode "is-Self")
(PredicateNode "is-Bob")
  )
  )

  So, because the implication link is scoped, the result
 of the
  variable
  substitution is

  (AndLink
  (ImplicationLink
(VariableNode "$foo123")
(PredicateNode "is-human")
  )
  (ImplicationLink
(VariableNode "$bar456")
(PredicateNode "is-human")
  )
  (EvaluationLink
(PredicateNode "acquainted")