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
On 10/22/2016 06:05 AM, Ben Goertzel wrote:
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
On Fri, Oct 21, 2016 at 4:27 PM, 'Nil Geisweiller' via opencog
<[email protected]> wrote:
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
On 10/21/2016 11:23 AM, Nil Geisweiller wrote:
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" <[email protected]
<mailto:[email protected]>> wrote:
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
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
--
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 [email protected].
To post to this group, send email to [email protected].
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 [email protected].
To post to this group, send email to [email protected].
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.
For more options, visit https://groups.google.com/d/optout.
