EvidenceCountTV

[Ben Goertzel]

Nil, others,

In working out w/Amen how to apply PLN to various Atoms derived from
natural language, I started to think we might want a truth value that
has the following fields:

***
float positive_evidence

float total_evidence // aka count, but this should be an OPTIONAL value
***

Where the total_evidence is defined one can then say

probabilistic strength = positive_evidence / total_evidence

The point is that for an Atom like the EvaluationLink in the construct

EvaluationLink
PredicateNode "eat"
List
ConceptNode "cat"
ConceptNode "mouse"

we can meaningfully accumulate a number indicating how many instances
of this relationship have been observed (the positive_evidence of the
Link) ... but there's no obviously maximally meaningful way to
normalize this positive_evidence value into a probabilistic or fuzzy
strength value....

If we apply Evaluation2Member to get

MemberLink
ConceptNode "mouse"
SatisfyingSet
VariableNode $X
EvaluationLink
PredicateNode "eat"
List
ConceptNode "cat"
$X

then we could meaningfully come up with some fuzzy strength, and if we
then apply M2I to get

InheritanceLink
ConceptNode "mouse"
SatisfyingSet
VariableNode $X
EvaluationLink
PredicateNode "eat"
List
ConceptNode "cat"
$X

then we can normalize the positive-evidence in the obvious way (i.e.
the total_evidence we want for the InheritanceLink is the total number
of entities satisfying the SatisfyingSet, within the assumed overall
universe of discourse)...

If this approach is right, then the PLN formulas like Eval2Member and
M2I would propagate positive_evidence values rather than strengths...

No changes for the PLN rules acting on straightforwardly probabilistic
links like InheritanceLinks would be needed, because these rules use
strength which can be derived from positive_evidence and
total_evidence...

Adding new TV types like this is annoying, but OTOH abusing the
"strength" or "mean" field in an existing TV type by making it mean
positive_evidence for certain link types, seems even more annoying...

Hopefully someone will bite the bullet and implement ProtoAtom soon ;p ;)

thoughts?
ben

--
Ben Goertzel, PhD
http://goertzel.org

Super-benevolent super-intelligence is the thought the Global Brain is
currently struggling to form...

[Nil Geisweiller]

On 10/19/2016 08:40 PM, Ben Goertzel wrote:
> Nil, others,
>
> In working out w/Amen how to apply PLN to various Atoms derived from
> natural language, I started to think we might want a truth value that
> has the following fields:
>
> ***
> float positive_evidence
>
> float total_evidence // aka count, but this should be an OPTIONAL value
> ***
>
> Where the total_evidence is defined one can then say
>
> probabilistic strength = positive_evidence / total_evidence
>
> The point is that for an Atom like the EvaluationLink in the construct
>
> EvaluationLink
> PredicateNode "eat"
> List
> ConceptNode "cat"
> ConceptNode "mouse"
>
> we can meaningfully accumulate a number indicating how many instances
> of this relationship have been observed (the positive_evidence of the

I'm trying to understand specifically your problem. By instances I
suppose you mean

EvaluationLink (stv 1 1)
PredicateNode "eat_342"
List
ConceptNode "cat_132"
ConceptNode "mouse_243"

for a positive one.

Evaluation (stv 0 1)
PredicateNode "eat_635"
List
ConceptNode "cat_768"
ConceptNode "mouse_129"

for a negative one.

Then you're goal is to define the strength and count of

> EvaluationLink (stv strength count)

> PredicateNode "eat"
> List
> ConceptNode "cat"
> ConceptNode "mouse"

right?

But the calculation of strength depends on the semantics you want to
this TV to have, right?

There is no standard semantics for that according to PLN, as far as I know.

For instance you may say that the strength represents the probability of
cat eating a mouse vs not eating a mouse, and then your total count is
the sum of positive and negative instances.

> EvaluationLink (stv strength count)

> PredicateNode "eat"
> List
> ConceptNode "cat"
> ConceptNode "mouse"

I suppose the count would the number of all instances you have, and the
strength would the number instance with (stv 1 1) / by the number of
instances with (stv 0 1). But again that's up to the semantics you want
it to capture.

> Link) ... but there's no obviously maximally meaningful way to
> normalize this positive_evidence value into a probabilistic or fuzzy
> strength value....

If there's no obvious way, it means the semantics is not completely
determined, then it needs to be determined...

>
> If we apply Evaluation2Member to get
>
> MemberLink
> ConceptNode "mouse"
> SatisfyingSet
> VariableNode $X
> EvaluationLink
> PredicateNode "eat"
> List
> ConceptNode "cat"
> $X
>
> then we could meaningfully come up with some fuzzy strength, and if we
> then apply M2I to get
>
> InheritanceLink
> ConceptNode "mouse"
> SatisfyingSet
> VariableNode $X
> EvaluationLink
> PredicateNode "eat"
> List
> ConceptNode "cat"
> $X

Do you mean?

> InheritanceLink
> SetLink ConceptNode "mouse"

> SatisfyingSet
> VariableNode $X
> EvaluationLink
> PredicateNode "eat"
> List
> ConceptNode "cat"
> $X

that is what the PLN gives, which contradicts the implementation, which
match what you wrote... I'm confused.

>
> then we can normalize the positive-evidence in the obvious way (i.e.
> the total_evidence we want for the InheritanceLink is the total number
> of entities satisfying the SatisfyingSet, within the assumed overall
> universe of discourse)...

No, it is the count of (SetLink (Concept "Ben")), which is 1. Or if that
weird M2I as currently implemented rule is correct, it is the count of
(Concept "Ben"). Do we agree on that?

>
> If this approach is right, then the PLN formulas like Eval2Member and
> M2I would propagate positive_evidence values rather than strengths...

Since I can't make sense of these rules and I'm not sure what they are
supposed to be, I can't comment.

>
> No changes for the PLN rules acting on straightforwardly probabilistic
> links like InheritanceLinks would be needed, because these rules use
> strength which can be derived from positive_evidence and
> total_evidence...

Agreed.

>
> Adding new TV types like this is annoying, but OTOH abusing the
> "strength" or "mean" field in an existing TV type by making it mean
> positive_evidence for certain link types, seems even more annoying...

Agreed. Ultimately I think we could offer a positive_evidence setter.
But I still don't understand the need for propagating positive_evidence
without knowing the total count.

Nil

[Nil Geisweiller]

On 10/20/2016 04:53 PM, Nil Geisweiller wrote:
>> then we can normalize the positive-evidence in the obvious way (i.e.
>> the total_evidence we want for the InheritanceLink is the total number
>> of entities satisfying the SatisfyingSet, within the assumed overall
>> universe of discourse)...
>
> No, it is the count of (SetLink (Concept "Ben")), which is 1. Or if that
> weird M2I as currently implemented rule is correct, it is the count of
> (Concept "Ben"). Do we agree on that?

Actually it would be at most 1 (or the size of (Concept "Ben") assuming
the M2I rule I don't understand), since we need to account for the
uncertainty on the conditional probability itself.

In the PLN book it is confidence over the MemberLink times some constant
which depends of the cohesiveness of the set (here the satisfying set of
eat(X, cat)). I do see the stuff, but it's not just about cohesiveness,
there is another implicit assumption, which is that

if X and Y are in S, then Set X Y are in S, then the whole stuff starts
making sense, but cohesiveness alone is not enough to capture that, I
think. We already had an email exchange about this I'm sure, but I
forgot the conclusion (if there were any).

Nil

[Ben Goertzel]

Hi Nil,

> I'm trying to understand specifically your problem. By instances I suppose
> you mean
>
> EvaluationLink (stv 1 1)
> PredicateNode "eat_342"
> List
> ConceptNode "cat_132"
> ConceptNode "mouse_243"
>
> for a positive one.
>
> Evaluation (stv 0 1)
> PredicateNode "eat_635"
> List
> ConceptNode "cat_768"
> ConceptNode "mouse_129"
>
> for a negative one.

Yes!

> Then you're goal is to define the strength and count of
>
>> EvaluationLink (stv strength count)
>> PredicateNode "eat"
>> List
>> ConceptNode "cat"
>> ConceptNode "mouse"
>
> right?

My goal is to define the truth value of the above link ...

> But the calculation of strength depends on the semantics you want to this TV
> to have, right?
>
> There is no standard semantics for that according to PLN, as far as I know.
>
> For instance you may say that the strength represents the probability of cat
> eating a mouse vs not eating a mouse, and then your total count is the sum
> of positive and negative instances.

Yeah, but

-- probability of cat eating mouse, versus cat eating arbitrary X

-- probability of cat eating mouse, versus arbitrary Y eating mouse

-- probability of cat eating mouse, versus arbitrary relation Z
holding between cat and mouse

each give different strengths, all formed by taking the same
positive-evidence value and normalizing it by a different
total-evidence

We could also form

-- probability of observing "cat eating mouse", as opposed to
observing "Z(X,Y)" for some triple (X,Y,Z) ...

-- probability of observing "cat eating mouse", as opposed to
observing Z(L) for some predicate Z and some arg-list L ... i.e. the
probability of observations of "Cat eating mouse" in the space of all
predicate-evaluations whose truth one has observed ...

The latter would be an OK analogue of "node probability" I guess...

If one chose any of the above systematically to define strength s, and
one then retained both s and total_evidence (count =n or confidence),
then one could get back positive_evidence from (s, n) .... However,
choosing one of these seems kind of a hack which is why it seemed
maybe better to just store the positive_evidence... and then
synthesize whatever strengths one needs on the fly...

>> EvaluationLink (stv strength count)
>> PredicateNode "eat"
>> List
>> ConceptNode "cat"
>> ConceptNode "mouse"
>
> I suppose the count would the number of all instances you have,

instances of what, though?

> and the
> strength would the number instance with (stv 1 1) / by the number of
> instances with (stv 0 1). But again that's up to the semantics you want it
> to capture.

Yes - which may well be different in different cases...

> If there's no obvious way, it means the semantics is not completely
> determined, then it needs to be determined...

I have a feeling the desired normalization will not be the same in all
cases, whereas the positive-evidence is always the central number
required in all cases...

Hmm, let's see...

The MemberLink before M2I means

"mouse is a member of the set of things that cats eat"

Whereas, the InheritanceLink after M2I means

"X is a member of mouse, implies (extensionally and intensionally) X
is a member of the set of things that cats eat"

I.e. the M2I rule in its currently implemented form relies on the
interpretation of

ConceptNode "cat"

as equivalent to

SatisfyingSet
MemberLink
$X
ConceptNode "cat"

> No, it is the count of (SetLink (Concept "Ben")), which is 1. Or if that
> weird M2I as currently implemented rule is correct, it is the count of
>

It's the count of

ConceptNode "cat"

which is the count of

SatisfyingSet
MemberLink
$X
ConceptNode "cat"

> Agreed. Ultimately I think we could offer a positive_evidence setter. But I
> still don't understand the need for propagating positive_evidence without
> knowing the total count.

It's because the same positive-evidence value makes sense in the
context of multiple different choices for the total count...

-- Ben

[Nil Geisweiller]

Hi,

I think someone suggested a while ago that positive and total counts be
the main data stored in a tv, and the probability would be calculated on
the fly when requested. The API could offer methods to access and modify
just the positive count, and so if the total count is let undefined the
probability would be NAN. This could be done in a way that maintains
compatibility with the existing TV API, so there would be no need to
introduce another TV type. Not that introducing a new TV type is bad,
but I feel it is both sufficiently simple and useful across types that
we might just put it in the base class. What do you think?

Regarding the total count, I see what you mean, on an abstract level at
least. So let's put the requirement: whenever an reasoning rule can be
agnostic of the total count and some if its premises have undefined
total count, the rule should be able to propagate just the positive count.

Do these 2 points above entirely capture your needs?

On 10/20/2016 05:57 PM, Ben Goertzel wrote:
> Whereas, the InheritanceLink after M2I means
>
> "X is a member of mouse, implies (extensionally and intensionally) X
> is a member of the set of things that cats eat"

Yep, that's what I read too. Hmm, this 2 layers (elements of elements)
inclusion gives me the creep. ;-) But I'm not sure why, hopefully
experimentation will help us to get this straight, and this is coming soon.

Nil

[Ben Goertzel]

Yes, those 2 points would satisfy our current needs... thx...

[Nil Geisweiller]

On 10/21/2016 08:44 AM, Ben Goertzel wrote:
> Yes, those 2 points would satisfy our current needs... thx...

Looking at the code, I'm thinking it's gonna be simpler to create a new
tv type, possibly inheriting from SimpleTV.

That is because the base TV class is completely abstract, adding the
methods is only gonna force other sub-classes to implement this, which
is a pain, although might be what we want, but since its usage is not
entirely sure to me at that point I suppose we should go with the
simpler stuff first.

So I intend to create an EvidenceCountTruthValue (possibly inheriting
from SimpleTruthValue) + scheme binding. That should cover your current
needs. Let me know otherwise.

Nil

>
> On Oct 21, 2016 1:23 PM, "Nil Geisweiller" <ngei...@googlemail.com

[Nil Geisweiller]

Of course I'm happy if Amen or someone else wants to give a shot, but
maybe he/she has already too much stuff on his/her plate, and I or Linas
will be faster since we know well that part of the code. Again let me know.

Nil

[Ben Goertzel]

I think this would be fun for Amen to work on, however, he has a lot
of stuff to do, so IMO if you could take care of this rapidly it would
be great...

ben

> --
> 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+u...@googlegroups.com.
> To post to this group, send email to ope...@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/5809D187.1040003%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Nil Geisweiller]

Here it is

https://github.com/opencog/atomspace/pull/956

the scheme binding takes both positive and total counts in its
constructor, cause I didn't know how to make it optional, however the
total count is only considered defined if equal or above the positive count.

Amen, needless to say feel free to modify any of this according to your
needs.

Nil

[AmeBel]

 

Amen, needless to say feel free to modify any of this according to your
needs.

Thanks 

[Linas Vepstas]

In my mental model of the world, it would be slightly less awkward if we kept the pair (pos, neg) instead of the pair (pos, total) -- its not much of a difference, but it helps maintain symmetry for as long as possible.  (e.g. in the handling of NotLink's and other situations that could invert or alter the meaning of one or both of these numbers.)

--linas

email to opencog+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@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/5809D187.1040003%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+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@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/580DCF48.4000603%40gmail.com.