In the PLN, it is assumed that one can convert confidence values into count
values, and vice versa

Matt Ikle' and I derived some fancy formulas for doing that, published in a
conference paper way back when,

https://www.academia.edu/175929/Assessing_the_Weight_of_Evidence_Implicit_in_an_Indefinite_Probability

(and based on certain assumptions, etc. etc.)

However, in the code we have never used the fancy formulas, but just a
simple heuristic approximation borrowed from Pei Wang's NARS system.

In any case, for PLN, it is definitely valid to convert btw count values
and confidence values...

As Linas notes, there might be other uses of count or confidence, valid for
some OpenCog applications, for which this kind of conversion does not make
sense.   However, this fact should not be used as a basis for restricting
count/confidence conversion for PLN, which is important for PLN's
purposes...

If someone wants to create

ProbabilityAndCountTruthValue // no conversion

ProbabilityAndConfidenceTruthValue // no conversion

ProbabilityAndCountOrConfidenceTruthValue // allowing conversion

I don't mind, though it may be an unnecessary complication....  These might
all be types of SimpleProbabilisticTruthValue, a subtype of
SimpleTruthValue and also of ProbabilisticTruthValue

As Linas points out, it might be smart to distinguish

SimpleProbabilisticTruthValue

vs.

SimpleFuzzyTruthValue

-- the reuse of "strength" for both probability and fuzzy membership
degree, while sometimes convenient, can also sometimes cause confusion as
one has to know something about the Atom type to know whether the strength
is a probability or fuzzy value...

There are lots of ways to slice the truth value types.....  But, in any
case, however they're sliced, PLN's simple truth values must be allowed to
convert freely btw count and confidence and back...

-- Ben



On Wed, Mar 12, 2014 at 4:06 AM, Linas Vepstas <notifications@github.com>wrote:

> In opencog/guile/SchemeSmobTV.cc:
>
> >  	
> >  			SCM rc = SCM_EOL;
> >  			rc = scm_acons(sconf, conf, rc);
> >  			rc = scm_acons(smean, mean, rc);
> > +			rc = scm_acons(scount, count, rc);
>
> For the statistics that I do, I need to have a raw, integer count (or at
> least, usually-an-integer), and a log-probability. To store the raw count,
> I invented the CountTruthValue. It was minimal, and I was taking baby-steps
> at the time.
>
> One of the issues is that the TruthValue::merge() method does this: if
> (other->getConfidence() > getConfidence()) {...} which means that if you
> try to add an atom to the atom space, but its already there with a
> *different* confidence, the confidence (and thus the count) will change
> in an unexpected and perhaps surprising way.
>
> This kind of merging is perhaps correct, *when* that's what you want ..
> and its probably what PLN wants. But, for other things, it can really mess
> things up, esp when the confidence/count is being used to hold something
> else, something unrelated. In particular, its probably wrong for fuzzy
> truth values, and its definitely wrong for probabilities.
>
> I think the solution is to move the merge() method into a
> truth-value-specific method, so that different truth value types do
> different things depending on what they are ... but its not clear what the
> best way is, to do all this.
>
> --
> Reply to this email directly or view it on GitHub<https://github.com/opencog/opencog/pull/590/files#r10493055>
> .
>



-- 
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