I've added some notes about that
http://wiki.opencog.org/w/ExtensionalImplicationScopeLink#Remarks
My feeling based is that the ImplicationScopeLink (I mean, either mixed,
extensional or intensional) is what we want in most cases, which is good
given that it's syntactically simpler than
On 10/17/2016 10:17 AM, Ben Goertzel wrote:
As for the name
ImplicationScopeLink
at first I thought I would prefer
ScopingImplicationLink
but now I'm not sure ;p
Anyway, ugly as it is, I think it may be better to use two different
link types for the different variants, under the general
As for the name
> ImplicationScopeLink
at first I thought I would prefer
ScopingImplicationLink
but now I'm not sure ;p
Anyway, ugly as it is, I think it may be better to use two different
link types for the different variants, under the general principle we've been
leaning towards lately,
On 10/16/2016 07:32 AM, Linas Vepstas wrote:
Shortly after sending this message, I decided that it was a bad idea to
let a sleeping bug lie. I am totally and completly confused by
ImplicationLink. I flat out do not understand it, at all, not one whit.
Consider this:
(ImplicationLink
Shortly after sending this message, I decided that it was a bad idea to let
a sleeping bug lie. I am totally and completly confused by ImplicationLink.
I flat out do not understand it, at all, not one whit.
Consider this:
(ImplicationLink (VariableNode "$X") (PredicateNode "is-human"))
In
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
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
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
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
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
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
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")
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,
13 matches
Mail list logo