PLN revisionFormula issue with count

[cosmoharrigan]

While running PLN, I noticed that the count attribute of some truth values was growing very large.

PLN is using a revisionFormula: https://github.com/opencog/opencog/blob/master/opencog/python/pln/rules/formulas.py#L483

which is called in chainers.py here: https://github.com/opencog/opencog/blob/master/opencog/python/pln/chainers.py#L726

It sets the new count to be the old count plus the new count: https://github.com/opencog/opencog/blob/master/opencog/python/pln/rules/formulas.py#L479 n = x.count+y.count

I think that will cause the count to grow very large.

I suspect this may not be correct.

In the PLN book on page 116, it mentions:

We may also heuristically form a count rule
such as n = n1 + n2 – c min(n1, n2), where the parameter c indicates an 
assumption about the level of interdependency between the bases of 
information corresponding to the two premises. The value c=1 denotes 
the assumption that the two sets of evidence are completely redundant; 
the value c=0 denotes the assumption that the two sets of evidence are 
totally distinct. Intermediate values denote intermediate assumptions.

in this simple case, my guess is that the sets of evidence are closer to being redundant, which would mean the c value was close to 1, causing the new truth value count to approach the max of either n1 or n2, rather than the sum of both of them.

Furthermore, isn't truth value revision currently implemented as the responsibility of the C++ TruthValue::merge class? Shouldn't it be encapsulated once, in one place, whether that's in PLN or in the TruthValue class, rather than doing it two different ways?

@jadeoneill what are your thoughts?

[cosmoharrigan]

cc: @moikle this might interest you as well

[linas]

I propose renaming SimpleTruthValue to PLNTruthValue. This opens the door to putting the various math formulas into PLNTruthValue, which would be faster in C++ than in python, and might make the python code look cleaner?

[edajade]

No, it wouldn't be.

On Wed, Mar 12, 2014 at 9:33 AM, Linas Vepstas notifications@github.comwrote:

I propose renaming SimpleTruthValue to PLNTruthValue. This opens the door to putting the various math formulas into PLNTruthValue, which would be faster in C++ than in python, and might make the python code look cleaner?

Reply to this email directly or view it on GitHubhttps://github.com/opencog/opencog/issues/587#issuecomment-37354823 .

[bgoertzel]

Hmmm...

Regardless of whether SimpleTruthValue is renamed to SimplePLNTruthValue (it shouldn't just be PLNTruthValue, because PLN also will use other kinds of truth values, like IndefiniteTruthValue...), putting the PLN truth value formulas in the TruthValue class seems not a good idea...

Truth value formula execution is not remotely our bottleneck; the bottleneck of PLN is of course Atomspace interaction... and having both the PLN rules and formulas in python seems more convenient than having the rules in python and the formulas in C++ in another part of the code...

ben

On Wed, Mar 12, 2014 at 5:33 PM, jadeoneill notifications@github.comwrote:

No, it wouldn't be.

On Wed, Mar 12, 2014 at 9:33 AM, Linas Vepstas <notifications@github.com

wrote:

I propose renaming SimpleTruthValue to PLNTruthValue. This opens the door to putting the various math formulas into PLNTruthValue, which would be faster in C++ than in python, and might make the python code look cleaner?

Reply to this email directly or view it on GitHub< https://github.com/opencog/opencog/issues/587#issuecomment-37354823>

.

Reply to this email directly or view it on GitHubhttps://github.com/opencog/opencog/issues/587#issuecomment-37389540 .

Ben Goertzel, PhD http://goertzel.org

"In an insane world, the sane man must appear to be insane". -- Capt. James T. Kirk

"Emancipate yourself from mental slavery / None but ourselves can free our minds" -- Robert Nesta Marley

[cosmoharrigan]

@jadeoneill can you comment on my original post?

[edajade]

The revision formula should definitely be in python, like the rest of the formulas and pln code. I think using the fancier formula from the PLN book is a good idea (and it would just be a 1 line change + another arbitrary parameter which is OK)

On Thu, Mar 13, 2014 at 4:42 AM, Cosmo Harrigan notifications@github.comwrote:

@jadeoneill https://github.com/jadeoneill can you comment on my original post?

Reply to this email directly or view it on GitHubhttps://github.com/opencog/opencog/issues/587#issuecomment-37439770 .

[cosmoharrigan]

How shall the redundancy assumption parameter c be calculated?

[edajade]

Just make it up to start with. Ben might come up with some formula (i don't think they have one yet)

On Thu, Mar 13, 2014 at 8:23 AM, Cosmo Harrigan notifications@github.comwrote:

How shall the redundancy assumption parameter c be calculated?

Reply to this email directly or view it on GitHubhttps://github.com/opencog/opencog/issues/587#issuecomment-37467281 .

[linas]

Several issues that are being overlooked:

1) Not all of the formulas can be in the python code. According to the atomspace design, some of the formulas MUST be in the C++ code. This is utterly unavoidable. Cosmo was just asking what to do about this.

The reason this is unavoidable is the following: When the atomspace contains an atom, and some user attempts to place an identical atom into the atomspace, but having a different truth value, one MUST decide what to do. One can do anything: discard the old truth value. Discard the new truth value. Do some fancy mathematical merge of the two. Doesn't mater (to me) what is done, however, something must be done.

2) If there are no objections, I will rename SimpleTruthValue to SimplePLNTruthValue 'real soon now'. The point of this renaming is to make it clear to current and future hackers that this truth value has a very specific semantics. Its not just 'some la-de-dah truth value'

3) Performance: Based on direct measurement, it should be clear to absolutely everyone involved that the fewer round-trips between python and C++, the faster everything will go. You will get direct and immediate performance improvements by minimizing the total number of calls into C++ code. You can minimize the total number of calls by batching up the work. Otherwise, you'll just waste all of your CPU time in the glue code between python and C++.

4) Don't just brush off my suggestions on performance. Based on direct experience, I can confidently say that, in general, people's intuitions about the location of bottlenecks are usually incorrect -- doesn't matter if you're the brilliant system architect or a lowly peon rank-n-file coder. That's just a fact of life, and it holds for all software projects, and OpenCog and PLN are no exception to this rule.

[bgoertzel]

The revision rule seems a special case to me...

I think most PLN formulas should be in python, as PLN is in python and this is thus by far the easiest thing for PLN developers... and calculating PLN formulas, in the course of doing python-based PLN inference, is really not the bottleneck...

However, as Linas points out, the revision formula is not just invoked during PLN reasoning, it should be invoked when someone introduces a new Atom into the Atomspace and it's identical to another Atom. In this case there is a question regarding efficiency. The question is whether the round-trip from C++ to python for doing revision is the time-bottleneck in this case. I don't know the answer to this question. Someone could do some measurements and find out. If it is the bottleneck, then there is an argument for putting the revision rule in C++. I hope not, but: One might then end up with copies of the revision rule in C++ and in python, which is awkward but might be the right compromise between developer convenience and system efficiency.

About renaming. I don't mind if you rename SimpleTruthValue to SimplePLNTruthValue. Someone else may then later bifurcate it into SimpleProbabilisticPLNTruthValue and SimpleFuzzyPLNTruthValue ;-p ...

ben

On Thu, Mar 13, 2014 at 6:51 AM, Linas Vepstas notifications@github.comwrote:

Several issues that are being overlooked:

1) Not all of the formulas can be in the python code. According to the atomspace design, some of the formulas MUST be in the C++ code. This is utterly unavoidable. Cosmo was just asking what to do about this.

The reason this is unavoidable is the following: When the atomspace contains an atom, and some user attempts to place an identical atom into the atomspace, but having a different truth value, one MUST decide what to do. One can do anything: discard the old truth value. Discard the new truth value. Do some fancy mathematical merge of the two. Doesn't mater (to me) what is done, however, something must be done.

2) If there are no objections, I will rename SimpleTruthValue to SimplePLNTruthValue 'real soon now'. The point of this renaming is to make it clear to current and future hackers that this truth value has a very specific semantics. Its not just 'some la-de-dah truth value'

3) Performance: Based on direct measurement, it should be clear to absolutely everyone involved that the fewer round-trips between python and C++, the faster everything will go. You will get direct and immediate performance improvements by minimizing the total number of calls into C++ code. You can minimize the total number of calls by batching up the work. Otherwise, you'll just waste all of your CPU time in the glue code between python and C++.

4) Don't just brush off my suggestions on performance. Based on direct experience, I can confidently say that, in general, people's intuitions about the location of bottlenecks are usually incorrect -- doesn't matter if you're the brilliant system architect or a lowly peon rank-n-file coder. That's just a fact of life, and it holds for all software projects, and OpenCog and PLN are no exception to this rule.

Reply to this email directly or view it on GitHubhttps://github.com/opencog/opencog/issues/587#issuecomment-37479180 .

Ben Goertzel, PhD http://goertzel.org

"In an insane world, the sane man must appear to be insane". -- Capt. James T. Kirk

"Emancipate yourself from mental slavery / None but ourselves can free our minds" -- Robert Nesta Marley

[cosmoharrigan]

There is this note that Linas had added on some wiki pages, such as this one:

CAUTION: in PLN, it is assumed that the truth value of EvaluationLink
and MemberLink is a fuzzy-set-membership value, and NOT a probabilistic 
truth value. Neither the C++ code, nor the python or scheme wrappers 
distinguish these two types of truth values at this time. Combining these 
two different kinds of truth values can and will result in crazy results.

In the PLN book, it talks about truth values representing fuzzy set membership and MemberLinks, and it also talks about truth values representing probabilities. Can you explain further what one needs to watch out for in the context of PLN?

[linas]

Ben,

Help me pick some good names. It's clear that "SimpleTruthValues" are not simple at all, they need a better descriptive name. I think FuzzyTruthValue is probably sufficient, as SimpleFuzzyPLNTruthValue is getting silly. The goal here is to allow the programmer to know what they're dealing with, and to throw an assert when the programmer accidentally uses of combines inappropriate truth values. Lets keep the names simple, short, direct, and meaningful.

[bgoertzel]

A standard FuzzyTruthValue would have only one number, the fuzzy set membership degree

A FuzzyPLNTruthValue is different from that, because it has a confidence/count as well...

The complicated names are meaningful, silly as they may seem..

I.e. PLN really does have notions of: a simple fuzzy truth value [with a (s,c) pair] versus a more complex fuzzy truth value [with e.g. a fuzzy set of probabilistic truth values]

So I think FuzzyPLNTruthValue is an OK name. Simply calling the fuzzy TV with an (s,c) pair a FuzzyTruthValue is not nice to anyone who wants to use OpenCog with fuzzy TVs containing a single number only (the membership degre)

In summary, I think it would be OK to replace SimpleTruthValue with PLNSimpleTruthValue and PLNFuzzyTruthValue

The complexity swept under the rug by this terminology is that PLNSimpleTruthValue actually means SimpleProbabilisticPLNTruthValue. So e.g. later on we will also have PLNIndefiniteTruthValue, which is a more complex kind of probabilistic PLN truth value, and PLNDistributionalTruthValue. But it seems OK to me to use PLNSimpleTruthValue as a shorthand for SimpleProbabilisticPLNTruthValue.

Note that we could also have

ProbabilityTruthValue // just a single probability BinaryTruthValue TernaryTruthValue // for discrete TV logics FuzzyTruthValue // a single fuzzy membership degree

None of these have users at the moment, but the are logically sensible...

For the Zen Buddhists, we can also use

UnaryTruthValue // everything is true! 0aryTruthValue // nothing exists

;-)

SUMMARY: my recommendation is for a list of types like

BinaryTruthValue TernaryTruthValue FuzzyTruthValue ProbabilityTruthValue

PLNSimpleTruthValue PLNFuzzyTruthValue PLNIndefiniteTruthValue ...

and then others as needed...

It happens that the two marked *\ are the ones we're using right now for PLN . But earlier prototype PLN code used PLNIndefiniteTruthValue and there was some support for this in the C++ PLN code...

-- Ben

-- Ben

On Thu, Mar 13, 2014 at 9:50 AM, Linas Vepstas notifications@github.comwrote:

Ben,

Help me pick some good names. It's clear that "SimpleTruthValues" are not simple at all, they need a better descriptive name. I think FuzzyTruthValue is probably sufficient, as SimpleFuzzyPLNTruthValue is getting silly. The goal here is to allow the programmer to know what they're dealing with, and to throw an assert when the programmer accidentally uses of combines inappropriate truth values. Lets keep the names simple, short, direct, and meaningful.

Reply to this email directly or view it on GitHubhttps://github.com/opencog/opencog/issues/587#issuecomment-37491767 .

Ben Goertzel, PhD http://goertzel.org

"In an insane world, the sane man must appear to be insane". -- Capt. James T. Kirk

"Emancipate yourself from mental slavery / None but ourselves can free our minds" -- Robert Nesta Marley

[cosmoharrigan]

PLNSimpleTruthValue PLNFuzzyTruthValue It happens that the two marked *\ are the ones we're using right now for PLN

How is the current PLN implementation distinguishing between those two?

[bgoertzel]

The distinction is made inside the derivation of the truth value formulas themselves. It is not made in the operation of the rules. The TV formulas depend on the link types of the premises, and they know that certain link types are fuzzy and certain are probabilistic

So in the current version the distinction btw PLNSimpleTV and PLNFuzzyTV is not needed for correct operation of the code. However, IMO it would be useful to remind humans not to confuse the two when developing new PLN formulas or other related PLN code...

ben

On Thu, Mar 13, 2014 at 10:20 AM, Cosmo Harrigan notifications@github.comwrote:

PLNSimpleTruthValue PLNFuzzyTruthValue

It happens that the two marked *\ are the ones we're using right now for PLN

How is the current PLN implementation distinguishing between those two?

Reply to this email directly or view it on GitHubhttps://github.com/opencog/opencog/issues/587#issuecomment-37493142 .

Ben Goertzel, PhD http://goertzel.org

"In an insane world, the sane man must appear to be insane". -- Capt. James T. Kirk

"Emancipate yourself from mental slavery / None but ourselves can free our minds" -- Robert Nesta Marley

[cosmoharrigan]

Ok, I see. Sorry for many questions, but: where do you suggest would be a convenient place for me to review the enumeration of which link types should belong to which category?

[bgoertzel]

Hmmm.... That's not systematically written down anywhere though it's implicit in the PLN book's math...

MemberLink and EvaluationLink are the big PLNFuzzyTV guys... I can't think of any others at this moment but I'm in a hurry and might be missing something....

No need to apologize, the questions are good, useful ones ;)

On Thu, Mar 13, 2014 at 10:34 AM, Cosmo Harrigan notifications@github.comwrote:

Ok, I see. Sorry for many questions, but: where do you suggest would be a convenient place for me to review the enumeration of which link types should belong to which category?

Reply to this email directly or view it on GitHubhttps://github.com/opencog/opencog/issues/587#issuecomment-37493786 .

Ben Goertzel, PhD http://goertzel.org

"In an insane world, the sane man must appear to be insane". -- Capt. James T. Kirk

"Emancipate yourself from mental slavery / None but ourselves can free our minds" -- Robert Nesta Marley

[cosmoharrigan]

Ok, thanks, I am stepping out now as well, but I think this enumeration is something to revisit and make explicit.

[linas]

Yes, that's a good question: point is: I'm using EvaluationLink's to store counting information about discovered patterns. So e.g.

EvaluationLink (frequency-counts-and-entropy-truth-value) RelationshipNode "SomeRelation" ListLink BlahAtom BlahBlahAtom

which tells me about how often the Blahatoms have been observed in some relationship type. Ideally, no one should run this through PLN, but good programming hygiene says that such accidents are best avoided by throwing an error when they occur. Thus, having an implicit truth type depending on the atom type is ... maybe acceptable for now, but somewhat dangerous ...

[cosmoharrigan]

This issue still persists: instead of

n = x.count+y.count

it has now been replaced by

n = x.count + y.count – REVISION_REDUNDANCY_FACTOR * min(x.count, y.count)

with

REVISION_REDUNDANCY_FACTOR = 0.5

where 0.5 is an arbitrary number.

The result is that count rapidly grows very large until it approaches its maximum value of 4473923584.

In practice, that rapid increase in count can cause confidence to behave "more like" a boolean rather than a range between 0 and 1, because any non-zero value will rapidly approach 1, which would seem to eliminate most of its usefulness.

How should this revision formula be fixed?

[bgoertzel]

I'll look at this and other PLN issues in 6-7 hours when I'm at the computer next, thx ;)

On Tue, Mar 25, 2014 at 8:29 AM, Cosmo Harrigan notifications@github.comwrote:

This issue still persists: instead of

n = x.count+y.count

it has now been replaced by

n = x.count + y.count - REVISION_REDUNDANCY_FACTOR * min(x.count, y.count)

with

REVISION_REDUNDANCY_FACTOR = 0.5

where 0.5 is an arbitrary number.

The result is that count rapidly grows very large until it approaches its maximum value of 4473923584.

In practice, that rapid increase in count can cause confidence to behave "more like" a boolean rather than a range between 0 and 1, because any non-zero value will rapidly approach 1, which would seem to eliminate most of its usefulness.

How should this revision formula be fixed?

Reply to this email directly or view it on GitHubhttps://github.com/opencog/opencog/issues/587#issuecomment-38518597 .

Ben Goertzel, PhD http://goertzel.org

"In an insane world, the sane man must appear to be insane". -- Capt. James T. Kirk

"Emancipate yourself from mental slavery / None but ourselves can free our minds" -- Robert Nesta Marley

[bgoertzel]

Hmmm...

I'd need to understand the context better, to understand what are the Atoms that are having their truth values revised over and over so many times... Maybe there is some other problem causing an excessive amount of revision, rather than the revision problem being the main issue in what you're doing... (?)

If we want to consider a model in which there we assume N pieces of evidence altogether relative to a given statement (a maximum count way less than infinity), then we could use a heuristic formula like

n = x.count + r( max(x.count, y.count) ) * [ y.count - min(x.count, y.count) ]

where r is a function defined by, say,

r( N) = 0

r(1) = 1 or near 1

and r is monotone

So e.g. we could have

r(x) = ( 1-x/N )^+

I guess a different, nonlinear form for r(x) could be derived from some probability theory assumptions....

The idea is that as

max(x.count, y.count)

gets closer and closer to N, the percentage of redundant evidence among x and y is bound to increase...

-- Ben

On Tue, Mar 25, 2014 at 8:29 AM, Cosmo Harrigan notifications@github.comwrote:

This issue still persists: instead of

n = x.count+y.count

it has now been replaced by

n = x.count + y.count - REVISION_REDUNDANCY_FACTOR * min(x.count, y.count)

with

REVISION_REDUNDANCY_FACTOR = 0.5

where 0.5 is an arbitrary number.

The result is that count rapidly grows very large until it approaches its maximum value of 4473923584.

In practice, that rapid increase in count can cause confidence to behave "more like" a boolean rather than a range between 0 and 1, because any non-zero value will rapidly approach 1, which would seem to eliminate most of its usefulness.

How should this revision formula be fixed?

Reply to this email directly or view it on GitHubhttps://github.com/opencog/opencog/issues/587#issuecomment-38518597 .

Ben Goertzel, PhD http://goertzel.org

"In an insane world, the sane man must appear to be insane". -- Capt. James T. Kirk

"Emancipate yourself from mental slavery / None but ourselves can free our minds" -- Robert Nesta Marley

[linas]

Closing; this appears to be based on the now-obsolete python-PLN codebase