[opencog-dev] Re: Outline for OpenCog tutorial

[Ben Goertzel]

Gaurav -- That would be great!

Amen Belayneh (cc'd) can point you to the best page to start from,
regarding building and installing the system...

On Wed, Jun 22, 2016 at 2:24 AM, Gaurav Gautam  wrote:
> Hello,
>
> I just found out about opencog today and I am downloading everything to
> build it. I see that the page link provided here is still blank in the
> building OpenCog section. I was wondering if I could fill it out for you?
>
> Yours sincerely
> Gaurav Gautam
>
>
> On Saturday, August 29, 2015 at 12:36:34 PM UTC+5:30, Ben Goertzel wrote:
>>
>> I spent a couple hours thinking about what an OpenCog tutorial would
>> look like, and made an initial outline here
>>
>> http://wiki.opencog.org/wikihome/index.php/Hands_On_With_OpenCog
>>
>> linking to existing materials where relevant...
>>
>> My hope is to have this tutorial actually fully exist by early next
>> year, say by Feb 15 as a concrete goal (and Jan 1 as an aspirational,
>> hopeful goal)
>>
>> This takes lower priority than ridding the wiki site of obsolete
>> information (except on pages in the Obsolete and Deprecated)
>> categories; but in some cases I think tutorial material could be made
>> by people who don't have the knowledge yet to clean the wiki pages of
>> obsolete information...
>>
>> At some point in the next months I will recruit/assign specific people
>> to make specific tutorial pages.   For now, if anyone has time and
>> will to fill in some of the pages in the outline that would be
>> awesome.
>>
>> Having a decent, clear and comprehensive tutorial will be important
>> for recruiting newbies to contribute.
>>
>> Of course, having a stable release of OpenCog will also be important
>> --- this will help guarantee that the examples in the tutorial will
>> always work, if the tutorial user has installed the last stable
>> release
>>
>> -- Ben
>>
>>
>>
>> --
>> Ben Goertzel, PhD
>> http://goertzel.org
>>
>> "The reasonable man adapts himself to the world: the unreasonable one
>> persists in trying to adapt the world to himself. Therefore all
>> progress depends on the unreasonable man." -- George Bernard Shaw



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdiK30O-wZefOUmLHpWGXY0D%2B2Vsyb-JLSwj0UN7WWYPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Is the lisp shell preferred over python shell?

[Ben Goertzel]

I would advise to use the Scheme shell, it is much more used and
better maintained

Python also basically works, but you're more likely to hit bugs there,
and there are no active users for the python shell right now

The python interface to OpenCog is heavily used in different ways
though -- python is the gateway via which openCog communicates with
external resources like ROS (for messaging to sensors and actuators)
or Theano (for neural net training/evaluation), etc.

-- Ben

On Wed, Jun 22, 2016 at 12:02 PM, Gaurav Gautam  wrote:
> Hello,
>
> I built opencog last night and have been watching Ben's videos on youtube. I
> am watching the AGI 13 videos now.
>
> I want to get my feet wet with AGI and opencog but I don't have a specific
> aim or motivation aside from an
> interest and fascination with opencog's vision. That, and I really really
> want to see and talk to an ASI in my lifetime.
>
> It seems to me that the lisp shell is preferred over the python shell by
> looking at the docs. So should I
> use the lisp shell? Please give me any other advise you have regarding
> getting started with AGI and opencog.
>
> Yours sincerely
> Gaurav Gautam
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/166b64d2-92ac-4843-8483-5d4bd4194855%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBeKdZCcyO2Qn0P%2B2_%2BX-wD-TRHeaT%3DMmjB6FxYPb2aYYg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Re: Linas' to-do list

[Ben Goertzel]

Hi Linas,

I think the following is the focus that makes most sense for you
during the next couple months (and perhaps beyond that, as you say
it's a large problem...)

> -- Integrate the self-awareness code into the the new, revised chatbot. This
> is an open-ended project, much larger than the two above, as things are
> currently in a rather poor state. However, it also seems to be much more
> important in the medium/long run.  Rworking the rule-selection-narrowing
> (frame) problem for openpsi would be a subtask of this task -- I already
> knew I needed to do this, before arriving in HK.

Optimizing SuReal is something Senna or someone else could do; whereas
the above requires a more holistic understanding and thus better
leverages your deeper understanding of the whole OpenCog
framework/approach ...

If we do get more OpenCog-AGI-focused $$, that would enable me to fund
you to focus mainly or wholly on unsupervised language learning
But even if this does happen over the summer, it will be best if you
can get the self-awareness code working together gracefully and
extensibly with OpenPsi and the new chatbot, before shifting focus
away from the Hanson stuff ...

BTW Man Hin is in the midst of "integrating" the chatbot-eva stuff
with the Openpsi based chatbot in a very crude way for short term
purposes only --- basically he is treating it as a separate "engine",
accessed by a single Psi rule, and used for processing certain
imperatives  But this is obviously a crude hack for short-term
demo purposes only ... not a real integration ... he and I decided
it's best to leave the real integration to you..

ben


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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdrhVRXzX06UhT%3DMMR3PNKtxcQPV2e1sCoob-Mq_cfC9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Running the pattern miner

[Ben Goertzel]

True... though I wonder what incompatibilities that branch has, as
compared to master...

On Wed, Jun 29, 2016 at 3:39 PM, AmeBel  wrote:
> Hi,
>
> FYI, the in-development patterminer can be found on the
> PatternMinerEmbodiment branch @ opencog/opencog/ repo.
>
> On Wednesday, June 29, 2016 at 3:16:13 PM UTC+8, Nil wrote:
>>
>> Well, I haven't moved past this issue, I think this other error is just
>> a different manifestation of the same problem...
>>
>> Nil
>>
>> On 06/29/2016 10:00 AM, Nil Geisweiller wrote:
>> > Actually, I've moved past that issue (I didn't use the right conf), but
>> > I've got another, perhaps more worrisome
>> >
>> > [2016-06-29 06:58:08:109] [INFO] Loading module
>> >
>> > "/home/nilg/OpenCog/opencog/build/opencog/learning/PatternMiner/libTestPatternMinerAgent.so"
>> >
>> > [2016-06-29 06:58:08:109] [ERROR] Caught signal 11 (Segmentation fault)
>> > on thread 140204635740224
>> >  Stack Trace:
>> >
>> > I guess I'll have to fire up gdb. Meanwhile, any feedback is
>> > appreciated.
>> >
>> > Nil
>> >
>> > On 06/29/2016 09:55 AM, Nil Geisweiller wrote:
>> >> Hi,
>> >>
>> >> I'm trying to use the pattern miner. I'm posting here first before
>> >> creating a github issue in case it is a silly problem.
>> >>
>> >> I'm loading the test in the cogserver
>> >>
>> >> opencog> loadmodule
>> >>
>> >> /home/nilg/OpenCog/opencog/build/opencog/learning/PatternMiner/libTestPatternMinerAgent.so
>> >>
>> >>
>> >>
>> >> and getting
>> >>
>> >> [2016-06-29 05:43:14:123] [WARN] Unable to load module
>> >>
>> >> "/home/nilg/OpenCog/opencog/build/opencog/learning/PatternMiner/libTestPatternMinerAgent.so":
>> >>
>> >>
>> >> /home/nilg/OpenCog/opencog/build/opencog/learning/PatternMiner/libPatternMiner.so:
>> >>
>> >> undefined symbol: _ZN7opencog11OBJECT_NODEE
>> >>
>> >> Any idea?
>> >>
>> >> Nil
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/387b5bac-3b76-49c0-b650-40d6f8396ea2%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdzuV7%2BDg0QWvdYxMQSQ%2BxVSVP-5sh%2BSr_rFDnf7%3Dfn7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Running the pattern miner

[Ben Goertzel]

Nil, among other factors, she is using a lot of the old Embodiment
code that you deleted from the master branch...

However, the Pattern Matcher itself should not rely on any of this old
Embodiment code, so I think she could likely merge her improved PM
into master...

What she is doing (among other things) is using the PM to recognize
patterns in the Atomspace resulting from a game character's
perceptions and actions, where the game character is running around in
the old Unity3D game world, controlled by the old Embodiment

There is no conceptual reason not to just port all this to Minecraft,
but Shujing hasn't had time to do that, as she's been doing this work
in a hurry as it's part of what she needs to do to finish her PhD
thesis...

At least the above is my understanding; Shujing can correct me if I'm wrong!




On Wed, Jun 29, 2016 at 3:52 PM, 'Nil Geisweiller' via opencog
 wrote:
> Apparently this branch was started a year ago.
>
> Shujing, what prevents you from merging it into the master?
>
> Nil
>
>
> On 06/29/2016 10:45 AM, Ben Goertzel wrote:
>>
>> True... though I wonder what incompatibilities that branch has, as
>> compared to master...
>>
>> On Wed, Jun 29, 2016 at 3:39 PM, AmeBel  wrote:
>>>
>>> Hi,
>>>
>>> FYI, the in-development patterminer can be found on the
>>> PatternMinerEmbodiment branch @ opencog/opencog/ repo.
>>>
>>> On Wednesday, June 29, 2016 at 3:16:13 PM UTC+8, Nil wrote:
>>>>
>>>>
>>>> Well, I haven't moved past this issue, I think this other error is just
>>>> a different manifestation of the same problem...
>>>>
>>>> Nil
>>>>
>>>> On 06/29/2016 10:00 AM, Nil Geisweiller wrote:
>>>>>
>>>>> Actually, I've moved past that issue (I didn't use the right conf), but
>>>>> I've got another, perhaps more worrisome
>>>>>
>>>>> [2016-06-29 06:58:08:109] [INFO] Loading module
>>>>>
>>>>>
>>>>> "/home/nilg/OpenCog/opencog/build/opencog/learning/PatternMiner/libTestPatternMinerAgent.so"
>>>>>
>>>>> [2016-06-29 06:58:08:109] [ERROR] Caught signal 11 (Segmentation fault)
>>>>> on thread 140204635740224
>>>>>   Stack Trace:
>>>>>
>>>>> I guess I'll have to fire up gdb. Meanwhile, any feedback is
>>>>> appreciated.
>>>>>
>>>>> Nil
>>>>>
>>>>> On 06/29/2016 09:55 AM, Nil Geisweiller wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to use the pattern miner. I'm posting here first before
>>>>>> creating a github issue in case it is a silly problem.
>>>>>>
>>>>>> I'm loading the test in the cogserver
>>>>>>
>>>>>> opencog> loadmodule
>>>>>>
>>>>>>
>>>>>> /home/nilg/OpenCog/opencog/build/opencog/learning/PatternMiner/libTestPatternMinerAgent.so
>>>>>>
>>>>>>
>>>>>>
>>>>>> and getting
>>>>>>
>>>>>> [2016-06-29 05:43:14:123] [WARN] Unable to load module
>>>>>>
>>>>>>
>>>>>> "/home/nilg/OpenCog/opencog/build/opencog/learning/PatternMiner/libTestPatternMinerAgent.so":
>>>>>>
>>>>>>
>>>>>>
>>>>>> /home/nilg/OpenCog/opencog/build/opencog/learning/PatternMiner/libPatternMiner.so:
>>>>>>
>>>>>> undefined symbol: _ZN7opencog11OBJECT_NODEE
>>>>>>
>>>>>> Any idea?
>>>>>>
>>>>>> Nil
>>>
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To post to this group, send email to opencog@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/387b5bac-3b76-49c0-b650-40d6f8396ea2%40googlegroups.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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/57737E38.4010904%40gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBecgKgVecVofiAjKObS%2By-WwVP%2B9s%2BrZiAFndcSgYyhvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Re: [opencog/opencog] Generate speech from r2l structure (#2238)

[Ben Goertzel]

Nil,

I talked to Man Hin and Amen about this a bit...

What they said is roughly as follows.

Suppose that you feed in the sentence "Pigs are very cute" into the
Atomspace, retaining all the outputs of nlp-parse

Next, suppose that you feed in the sentences "Dogs are slightly ugly" and
"Fred is a dog"  retaining all the outputs of nlp-parse

Suppose that PLN draws the conclusion corresponding to "Fred is slightly
ugly" (expressed in Atomese, not in English... i.e. PLN derives the R2L
output corresponding to "Fred is slightly ugly" (let's call this C) ) ...

Then I believe that, if you feed C to the microplanner, it should invoke
sureal in a way that leads to the sentence "Fred is slightly ugly" getting
produced...

ON THE OTHER HAND ... if when you feed in "Dogs are slightly ugly" and
"Fred is a dog" you do NOT retain all the outputs of nlp-parse in the
Atomspace, but only retain the output of R2L on these input sentences --
THEN I think the microplanner/sureal will not succeed at surface-realizing
from C ...

The point is that sureal needs the links between e.g. the ConceptNode for
"dog" and the WordNode for "dog" (which then has links to the link-parser
dictionary entry for "dog" ...)   These Atoms are produced when parsing
a sentence involving "dog" such as "Dogs are slightly ugly" or "Fred is a
dog" ...

Later on we will improve the microplanner to do word selection as a
separate process ... so that if the ConceptNode that PLN comes up with is
not already linked to some WordNode with a link grammar dictionary entry,
then the word-selection process will find a set of Atoms that represent
that ConceptNode to a reasonable approximation...

-- Ben




On Mon, Jul 4, 2016 at 3:49 PM, ngeiswei  wrote:

> Sorry to slam you with messages. I'm reporting my progress in case someone
> comes by and happens to be able to help.
>
> According to opencog/nlp/sureal/surface-realization.scmIf the SetLink
> contains an interpretation it will just output the corresponding existing
> sentence. Otherwise it will call create-sentence which ultimately calls
> sureal-match which call C++ function do_sureal_match.
>
> The question then is, what are the requirements of do_sureal_matchin
> order to generate a sentence. Looking at the sureal unit tests I need no
> test using instances"likes@..."instead of"likes"`, so maybe that's why it
> doesn't work. I guess I could generate structure without instances. Yet the
> fuzzy pattern matcher will try to select as answers the syntactically most
> similar structures to the query, and so I don't see how my inferred
> structure could be handed to sureal then. Anyway, more to investigate...
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/opencog/opencog/issues/2238#issuecomment-230227008>,
> or mute the thread
> <https://github.com/notifications/unsubscribe/AFolXFUY1_FVucKLwaxgCEZTwnT89Tf-ks5qSLsNgaJpZM4JEC7x>
> .
>



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBcsEkKo1z52DkF_sQ-CkRLAS6OHxZwjakgwkoPVJoKSKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] visualizer progress

[Ben Goertzel]

Some examples of the current OpenCog visualizer from Hedra in Addis  …

http://goertzel.org/visualizer_examples.mkv

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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBeGknLk5s0OHH1-bG2oG9bFSSgqjN4B60omywtzNq0%2BHA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Outline for OpenCog tutorial

[Ben Goertzel]

Sure, please do expand the tutorial page!  it is supposed to be filled
out, we just haven't gotten around to it...


On Fri, Jul 8, 2016 at 3:55 PM, Gaurav Gautam  wrote:
> Hello,
>
> I have now installed opencog several times. And I have made some progress in
> understanding atomspace
> and interacting with it using the scheme shell, with some invaluable help
> from Linas. I was wondering if I
> can add some things to the Lesson2 on the wiki:
>
> http://wiki.opencog.org/wikihome/index.php/Hands_On_With_OpenCog#Lesson_2:_Getting_started_with_Atoms_and_the_Scheme_shell_.28Amen.29
>
> I won't remove anything that is there. But I was thinking I could put the
> following subheadings and some content there:
> 1. Atomspace and atoms (What is a hypergraph. And that atomspace implements
> a hypergraph. How it can be queried and changed using scheme.)
> 2. Atoms: Links and Nodes (A summary of link and node types. How some of the
> links like EvaluationLink, BindLink, PlusLink etc.
>  can be used with cog-bind and
> cog-execute).
> 3. Interacting using c++: I haven't been successful at this myself yet. But
> I will add a subsection when I am done.
>
> Would this be alright or do you want to keep it just as a set of links to
> other pages? All the headings on the hands on
> wiki are meant to be expanded right?
>
> Yours sincerely
> Gaurav Gautam
>
> On Monday, June 27, 2016 at 11:40:06 AM UTC+5:30, AmeBel wrote:
>>
>> update your atomspace installation
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/7554dc70-c8b0-489e-98be-36645eb2280c%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdsrFioBAxO5pcYVZLiJmC-2YTg09KrJWZJmdBfO7hTwg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Replacing Relex2Logic with Relex2Lojban

[Ben Goertzel]

Here is a modest proposal, which would replace Relex2Logic with
something vaguely similar in spirit but much superior,

http://wiki.opencog.org/wikihome/index.php/Lojbanic_Relex2Logic

Actually it's a bit closer to the spirit of the bad old RelEx2Frame,
but with the significant difference that Lojban is a language with
complete coverage of everyday semantics, whereas FrameNet is sorely
limited and hasn't been honed by usage...

-- Ben


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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBd14p2N2stQqNf5e6kgjX31s24-s7UCsp-qhLzcqGFcuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Replacing Relex2Logic with Relex2Lojban

[Ben Goertzel]

Hi Jim,

I totally agree that, in principle, Lojban could have a huge number of
applications involving human-machine interaction ... and human-human
interaction   If biology and philosophy papers were written in
Lojban, knowledge would advance faster...

However I don't currently see a viable route to getting Lojban used by
a significant group of humans   Maybe once we have advanced AGIs,
if some geeky people want to communicate with the AGIs in something
more closely resembling their native language, they will learn a
future version of Lojban to do so?  ;0

On the other hand, as an internal tool within significantly
logic-focused AI systems, I can increasingly see a quite practical
near-term usage  Potentially this usage will -- in some way we
can't exactly foresee right now -- lead to human adoption in some
subcommunity as well... but if it just helps us get to AGI a bit
faster and better, that's good enough ;) ...

-- Ben

-- Ben






On Fri, Jul 8, 2016 at 10:12 PM, Jim Rutt  wrote:
> I like this idea very much.  I'm currently considering Lojban as a
> "knowledge engineering" language for a "really smart AI for games" project
> I'm starting to spin up.  Prior to full on AGI I see some fruitful problems
> to be solved using "sort of AGIish" software that depends on human created
> domain specific declarative knowledge.  My hypothesis is that there is a
> useful and talented - and not too expensive - class of human talent that can
> learn Lojban well who would not be appropriate for using tools that are less
> human language-like.  These might include very bright but highly
> anti-quantitative liberal arts grads.  Lojban strikes me as a potentially
> quite good adapter between the world of humans and the world of machines.
>
> ko pilno lo clearer pensi la lojban
>
> jim
>
>
> On Fri, Jul 8, 2016 at 7:44 AM, Ben Goertzel  wrote:
>>
>> Here is a modest proposal, which would replace Relex2Logic with
>> something vaguely similar in spirit but much superior,
>>
>> http://wiki.opencog.org/wikihome/index.php/Lojbanic_Relex2Logic
>>
>> Actually it's a bit closer to the spirit of the bad old RelEx2Frame,
>> but with the significant difference that Lojban is a language with
>> complete coverage of everyday semantics, whereas FrameNet is sorely
>> limited and hasn't been honed by usage...
>>
>> -- Ben
>>
>>
>> --
>> Ben Goertzel, PhD
>> http://goertzel.org
>>
>> Super-benevolent super-intelligence is the thought the Global Brain is
>> currently struggling to form...
>
>
>
>
> --
> ===
> Jim Rutt
> JPR Ventures
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/CAPzPGw7p7MKC2d0MucQf8s4AimtSu-rNtkmm8Pprf03iJhJVdA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBc%2BbW-oXnYtqiYHg_6ZQeVawJghDKhL-jZ6%3DPCmmYyFAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Replacing Relex2Logic with Relex2Lojban

[Ben Goertzel]

 matter, it's the precisely-stated
logical relationships between the Lojban words...

-- Ben










On Sat, Jul 9, 2016 at 12:09 PM, Matt Chapman  wrote:
> How does storing ConceptNode atoms with lojbanic labels improve over storing
> atoms with English labels? For practical applications, it seems like it
> would unnecessarily increase the size of the atomspace, and for training
> data, I expect there are vastly many more English to $X translation examples
> than Lojban to $X. Lojban is a fun toy, but like Linas, I don't see the
> problem that is being solved here. Sure Lojban has fewer rules to encode,
> but you still end up manually encoding them, as far as I  can tell. Maybe it
> feel less like cheating because writing lojban feels like writing code to
> begin with...
>
> All the Best,
>
> Matt
>
> --
> Standard Disclaimer:
> Please interpret brevity as me valuing your time, and not as any negative
> intention.
>
> On Fri, Jul 8, 2016 at 5:03 PM, Linas Vepstas 
> wrote:
>>
>> FWIW, I am virulently anti-lojban, because mostly I believe it doesn't
>> solve any problems that we actually have. --linas
>>
>> On Fri, Jul 8, 2016 at 9:12 AM, Jim Rutt  wrote:
>>>
>>> I like this idea very much.  I'm currently considering Lojban as a
>>> "knowledge engineering" language for a "really smart AI for games" project
>>> I'm starting to spin up.  Prior to full on AGI I see some fruitful problems
>>> to be solved using "sort of AGIish" software that depends on human created
>>> domain specific declarative knowledge.  My hypothesis is that there is a
>>> useful and talented - and not too expensive - class of human talent that can
>>> learn Lojban well who would not be appropriate for using tools that are less
>>> human language-like.  These might include very bright but highly
>>> anti-quantitative liberal arts grads.  Lojban strikes me as a potentially
>>> quite good adapter between the world of humans and the world of machines.
>>>
>>> ko pilno lo clearer pensi la lojban
>>>
>>> jim
>>>
>>>
>>> On Fri, Jul 8, 2016 at 7:44 AM, Ben Goertzel  wrote:
>>>>
>>>> Here is a modest proposal, which would replace Relex2Logic with
>>>> something vaguely similar in spirit but much superior,
>>>>
>>>> http://wiki.opencog.org/wikihome/index.php/Lojbanic_Relex2Logic
>>>>
>>>> Actually it's a bit closer to the spirit of the bad old RelEx2Frame,
>>>> but with the significant difference that Lojban is a language with
>>>> complete coverage of everyday semantics, whereas FrameNet is sorely
>>>> limited and hasn't been honed by usage...
>>>>
>>>> -- Ben
>>>>
>>>>
>>>> --
>>>> Ben Goertzel, PhD
>>>> http://goertzel.org
>>>>
>>>> Super-benevolent super-intelligence is the thought the Global Brain is
>>>> currently struggling to form...
>>>
>>>
>>>
>>>
>>> --
>>> ===
>>> Jim Rutt
>>> JPR Ventures
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To post to this group, send email to opencog@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/CAPzPGw7p7MKC2d0MucQf8s4AimtSu-rNtkmm8Pprf03iJhJVdA%40mail.gmail.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+unsubscr...@googlegroups.com.
>> To post to this group, send email to opencog@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/CAHrUA35G-ooD2i_RMi93YN2T%2Bmo44coYytAkTj_0RsH9KOdzvg%40mail.gmail.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBecpd2xSZ%2BMBOvEz1zBJ2WS87DfNv%3DdMyPsrYUYfyH0rA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Replacing Relex2Logic with Relex2Lojban

[Ben Goertzel]

I think it could help a lot in solving one problem you currently have:
Mapping multiple roughly-synonymous ways of saying the same thing,
into the same logical relationship-set (you've referred to this as
phrase-level "synonymy" before).   The way it helps is by constituting
a viable "logical normal form" for everyday commonsense statements...

I think it can also help, down the road, in terms of enabling
automatic (no hand coded rules) building of mapping rules between
syntactico-semantic rules learned by unssupervised learning, and
logical relationships that are tractable for PLN to reason on...

-- Ben






On Sat, Jul 9, 2016 at 8:03 AM, Linas Vepstas  wrote:
> FWIW, I am virulently anti-lojban, because mostly I believe it doesn't solve
> any problems that we actually have. --linas
>
> On Fri, Jul 8, 2016 at 9:12 AM, Jim Rutt  wrote:
>>
>> I like this idea very much.  I'm currently considering Lojban as a
>> "knowledge engineering" language for a "really smart AI for games" project
>> I'm starting to spin up.  Prior to full on AGI I see some fruitful problems
>> to be solved using "sort of AGIish" software that depends on human created
>> domain specific declarative knowledge.  My hypothesis is that there is a
>> useful and talented - and not too expensive - class of human talent that can
>> learn Lojban well who would not be appropriate for using tools that are less
>> human language-like.  These might include very bright but highly
>> anti-quantitative liberal arts grads.  Lojban strikes me as a potentially
>> quite good adapter between the world of humans and the world of machines.
>>
>> ko pilno lo clearer pensi la lojban
>>
>> jim
>>
>>
>> On Fri, Jul 8, 2016 at 7:44 AM, Ben Goertzel  wrote:
>>>
>>> Here is a modest proposal, which would replace Relex2Logic with
>>> something vaguely similar in spirit but much superior,
>>>
>>> http://wiki.opencog.org/wikihome/index.php/Lojbanic_Relex2Logic
>>>
>>> Actually it's a bit closer to the spirit of the bad old RelEx2Frame,
>>> but with the significant difference that Lojban is a language with
>>> complete coverage of everyday semantics, whereas FrameNet is sorely
>>> limited and hasn't been honed by usage...
>>>
>>> -- Ben
>>>
>>>
>>> --
>>> Ben Goertzel, PhD
>>> http://goertzel.org
>>>
>>> Super-benevolent super-intelligence is the thought the Global Brain is
>>> currently struggling to form...
>>
>>
>>
>>
>> --
>> ===
>> Jim Rutt
>> JPR Ventures
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To post to this group, send email to opencog@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/CAPzPGw7p7MKC2d0MucQf8s4AimtSu-rNtkmm8Pprf03iJhJVdA%40mail.gmail.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBf5ytVRB0rLO6VPL95duz89KtWLKcESiNhwencJY5DKdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Replacing Relex2Logic with Relex2Lojban

[Ben Goertzel]

For those who are interested, some further potential particulars are here...

http://wiki.opencog.org/wikihome/index.php/Lojbanic_Relex2Logic#Some_Particulars

On Sat, Jul 9, 2016 at 1:25 PM, Ben Goertzel  wrote:
> I think it could help a lot in solving one problem you currently have:
> Mapping multiple roughly-synonymous ways of saying the same thing,
> into the same logical relationship-set (you've referred to this as
> phrase-level "synonymy" before).   The way it helps is by constituting
> a viable "logical normal form" for everyday commonsense statements...
>
> I think it can also help, down the road, in terms of enabling
> automatic (no hand coded rules) building of mapping rules between
> syntactico-semantic rules learned by unssupervised learning, and
> logical relationships that are tractable for PLN to reason on...
>
> -- Ben
>
>
>
>
>
>
> On Sat, Jul 9, 2016 at 8:03 AM, Linas Vepstas  wrote:
>> FWIW, I am virulently anti-lojban, because mostly I believe it doesn't solve
>> any problems that we actually have. --linas
>>
>> On Fri, Jul 8, 2016 at 9:12 AM, Jim Rutt  wrote:
>>>
>>> I like this idea very much.  I'm currently considering Lojban as a
>>> "knowledge engineering" language for a "really smart AI for games" project
>>> I'm starting to spin up.  Prior to full on AGI I see some fruitful problems
>>> to be solved using "sort of AGIish" software that depends on human created
>>> domain specific declarative knowledge.  My hypothesis is that there is a
>>> useful and talented - and not too expensive - class of human talent that can
>>> learn Lojban well who would not be appropriate for using tools that are less
>>> human language-like.  These might include very bright but highly
>>> anti-quantitative liberal arts grads.  Lojban strikes me as a potentially
>>> quite good adapter between the world of humans and the world of machines.
>>>
>>> ko pilno lo clearer pensi la lojban
>>>
>>> jim
>>>
>>>
>>> On Fri, Jul 8, 2016 at 7:44 AM, Ben Goertzel  wrote:
>>>>
>>>> Here is a modest proposal, which would replace Relex2Logic with
>>>> something vaguely similar in spirit but much superior,
>>>>
>>>> http://wiki.opencog.org/wikihome/index.php/Lojbanic_Relex2Logic
>>>>
>>>> Actually it's a bit closer to the spirit of the bad old RelEx2Frame,
>>>> but with the significant difference that Lojban is a language with
>>>> complete coverage of everyday semantics, whereas FrameNet is sorely
>>>> limited and hasn't been honed by usage...
>>>>
>>>> -- Ben
>>>>
>>>>
>>>> --
>>>> Ben Goertzel, PhD
>>>> http://goertzel.org
>>>>
>>>> Super-benevolent super-intelligence is the thought the Global Brain is
>>>> currently struggling to form...
>>>
>>>
>>>
>>>
>>> --
>>> ===
>>> Jim Rutt
>>> JPR Ventures
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To post to this group, send email to opencog@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/CAPzPGw7p7MKC2d0MucQf8s4AimtSu-rNtkmm8Pprf03iJhJVdA%40mail.gmail.com.
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>
>
>
> --
> Ben Goertzel, PhD
> http://goertzel.org
>
> Super-benevolent super-intelligence is the thought the Global Brain is
> currently struggling to form...



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBcPyEVEuOw-TesyV_aWqAr-1Dz60YOhUK1ra7Wdsajbsg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: brainstorming new names for OpenCogPrime

[Ben Goertzel]

SANTA = Self-organizing Adaptive NeTwork Algorithm ... yeah, sure, why not? ;D

On Thu, Jul 14, 2016 at 4:04 AM, Andi  wrote:
> Ben,
> since it is your design:
>
> "-- CogPrime for my own specific AGI design, based on cognitive synergy
> between PLN, MOSES, ECAN and so forth"
>
> It should be named as what it is and at what you want it to be:
>
> BensSanta
>
> And it will be praised and talked about for thousands of years,
> by people sitting around their fires, telling tales about how it began..
>
> Belive me: everybody in the scene will remenber this name and what it means
> and who made the design and with what tools it was made - the opencog
> toolset.
>
> In this way the first gift from BensSanta will be that more people know
> about and remember opencog...
>
> Andi
>
>
>
>
>
>
> Am Sonntag, 31. Januar 2016 08:18:46 UTC+1 schrieb Ben Goertzel:
>>
>> Hi all,
>>
>> So, I could use y'all's help in some name-brainstorming...
>>
>> Way back in the days of yore, before self-driving cars and deep
>> learning were all the rage and Silicon Valley overlords talked about
>> billions for open-source AI, before national leaders and
>> mega-corporations thought AGI was a meaningful pursuit, back when we
>> were running around in loincloths and trying to program AGI using
>> abacuses carved from mammoth bones ... way back then, in the chaotic
>> mess of my livingroom in Rockville MD, I crafted the following
>> fiendishly clever naming scheme:
>>
>> -- OpenCog for the general framework, e.g. Atomspace, MindAgents,
>> etc., that I wanted to create via open-sourcing the key bits of
>> Novamente Cognition Engine ... as a toolkit that many people could use
>> to experiment with their various proto-AGI approaches...
>>
>> -- CogPrime for my own specific AGI design, based on cognitive synergy
>> between PLN, MOSES, ECAN and so forth
>>
>> -- OpenCogPrime for the implementation of CogPrime within OpenCog
>> (since CogPrime as an abstract AGI design could be implemented in
>> other non-OpenCog frameworks as well...)
>>
>> ...
>>
>> In hindsight, this "clever" naming scheme was not one of my better
>> inventions and it generally causes more confusion than anything
>> else   What has happened is that "CogPrime" is never used and
>> "OpenCog" is used to mean both the framework and the AGI design and
>> various superpositions and blends between those two things...
>>
>> So a few of us have decided it would be a Good Thing to have a new and
>> distinct name for "CogPrime", so as to clearly distinguish it from the
>> underlying OpenCog framework...
>>
>> The door is open for any name anyone can come with, so if you have any
>> suggestions please post to the list   Of course, if nobody comes
>> up with anything more appealing we can always stick with mediocre old
>> "CogPrime" ...
>>
>> I am indeed aware of the weakness of the whole concept of
>> "branded/named AI architecture" ... after all, each branded
>> architecture  mixes up concepts from all over the place, and the
>> underlying algorithms and structures are often more important than the
>> specific branded combination.  Yet we live in a world dominated by
>> humans still, and given the peculiarities of human psychology, having
>> zingy names and brands to associate with things is helpful for
>> communication, fundraising, and other human-society necessities
>> so it goes...
>>
>> thanks!
>> ben
>>
>>
>>
>>
>>
>> --
>> Ben Goertzel, PhD
>> http://goertzel.org
>>
>> "The reasonable man adapts himself to the world: the unreasonable one
>> persists in trying to adapt the world to himself. Therefore all
>> progress depends on the unreasonable man." -- George Bernard Shaw
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/a9924088-7122-4572-9b17-5441668a1653%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBcv%2BSH-AYD7a3kfcfaWgXjDJ45jU-AVm8TAsCUjHUrnyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Getting rid of UUIDs in the Haskell LIb

[Ben Goertzel]

LInas will have thoughts but he's flying home to Austin from NYC
tonight so he may only share them US tomorrow...

On Thu, Jul 21, 2016 at 5:32 PM, Roman Treutlein  wrote:
> Hello,
>
> I was just trying to get the Haskell Lib to use Handle/AtomPtr instead of
> UUIDs. Unfortunately, I was unsuccessful thus far. The issue being that I
> can't use Handle/AtomPtr directly as they are Objects which aren't directly
> supported by the C-Interface.
>
> I could use a Pointer to the Atom but that is unsafe on multiple levels.
>
> Looking at the Scheme code it also seems to use UUIDs but I am not quite
> sure to what extend.
>
> Anyway, I just wanted to know if somebody had some thoughts about this.
>
> regards
> /Roman
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/d80fa1af-b3cf-47b4-908a-8c42061519db%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBeJFvUjWw8OgkmpxFb%3DcuUeysQzTfwWsitXctmtiLPByA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Getting rid of UUIDs in the Haskell LIb

[Ben Goertzel]

But it's not clear that an Atom created on one local machine, then
processed a bit, then discarded, ever needs to get assigned a UUID.
They could get assigned only when saving to a backing store or sending
across a network, right?

-- ben

On Fri, Jul 22, 2016 at 6:16 PM, Matt Chapman  wrote:
>
> On Fri, Jul 22, 2016 at 2:55 PM, Linas Vepstas 
> wrote:
>>
>> My long-term goal is to create such a "private table" in the database
>> backends, and remove UUID's in general.
>
>
> Aren't UUID's (or something equivalent) necessary for a distributed
> atomspace? I suspect you don't want to have to worry about synchronizing
> this int table across machines...
>
> All the Best,
>
> Matt
>
> --
> Standard Disclaimer:
> Please interpret brevity as me valuing your time, and not as any negative
> intention.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/CAPE4pjBYmMTnSg_GjbdGVf2E94ytenar%3DFEDa5b66gDKzTLfUA%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBf_E%3Dp%3DJUCO%2B-RDa26vzbqX3vrm4J1am%2BB6zyN6WeD_4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Re: An unsupervised learning with pattern mining demo

[Ben Goertzel]

Very interesting!   I think we will start using your pattern miner for
other things this fall -- finally -- for mining patterns from visual
perception and also language ...

more later ;)

and congratulations on making this work !!


On Wed, Jul 27, 2016 at 4:20 AM, Shujing Ke  wrote:
> To anyone who has interest,
>
> I just finished a new demo for unsupervised learning from observations with
> pattern mining.
>
> https://www.youtube.com/watch?v=X8C7nhIULZs
>
> Best,
> Shujing



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBeDRwEEG7MJD%3Dt4eS8%3DrtKcMOWZqT4ag4KdfST-at_4kA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Language learning from simple robot head experience

[Ben Goertzel]

asic Perceptions … so we can
get language learning experimentation rolling right away, without
waiting for extended perception…

LANGUAGE LEARNING

What I then suggest is that we

1) Use the ideas from Linas & Ben’s “unsupervised language learning”
paper to learn a small “link grammar dictionary” from the corpus
mentioned above.  Critically, the features associated with each word
should include features from non-linguistic PERCEPTION, not just
features from language.  (The algorithms in the paper support this,
even though non-linguistic features are only very briefly mentioned in
the paper.)  ….  There are various ways to use PLN inference chaining
and Shujing’s information-theoretic Pattern Miner (both within
OpenCog)  in the implementation of these ideas…

2) Once (1) is done, we then have a parallel corpus of quintuples of the form

[audiovisual scene, English sentence, parse of sentence via link
grammar with learned dictionary, Lojban sentence, PLN-Atomese
interpretation of Lojban sentence]

We can take the pairs

[parse of sentence via link grammar with learned dictionary,
PLN-Atomese interpretation of Lojban sentence]

from this corpus and use them as the input to a pattern mining process
(maybe a suitably restricted version of the OpenCog Pattern Miner,
maybe a specialized implementation), which will mine ImplicationLinks
serving the function of current RelEx2Logic rules.

The above can be done for sentences about Basic Perceptions only, and
also for sentences about Second Stage Perceptions.

NEXT STEPS FOR LANGUAGE LEARNING

The link grammar dictionary learned as described above will have
limited scope.  However, it can potentially be used as the SEED for a
larger link grammar dictionary to be learned from unsupervised
analysis of a larger text corpus, for which nonlinguistic correlates
of the linguistic constructs are not available.   This will be a next
step of experimentation.

NEXT STEPS FOR INTEGRATION

Obviously, what can be done with simple perceptions can be done with
more complex perceptions as well … the assumption of simple
perceptions is because that’s what we have working or almost-working
right now… but Hanson Robotics will put significant effort into making
better visual perception for their robots, and as this becomes a
reality we will be able to use it within the above process..



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBe8Dy7Ojb0uL1Rqow6u7rEmGLRw%2B%2B6nSsL5Af591KXMBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Language learning from simple robot head experience

[Ben Goertzel]

>From what I can tell, Google's tech leaders are smart, inventive and
good-hearted people who are  not, however, deep thinkers about AGI ...
they are too busy for that...

Demis and Shane are brilliant, inventive, deep-thinking people who are
however apparently convinced that loose brain emulation (Demis) or
some mix of loose brain emulation and algorithmic information based
approaches (Shane) are the best approach to AGI ... so they are simply
not that intellectually interested in approaches like OpenCog, even
though they're aware of it...

I would like to have more funds so we could hire more senior
developers and proceed faster.  However, I would not like this *as
badly* as I prefer the project to remain free and open source, as I
feel FOSS AGI will be the best course for the good of the humanity and
will increase the odds of a positive Singularity. So being fully
sucked into a big company or gov't agency or typical VC-funded AI
startup situation is not so compelling to me at this point... indeed
opportunities for this have been presented ...

The odds seem reasonable that with the current favorable climate
toward AGI, OpenCog will be able to secure greater funding during the
next year, so it can grow faster in various directions without
"selling out" 

Once we get the project past a certain critical threshold in terms of
funky downloadable demos AND clear documentation and simpler usabilty
by developers, then I think the thing can really take off quickly, and
become as I've said "the Linux of AGI" (just for a start).   Getting
to this threshold is proving slow and laborious given the complexity
of the design.  But from the inside, the progress is clear.  A
moderate-sized burst of funding would get us there, but we can also
very likely get there without that, just not quite as fast...

-- Ben





On Sat, Jul 30, 2016 at 5:08 AM, Andi  wrote:
> Ben, my congratulations for reaching this point!
>
> I am watching the AI scene since more than 40 years - as far as I can see,
> the opencog stystem is the richest and by far most probable to build an AGI.
>
> Why Google does not chain you and your team to a desk at their
> headquarters?
> They need to spend about 500.000.000 USD on new projects every week. Why
> they do not put one week on you and your team
> AGI is essential for them. Opecog is the only complete approach to reach it.
> Is there nobody at Google who watch closely opencog -and- understand what it
> is doing?
>
> Respect!
> Andi
>
>
>
>
>
> Am Freitag, 29. Juli 2016 03:32:11 UTC+2 schrieb Ben Goertzel:
>>
>> (proposed R&D project for fall 2016 - 2017)
>>
>> We are now pretty close (a month away, perhaps?) to having an initial,
>> reasonably reliable version of an OpenCog-controlled Hanson robot
>> head, carrying out basic verbal and nonverbal interactions.   This
>> will be able to serve as a platform for Hanson Robotics product
>> development, and also for ongoing OpenCog R&D aimed at increasing
>> levels of embodied intelligence.
>>
>> This email makes a suggestion regarding the thrust of the R&D side of
>> the ongoing work, to be done once the initial version is ready.  This
>> R&D could start around the beginning of September, and is expected to
>> take 9-12 months…
>>
>>
>> GENERAL IDEA:
>> Initial experiment on using OpenCog for learning language from
>> experience, using the Hanson robot heads and associated tools
>>
>> In other words, the idea is to use simple conversational English
>> regarding small groups of people observed by a robot head, as a
>> context in which to experiment with our already-written-down ideas
>> about experience-based language learning.
>>
>> BASIC PERCEPTION:
>>
>> I think we can do some interesting language-learning work without
>> dramatic extensions of our current perception framework.  Extending
>> the perception framework is valuable but can be done in parallel with
>> using the current framework to drive language learning work.
>>
>> What I think we need to drive language learning work initially, is
>> that the robot can tell, at each point in time:
>>
>> — where people’s faces are (and assign a persistent label to each person’s
>> face)
>>
>> — which people are talking
>>
>> — whether an utterance is happy or unhappy (and maybe some additional
>> sentiment)
>>
>> — if person A’s face is pointed at person B’s face (so that if A is
>> talking, A is likely talking to B) [not yet implemented, but can be
>> done soon]
>>
>> — the volume of a person’s voice
>>
>> — via speech-to-text, what people are saying
>>

[opencog-dev] OpenCog doing some basic reasoning via natural language in a robot control framework

[Ben Goertzel]

Here is a video of OpenCog doing basic reasoning based on natural
language interaction, thx to Nil Geisweiller and many others

https://www.youtube.com/watch?v=Gu6zrwAVD0k&feature=youtu.be

It's simple but it's a milestone of system integration -- getting PLN
logical reasoning, natural language comprehension and generation and
sentiment analysis working together in the robot control software
framework...

This example and others will be demonstrable on the physical robot very soon...

ben


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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBd2BxgJL10BQdZFhk1VPcgAaQCXOsBm3%2Bv1zNthK%2Bi1kQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] goertzel.org seems not to be online?

[Ben Goertzel]

Yes, it's down due to a malware problem I have not had time to fix ...
I will get it back up eventually...

On Tue, Aug 2, 2016 at 3:16 AM, Andi  wrote:
> ???
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/3f230a4d-cd57-4cb3-8b5a-52c8afecfab3%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBd5L%3DfDJWj0%3DoPi9KbWvEepwaOY_LgnNLfcNPckYw0ksg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] how to train a CNN with feature vectors and not images?

[Ben Goertzel]

Guys,

The big problem with using GPUs for OpenCog is that most OpenCog
cognitive algorithms would be better suited for MIMD parallelism than
for SIMD parallelism

To put it simply, GPUs are SIMD parallel which means they are suited
for cases where one needs to repetitively do the same thing over and
over to multiple data items ...  Neural net algorithms tend to be like
this.   In OpenCog, ECAN is also like this (as it's basically a
special variant of an attractor neural net).   But the other OpenCog
algorithms are generally not like this.  They are tractably
parallelizable, but only on a MIMD parallel substrate...

Another issue is RAM access -- for OpenCog (or any system centered on
manipulation of large graphs) the biggest cost in terms of processing
time is RAM access for small, hard to predict RAM read/writes   So
if the bulk of RAM is not on the GPU then all the savings realized by
the GPU will be eaten by GPU-CPU messaging

What you really want for OpenCog is a MIMD parallel chip, with a lot
of RAM, and special connects btw the processors' caches.   This
would let you put OpenCog on embedded devices in a useful way, and
also build OpenCog-tailored supercomputers  These would be
customized for OpenCog in the same sense that the current crop of
"deep learning chips" are customized for hierarchical NNs.

Mandeep Bhatia and I have sketched some ideas about an "OpenCog chip"
along these lines but have been too busy with other stuff to refine
these ideas into a detailed design that can be given to an FPGA
programmer for prototyping... it will happen eventually ;)

For the present, GPUs could be used for certain special purposes
within OpenCog -- e.g.

-- ECAN importance spreading across an Atomspace whose structure does
not frequently change

-- maybe, with a lot of work, some sort of limited (but could still be
very useful) pattern matching against an Atomspace whose structure
does not frequently change


These could be quite valuable but wouldn't constitute "porting the
whole OpenCog to GPU"

-- Ben



On Tue, Aug 2, 2016 at 3:43 AM, Andi  wrote:
> Hi Gaurav,
> I think that it should be possible to take advantage of the massiv parallel
> computing power of a GPU also for the OpenCog system like it is used for
> NNs.
>
> So, are there any NP-hard problems inside the box?
>
> --Andi
>
> Am Dienstag, 2. August 2016 03:22:22 UTC+2 schrieb Gaurav Gautam:
>>
>> I may be wrong, but as far as I understand one problem may be that neural
>> networks are not really graphs or hypergraphs. Books show them as a set of
>> layers and some connecting edges which looks a lot like a graph, but when
>> they are implemented in code, they mostly are matrix operations. So, as far
>> as I understand a program implementing a neural network will be doing matrix
>> operations. If I am right about this, then I don't see how seeing atomspace
>> as a neural network will help.
>>
>> What I am saying is that I don't think the atoms and links can be
>> connected to make a neural network straightforwardly. Of course, one could
>> make atoms that represent the coefficients of the model that the CNN
>> represents and then connect those with links that have weights and then make
>> a function that can take such a hypergraph and tune the weights. But
>> wouldn't that be very inefficient? Wouldn't you want to just represent a
>> feature vector in atomese and then run CNN on it (through an external
>> library perhaps) and get results in atomese that the other algorithms can
>> pick up? But then again, I have very little idea what I am talking about, so
>> I may be way off.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/067f3e5c-493e-4f68-b7fb-1c2b46a05bb2%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBcFDqo-L8cdZfh13pkXrt3fFN%2BtPLihUBptT%3DoyeGpajA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] how to train a CNN with feature vectors and not images?

[Ben Goertzel]

A lot of people have tried to make graph manipulations work
effectively on GPU, and have also tried to make parallel backtracking
work effectively on GPU .. there are various MS and PhD theses in
these directions around ... there are logical-looking methods that
have been tried, but I've never seen anyone demonstrate or report
significant speedup on nontrivial problems.   In the end one is
trying to fix a square peg in a round hole (er, a graph-shaped peg in
a low-dimensional-array shaped hole..), and it's awkward and not so
efficient...



On Tue, Aug 2, 2016 at 11:05 AM, Linas Vepstas  wrote:
> Hi Andi,
>
> Ben has a good answer, and to emphasize, let me add this:   Think of the
> atomspace as being a collection of trees.  The atoms are the nodes in the
> tree.  Any one atom can appear in many trees, and so the whole thing is in
> fact tangled into a big matt, like a rhizome
> https://www.google.com/search?q=rhizome&tbm=isch
>
> The pattern matcher starts at one atom, and walks the rhizome, exploring
> nearest neighbors, until all the entire neighborhood is explored (and a
> match is found, or some other (local) computation is performed).
>
> The problem is that the atoms are scattered randomly through RAM, so when
> the nearest neighbor walk happens, random locations in RAM get visited.  I'm
> guessing that there is a lot of cache-miss going on two:  If you have, say,
> a CPU cache that is 8-way, 4-associative, then you could have maybe 32 atoms
> in the cache, but the chance that the 33rd atom will accidentally be in one
> of the existing cache lines is just about zero, and so the graph walk will
> have a 99.9% cache-miss rate.   (most graphs that get searched have more
> that 32 atoms in them. )
>
>
> Hmm, I have an idea -- I guess the atomsapce *could* keep track of
> individual connected components  (create a bag of trees, which are connected
> by one or more atoms) -- any given search is guaranteed to stay in just one
> bag, and so maybe one could download the entire bag to the gpu before
> starting a search.   Could work if the bags are small enough to fit in GPU
> ram.
>
> Maybe allocation could be changed to improve cache locality: allocate atoms
> so that they are more likely to be on the same cache line if they are also
> connected.  But this becomes a hard, fiddly computer-science problem...
>
> --linas
>
>
> On Mon, Aug 1, 2016 at 3:26 PM, Andi  wrote:
>>
>> Hello All,
>> I do not want to disturb the ongoing work so an answer to this question is
>> not urgent,
>> but it will help me during my investigations within the next month.
>>
>> What in the hell could prevent me to look at the Atomspace as a certain
>> kind of Neuronal Network?
>>
>> Please don't tell me:"Because it is a hypergraph" haha
>>
>> One of my aims is, try to port the whole thing, or some parts, to
>> hardware. Maybe a bunch of some GPU's, PLD's and a CPU can do it. It seems
>> that they are designing some interesting machines for Deep Learning - so
>> maybe even nothing new has to be invented..
>>
>> For first steps I think it should at least be possible to use some
>> GPU-power to do some work in parallel or is there really a theoretical
>> barrier for paralleling some work that I cannot see in the moment?
>>
>> Please don't be afraid,  I know what kind of challenging task this is and
>> would carry it on my own back. But maybe it is not so much work if the right
>> approach is found...
>> At least I want to investigate this - so any red lights blinking?
>>
>> --Andi
>>
>>
>> Am Sonntag, 24. April 2016 07:07:25 UTC+2 schrieb Ben Goertzel:
>>>
>>> Indeed this is not an OpenCoggy question, but some of us may be able
>>> to help... is this dynamic data or instantaneous data you're trying to
>>> classify?
>>>
>>>
>>>
>>> On Sat, Apr 23, 2016 at 1:46 PM,   wrote:
>>> > Hi
>>> >
>>> > I have a dataset of mocap (motion caption) positions as vectors which I
>>> > am
>>> > going to train a DNN for this dataset.
>>> > the sample data would be like a 140-D dimension vector.
>>> > Is it possible to train a CNN for this kind of data? I have
>>> > how to use convolution layers for this kind of data as kernels are
>>> > e.g.5x5
>>> > while the data is  a vector?
>>> >
>>> >
>>> > If I make the data in a form of matrix, is it possible to train a
>>> > pretrained
>>> > CNN e.g. alexnet for this dataset?
>>> >
>>> > Best
>

Re: [opencog-dev] randme openpsi to ... decider?

[Ben Goertzel]

Yeah, we just discussed this F2F.   It seems that "OpenPsi" as
currently used sorta wraps up two things...

1) The action selector and related tools, which are generic and would
be used for a theorem-prover or various other sorts of AIs that have
no close resemblance to the human mind

2) A model of human-like psychology / emotion / action-regulation,
which at this point is a custom blend of Psi and the CPM (Component
Process Model), and may get even more human-specific aspects due to
the Hanson Robotics collaboration

...

.. and I agree w/ LInas it would be useful to separate these cleanly.
Both are valuable but they are distinct.

An accurate but long/boring name for 1) would be "Action Selector and
Formulator" ... which can fairly enough be abbreviated "action
selector" I guess ...

A worry with "Decider" is that PLN also decides things, but in the
declarative rather than imperative sense but... hmmm...

An accurate but long/boring name for 2) would be "Human-Like
Regulation" I guess ...

Name brainstorms will be appreciated ;)

ben

On Tue, Aug 2, 2016 at 1:01 PM, Linas Vepstas  wrote:
> The openpsi name is problematic:
>
> -- Joscha Bach's psi is also open-source
> -- openpsi is no longer the main psychological modeller for opencog
> (the "component process model" now is)
>
> This suggests that a better name is needed.
>
> The functions implemented in openpsi perform a very important task of
> selecting and choosing and deciding what to do, based on the need to fulfill
> certain goals.   The goals need not be psychological goals, and the chosen
> "things" are usually "actions" but not necessarily so.
>
> "action selector" is one but its boring. "action formulator and selector"
> ASAF ASF AFS AFAS is aonther mouthful.
>
> How about "the decider"?
> pluses: its short, its a term not used anywhere else in the system, so no
> confusion about which subsystem it refers to.  Its unique enough that there
> is not even a collision with most OS or compsci theory and no confusion with
> NN or ANN theory.  Yet you can guess what it does, given just its one-word
> name.
>
> minuses: unfortunate reference to dubya.
>
> --linas
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/CAHrUA35yrok%2BmW-VyPpOOw%3DRT1haUN4wTJr6tSqJungQ6K4WgQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBd_V_vXoPcNjFKMb%2BKu1jaVMfu3tNahPBTMusYG9YDR7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Re: [hansonrobotics/HEAD] ROS NMPT Salience Detector: Degree Values and Salient Feature Tracking (#117)

[Ben Goertzel]

se of the contrast in the image (sharp black/what, or
>> mostly washed-out grey)
>> -- sudden changes in overall lighting
>> -- average color for the entire visual field.
>>
>> Sunlit rooms tend to have high contrast; lots of blue suggests the sky is
>> visible; a sudden change of lighting suggests that someone put their hand
>> over the camera.
>>
>> Apparently, people cover the camera with their hands a lot during demos,
>> and I would really really like to know when that happens.
>>
>> There's other stuff I'd like to see, that would allow the robot to
>> actually *learn*, but that is for a some future email.  The short version is
>> that I would like to be able to send the detector some little tiny snippets
>> of pseudo-code, and have it run that pseudo-code, and report when it
>> triggers. The pseudo-code would consist of little algorithmic combinations
>> of speed, color, movement, size, etc. and opencog would generate these and
>> use them as feature detectors.  I.e. rather than hard-coding (hand-coding)
>> the feature detectors, they would be generated dynamically, on the fly, by
>> opencog itself, rather than by human programmers.   This is an idea for the
>> future, though.  Important, but not urgent.
>>
>> -- Linas
>>
>>
>>
>



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdRoyfEbeC0bRn8E_Z1ghGqy2HcJZbEUYktv%3Dka7DS01g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Re: [hansonrobotics/HEAD] ROS NMPT Salience Detector: Degree Values and Salient Feature Tracking (#117)

[Ben Goertzel]

For sure we all want to go further!  But we need to demonstrate
moderately cool stuff in the immediate term, and this saliency
detector (appropriately leveraged within Psi rules) should be helpful
in that regard...

On Wed, Aug 10, 2016 at 5:03 PM, Linas Vepstas  wrote:
> OK, well, if you just write a teensy sliver of code that simply turns the
> head towards any direction where something "sufficiently salient" happened,
> then sure, that makes for a livelier, more entertaining demo. And so maybe
> that is worthwhile.
>
> But it also keeps her at the "dumb robot" level, reacting to a stimulus
> without any clue as to why -- its like a single-neuron circuit -- whenever
> one end of the neuron gets tickled, the other end turns a motor.   I want to
> move past single-neuron reactive circuitry.   I mean, doors that swing out
> of your way when you approach them were were in all the supermarkets by the
> 1960's -- turning your head to look at something "salient" is at about the
> same level of sophistication.  Its been 50 years. Yes, get to that, but then
> go farther.
>
> --linas
>
> On Tue, Aug 9, 2016 at 1:08 AM, Ben Goertzel  wrote:
>>
>> Hi LInas, many of your suggestions are good ones and should be added to
>> the list
>>
>> However, the "visual saliency" term was not invented by us -- and the
>> addition of this saliency detector was especially suggested by David H
>> because in his prior work he has found similar code to be useful with
>> his robots  So I guess I will trust him that it's a useful
>> indicator to have, even though I agree with you that lots of other
>> stuff is also useful
>>
>> The reason for adding a "Degree" was that without it, the saliency
>> detector gave way too many false positives  Having a degree lets
>> us tune a threshold denoting what is salient enough to bother doing
>> anything about...
>>
>> ben
>>
>> On Mon, Aug 8, 2016 at 1:01 PM, Linas Vepstas 
>> wrote:
>> > Oops, hit "send" on the email too soon.
>> >
>> > Perhaps the #1 most important thing on the list is the "sudden change in
>> > brightness" detector.   During the demos people either cover her camera
>> > or
>> > get up in her face, and say things like "can you see me now", and I
>> > would
>> > really like to have the robot know when this is happening -- this is
>> > probably the #1 most important demoable feature, more important than
>> > saliency, movement, anything else.
>> >
>> > The #2 most important feature would be size-of-movement -- another thing
>> > people do is to wave their hand directly in front of the camera:  From
>> > the
>> > camera point of view, it would look like everything is moving everywhere
>> > --
>> > the entire visual field is moving.  It doesn't have a location, because
>> > its
>> > everywhere.  Again, this is a very important situation to recognize, and
>> > relay to the robot.
>> >
>> > Both of the above should be easy to implement, and are more important,
>> > demo-wise, than "saliency".
>> >
>> > --linas
>> >
>> >
>> >
>> > On Mon, Aug 8, 2016 at 2:49 PM, Linas Vepstas 
>> > wrote:
>> >>
>> >> I have multiple issues with the so-called "saliency detector" in this
>> >> pull
>> >> request: https://github.com/hansonrobotics/HEAD/pull/117 that I'm
>> >> thinking
>> >> its better to discuss these in general, rather than simply in the
>> >> context of
>> >> one pull request.
>> >>
>> >> So:...
>> >>
>> >> On Wed, Jul 27, 2016 at 10:06 AM, natnaelargaw
>> >> 
>> >> wrote:
>> >>>
>> >>> the frequency of occurrence of a salient point with in a fixed turn
>> >>> around time t. Further more, this method norm
>> >>
>> >>
>> >> First off, the entire module seems to be mis-named -- it has nothing at
>> >> all to do with "saliency" -- rather, the device seems to be a
>> >> motion-tracker.
>> >>
>> >> Something can be highly salient, and completely still, but that is not
>> >> what this does, based on the description in the README.
>> >>
>> >> Next, I'd like to see an API change. Put yourself in the place of
>> >> opencog.
>> >> Suppose you were blind-folded,  a

Re: [opencog-dev] goertzel.org seems not to be online?

[Ben Goertzel]

Yes, there is a malware problem on that server, some of my interns
have been struggling to fix it for a couple weeks, it should be almost
fixed now...

On Fri, Aug 12, 2016 at 11:12 AM, Andi  wrote:
> Trying to acces goertzel.org now i got this..
>
> http://www.mcafee.com/threat-intelligence/site/default.aspx?url=http://successurls.org/bssIn?extra_param_1=G91825&se=&utm_source=wp.goertzel.org&utm_medium=redirect&utm_campaign=general&utm_content=general&utm_term=Ben%20Goertzel%27s%20Website
>
>
> Am Dienstag, 2. August 2016 14:59:19 UTC+2 schrieb Ben Goertzel:
>>
>> Yes, it's down due to a malware problem I have not had time to fix ...
>> I will get it back up eventually...
>>
>> On Tue, Aug 2, 2016 at 3:16 AM, Andi  wrote:
>> > ???
>> >
>> > --
>> > 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/3f230a4d-cd57-4cb3-8b5a-52c8afecfab3%40googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Ben Goertzel, PhD
>> http://goertzel.org
>>
>> Super-benevolent super-intelligence is the thought the Global Brain is
>> currently struggling to form...
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/b9ba3f44-2286-4222-b91b-e32200c5d488%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBe6fWKCc_eau28sQTtp5Zj3YvDO3M2fS-eQK5iCfpoAcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] What CYC has done wrong

[Ben Goertzel]

He's focusing on micro-level things they did wrong, but not
confronting the possibility that making a huge handcoded KB is just
the wrong thing to be doing...

For instance he notes they have had to add 75 kinds of "in" to handle
different sorts of "in" relationship ... but doesn't question whether
it might be smarter to have the system instead learn various shades of
"in", which could allow it to learn 1000s of context-specific senses
not just 75 ...

ben



On Tue, Aug 16, 2016 at 1:30 PM, Linas Vepstas  wrote:
> The below is an old presentation, from 2009, but its the first I've seen of
> it.  Its long, I have not read it yet.   However, I suspect that it probably
> says good things (I hope; else that would be something else that CYC did
> wrong...)
>
> http://c4i.gmu.edu/oic09/papers/Mistakes%20Were%20Made%20OIC%202009%20keynote.pdf
>
> Everyone working on opencog theory should probably read it and memorize it
> and apply those lessons to the things we do.
>
> Thanks to Lukasz Stafiniak for pointing this out.
>
> --linas
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/CAHrUA369vqLVG7xEx5vVS%2BASqtaKMNSVBc7S3rdxdU8gGgEFOQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBfej%2Bn9u6%3DSjVcZ5JOUjHo%3DG86EVRMiqu9PNP0SRXyTyg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] What CYC has done wrong

[Ben Goertzel]

tions.
>>>
>>>
>>> Thanks Noah!
>>>
>>> --linas
>>>>
>>>>
>>>> --
>>>> 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+unsubscr...@googlegroups.com.
>>>> To post to this group, send email to opencog@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/b40a25d7-a3a9-4406-8ae8-ee54fb025462%40googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "opencog" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/opencog/y--WRlIxf3s/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> opencog+unsubscr...@googlegroups.com.
>>> To post to this group, send email to opencog@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/CAHrUA35YO3gA7gtQ8XefhvqvM328JbWO8e8NviKAdbYV8Q%3D1ag%40mail.gmail.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+unsubscr...@googlegroups.com.
>> To post to this group, send email to opencog@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/CA%2B2nBRv08AFbOw83RLG5eMANq%2B%2Bx%2B0ZOTrq%2B4BJEnAVwmAc9PQ%40mail.gmail.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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/CAHrUA34B%3DzND5ijL-KrzOc9Bv4pNQi6ESpyKyiAGJe1w0ibC9w%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdYPOyKGrksnoOe21nApFJdjUkDwmk_WcTPGSjz-jHpLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] probabilistic type theory with records ... variants of categorial grammar & semantics, etc.

[Ben Goertzel]

Linas, Nil, etc. --

This variation of type theory

http://www.dcs.kcl.ac.uk/staff/lappin/papers/cdll_lilt15.pdf

seems like it may be right for PLN and OpenCog ... basically,
dependent type theory with records (persistent memory) and
probabilities ...

If we view PLN as having this sort of semantics, then RelEx+R2L is
viewed as enacting a morphism from:

-- link grammar, which is apparently equivalent to pregroup grammar,
which is a nonsymmetric cartesian closed category

to

-- lambda calculus endowed with the probabilistic TTR type system,
which is a locally cartesian closed category

https://ncatlab.org/nlab/show/relation+between+type+theory+and+category+theory#DependentTypeTheory

For the value of dependent types in natural language semantics, see e.g.

http://www.slideshare.net/kaleidotheater/hakodate2015-julyslide?qid=85e8a7fc-f073-4ded-a2c8-9622e89fd07d&v=&b=&from_search=1

(the examples regarding anaphora in the above are quite clear)

https://ncatlab.org/nlab/show/dependent+type+theoretic+methods+in+natural+language+semantics

This paper

http://www.slideshare.net/DimitriosKartsaklis1/tensorbased-models-of-natural-language-semantics?qid=fd4cc5b3-a548-46a7-b929-da8246e6c530&v=&b=&from_search=2

on the other hand, seems mathematically sound but conceptually wrong
in its linguistic interpretation.

It constructs a nice morphism from pregroup grammars (closed cartesian
categories) to categories defined over vector spaces -- where the
vector spaces are taken to represent co-occurence vectors and such,
indicating word semantics  The morphism is nice... however, the
idea that semantics consists of numerical vectors is silly ...
semantics is much  richer than that

If we view grammar as link-grammar/pregroup-grammar/asymmetric-CCC ...
we should view semantics as {probabilistic TTR  / locally compact
closed CCC *plus* numerical-vectors/linear-algebra}

I.e. semantics has a distributional aspect AND ALSO a more explicitly
logical aspect

Trying to push all of semantics into distributional word vectors,
leads them into insane complexities like modeling determiners using
Frobenius algebras... which is IMO just not sensiblen ... it's trying
to achieve a certain sort of mathematical simplicity that does not
reflect the kind of simplicity seen in natural systems like natural
language...

Instead I would say RelEx+R2L+ECAN (on language) +
word-frequency-analysis can be viewed as enacting a morphism from:

-- link grammar, which is apparently equivalent to pregroup grammar,
which is a nonsymmetric cartesian closed category

to the product of

-- lambda calculus endowed with the probabilistic TTR type system,
which is a locally cartesian closed category

-- the algebra of finite-dimensional vector spaces

This approach accepts fundamental heterogeneity in semantic representation...

-- Ben

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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdon6m8Vc8JN8Xt%3Dge3O1iQOPQ-yVL%2BZc%2Bjizt7S7S8%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] future of atomese

[Ben Goertzel]

OK -- I see the light now ...

What we need to do is

1) make a surface syntax for Atomese that is effectively like Agda,
but a good bit prettier

2) make an ultra-fast type checker that encompasses moderately complex
dependent types

3) then instead of using slow Agda, and incurring the overhead of
going Agda ==> Haskell ==> C++ ... we just go straight NewAtomese ==>
C++, and everything is fast as well as elegant (well everything except
the slow things actually happening inside OpenCog...)

... in line with the general principle that integrating others' ideas
sometimes ends up working better than integrating their code...

But ... well ... not this month I guess ;)

ben

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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdDBfi%3DSSnvRpixtsL_AqRu75AxZbX%2BAN9UkdLZAZHX2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Re: [Link Grammar] Re: probabilistic type theory with records ... variants of categorial grammar & semantics, etc.

[Ben Goertzel]

Linas,

Alas my window of opportunities for writing long emails on math-y
stuff has passed, so I'll reply to your email more thoroughly in a
couple days...

However, let me just say that I am not so sure linear logic is what we
really want  I understand that we want to take resource usage into
account in our reasoning generally... and that in link grammar we want
to account for the particular exclusive nature of the disjuncts ...
but I haven't yet convinced myself linear logic is necessarily the
right way to do this... I need to take a few hours and reflect on it
more and try to assuage my doubts on this (or not)

-- ben


On Tue, Aug 30, 2016 at 6:14 AM, Linas Vepstas  wrote:
> It will take me a while to digest this fully, but one error/confusion (and
> very important point) pops up immediately: link-grammar is NOT cartesian,
> and we most definitely do not want cartesian-ness in the system.  That would
> destroy everything interesting, everything that we want to have.  Here's the
> deal:
>
> When we parse in link-grammar, we create multiple parses.  Each parse can be
> considered to "live" in its own unique world or universe (it's own Kripke
> frame)  These universes are typically incompatible with each other: they
> conflict. Only one parse is right, the others are wrong (typically --
> although sometimes there are some ambiguous cases, where more than one parse
> may be right, or where one parse might be 'more right' than another).
>
> These multiple incompatible universes are symptomatic of a "linear type
> system".  Now, linear type theory finds applications in several places: it
> can describe parallel computation (each universe is a parallel thread) and
> also mutex locks and synchronization, and also vending machines: for one
> dollar you get a menu selection of items to pick from -- the ChoiceLink that
> drove Eddie nuts.
>
> The linear type system is the type system of Linear logic, which is the
> internal language of the closed monoidal categories, of which the closed
> cartesian categories are a special case.
>
> Let me return to multiple universes -- we also want this in PLN reasoning. A
> man is discovered standing over a dead body, a bloody sword in his hand --
> did he do the deed, or is he simply the first witness to stumble onto the
> scene?  What is the evidence pro and con?
> This scenario describes two parallel universes: one in which he is guilty,
> and one in which he is not. It is the job of the prosecutor, defense, judge
> and jury to figure out which universe he belongs to.  The mechanism is a
> presentation of evidence and reasoning and deduction and inference.
>
> Please be hyper-aware of this, and don't get confused: just because we do
> not know his guilt does not mean he is "half-guilty", -- just like an
> unflipped coin is not a some blurry, vague superimposition of heads and
> tails.
>
> Instead, as the evidence rolls in, we want to find that the probability of
> one universe is increasing, while the probability of the other one is
> decreasing.  Its just one guy -- he cannot be both guilty and innocent --
> one universe must eventually be the right one,m and it can be the only one.
> (this is perhaps more clear in 3-way choices, or 4-way choices...)
>
> Anyway, the logic of these parallel universes is linear logic, and the type
> theory is linear type theory, and the category is closed monoidal.
>
> (Actually, I suspect that we might want to use affine logic, which is per
> wikipedia "a substructural logic whose proof theory rejects the structural
> rule of contraction. It can also be characterized as linear logic with
> weakening.")
>
> Anyway, another key point: lambda calculus is the internal language of
> *cartesian* closed categories.  It is NOT compatible with linear logic or
> linear types.   This is why I said in a different email, that "this way lies
> madness".  Pursuit of lambda calc will leave us up a creek without a paddle,
> it will prevent us from being able to apply PLN to guilty/not-guilty court
> cases.
>
> 
> BTW, vector spaces are NOT cartesian closed! They are the prime #1 most
> common example of where one can have tensor-hom adjunction, i.e. can do
> currying, and NOT be cartesian!  Vector spaces *are* closed-monoidal.
>
> The fact that some people are able to map linguistics onto vector spaces
> (although with assorted difficulties/pathologies) re-affirms that
> closed-monoidal is the way to go.  The reason that linguistics maps poorly
> onto vector spaces is due to their symmetry -- the linguistics is NOT
> symmetric, the vector spaces are.So what we are actually doing (or need
> to do) is develop the infrastructure for *cough cough* a non-symme

Re: [opencog-dev] Pattern Miner and missing libTestPatternMinerAgent.so

[Ben Goertzel]

Did you try the steps here?

http://wiki.opencog.org/wikihome/index.php/Pattern_miner#Steps_to_run_a_non-distributed_pattern_miner_test

On Tue, Aug 30, 2016 at 11:13 PM,   wrote:
>
> Hello all,
>
> I tried running pattern Miner. I did the following:
>
> installed Boost
> installed cpprest
> started cogserver
> Loaded,  `opencog> loadmodule
> opencog/learning/PatternMiner/libTestPatternMinerAgent.so`
>
> But it displayed :
> `opencog> loadmodule
> opencog/learning/PatternMiner/libTestPatternMinerAgent.so
>  Unable to load module
> "opencog/learning/PatternMiner/libTestPatternMinerAgent.so". Check the
> server logs for details.`
>
> I also checked for the libTestPatternMinerAgent shared object file. But
> there is no such .so file inside Pattern Miner folder.
> How can i solve this?
>
> Thanks in advance.
>
> Regards,
> Vishnu.
>
>
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/5ffc3757-eaca-4434-87c7-0cbda6e67d64%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBf70HD%2BwFBOLwRd95Dyn3GfLs3HEOMtR8d0b8nMBdeXcA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Pattern Miner and missing libTestPatternMinerAgent.so

[Ben Goertzel]

I remember Nil met a vaguely similar problem here, due to some missing
linkage...

https://groups.google.com/forum/#!msg/opencog/7A0WDFrTKhk/UNakwr9GAQAJ

On Tue, Aug 30, 2016 at 11:47 PM,   wrote:
>
> Yes 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/e49d87f5-565d-4e94-9e28-ef3380b254b2%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBeFTgkRCXJJRr4%3DCQV9RTMjERNnOeHMNBdPMLcvAQKOGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: [Link Grammar] Re: probabilistic type theory with records ... variants of categorial grammar & semantics, etc.

[Ben Goertzel]

p.
>
> There's another way of thinking of chip verification: one might say, in any
> given universe/kripke frame, that a given transistor is in one of three
> states: on, off, or "don't know", with the "don't know" state corresponding
> to the "we haven't simulated/verified that one yet".   The collection of
> possible universes shrinks, as you eliminate the "don't know" states during
> the proof process.This kind of tri-valued logic is called
> "intuitionistic logic" and has assorted close relationships to linear logic.
>
> These same ideas should generalize to PLN:  although PLN is itself a
> probabilistic logic, and I do not advocate changing that, the actual
> chaining process, the proof process of arriving at conclusions in PLN,
> cannot be, must not be.
>
> I hope the above pins down the source of confusion, when we talk about these
> things.  The logic happening at the proof level, the ludics level, is very
> different from the structures representing real-world knowledge.
>
> --linas
>
> On Tue, Aug 30, 2016 at 9:28 AM, Ben Goertzel  wrote:
>>
>> Linas,
>>
>> Alas my window of opportunities for writing long emails on math-y
>> stuff has passed, so I'll reply to your email more thoroughly in a
>> couple days...
>>
>> However, let me just say that I am not so sure linear logic is what we
>> really want  I understand that we want to take resource usage into
>> account in our reasoning generally... and that in link grammar we want
>> to account for the particular exclusive nature of the disjuncts ...
>> but I haven't yet convinced myself linear logic is necessarily the
>> right way to do this... I need to take a few hours and reflect on it
>> more and try to assuage my doubts on this (or not)
>>
>> -- ben
>>
>>
>> On Tue, Aug 30, 2016 at 6:14 AM, Linas Vepstas 
>> wrote:
>> > It will take me a while to digest this fully, but one error/confusion
>> > (and
>> > very important point) pops up immediately: link-grammar is NOT
>> > cartesian,
>> > and we most definitely do not want cartesian-ness in the system.  That
>> > would
>> > destroy everything interesting, everything that we want to have.  Here's
>> > the
>> > deal:
>> >
>> > When we parse in link-grammar, we create multiple parses.  Each parse
>> > can be
>> > considered to "live" in its own unique world or universe (it's own
>> > Kripke
>> > frame)  These universes are typically incompatible with each other: they
>> > conflict. Only one parse is right, the others are wrong (typically --
>> > although sometimes there are some ambiguous cases, where more than one
>> > parse
>> > may be right, or where one parse might be 'more right' than another).
>> >
>> > These multiple incompatible universes are symptomatic of a "linear type
>> > system".  Now, linear type theory finds applications in several places:
>> > it
>> > can describe parallel computation (each universe is a parallel thread)
>> > and
>> > also mutex locks and synchronization, and also vending machines: for one
>> > dollar you get a menu selection of items to pick from -- the ChoiceLink
>> > that
>> > drove Eddie nuts.
>> >
>> > The linear type system is the type system of Linear logic, which is the
>> > internal language of the closed monoidal categories, of which the closed
>> > cartesian categories are a special case.
>> >
>> > Let me return to multiple universes -- we also want this in PLN
>> > reasoning. A
>> > man is discovered standing over a dead body, a bloody sword in his hand
>> > --
>> > did he do the deed, or is he simply the first witness to stumble onto
>> > the
>> > scene?  What is the evidence pro and con?
>> > This scenario describes two parallel universes: one in which he is
>> > guilty,
>> > and one in which he is not. It is the job of the prosecutor, defense,
>> > judge
>> > and jury to figure out which universe he belongs to.  The mechanism is a
>> > presentation of evidence and reasoning and deduction and inference.
>> >
>> > Please be hyper-aware of this, and don't get confused: just because we
>> > do
>> > not know his guilt does not mean he is "half-guilty", -- just like an
>> > unflipped coin is not a some blurry, vague superimposition of heads and
>> > tails.
>> &

Re: [opencog-dev] Re: [Link Grammar] Re: probabilistic type theory with records ... variants of categorial grammar & semantics, etc.

[Ben Goertzel]

Regarding link parses and possible worlds...

In the TTR paper they point out that "possible worlds" is somehow
conceptually misleading terminology, and it may often be better to
think about "possible situations" (in a deep sense each possible
situation is some distribution over possible worlds, but it may rarely
be necessary to go that far)

In that sense, we can perhaps view the type of a link parse as a
dependent type, that depends upon the situation ... (?)

This is basically the same as viewing the link-parser itself as a
function that takes (sentence, dictionary) pairs into functions that
map situations into sets of link-parse-links  [but the latter is a
more boring and obvious way of saying it ;p]

But again, I don't (yet) see why linear logic would be required
here... it seems to me something like TTR with  truth values is
good enough, and we can handle resource management on the "Occam's
razor" level

As you already know (but others may not have thought about), weighting
possible link parses via their probabilities based on a background
corpus, is itself a form of "resource usage based Occam's razor
weighting".   Because the links and link-combinations with higher
probability based on the corpus, are the ones that the OpenCog system
doing the parsing has more reason to retain in the Atomspace --- thus
for higher-weighted links or link-combinations, the "marginal memory
usage" required to keep those links/link-combinations in memory is
less.  So we can view the probability weighting of a potential parse
as proportional to the memory-utilization-cost of that parse, in the
context of a system with a long-term memory full of other parses from
some corpus (or some body of embodied linguistic experience,
whatever...).

Currently it seems to me that the probabilistic weighting of parses
(corresponding to possible situations) is already handling
resource-management implicitly and we don't need linear logic to do
that here...

Of course these things are pretty subtle when you really think about
them, and I may be missing something...

ben


On Wed, Aug 31, 2016 at 1:10 AM, Ben Goertzel  wrote:
>  Linas,
>
> Actually, even after more thought, I still don't (yet) see why linear
> logic is needed here...
>
> In PLN, each statement is associated with at least two numbers
>
> (strength, count)
>
> Let's consider for now the case where the strength is just a probability...
>
> Then in the guilt/innocence case, if you have no evidence about the
> guilt or innocence, you have count =0   So you don't have to
> represent ignorance as p=.6 ... you can represent it as
>
> (p,n) = (*,0)
>
> The count is the number of observations made to arrive at the strength 
> figure...
>
> PLN count rules propagate counts from premises to conclusions, and if
> everything is done right without double-counting of evidence, then the
> amount of evidence (number of observations) supporting the conclusion
> is less than or equal to the amount of evidence supporting the
> premises...
>
> This does not handle estimation of resource utilization in inference,
> but it does handle the guilt/innocence example
>
> As for the resource utilization issue, certainly one can count the
> amount of space and time resources used in drawing a certain inference
> ... and one can weight an inference chain via the amount of resources
> it uses... and one can prioritize less expensive inferences in doing
> inference control.  This will result in inferences that are "simpler"
> in the sense of resource utilization, and hence more plausible
> according to some variant of Occam's Razor...
>
> But this is layering resource-awareness on top of the logic, and using
> it in the control aspect, rather than sticking it into the logic as
> linear and affine logic do...
>
> The textbook linear logic example of
>
> "I have $5" ==> I can buy a sandwich
> "I have $5" ==> I can buy a salad
> |- (oops?)
> "I have $5" ==> I can buy a sandwich and I can buy a salad
>
> doesn't impress much much, I mean you should just say
>
> If I have $5, I can exchange $5 for a sandwich
> If I have $5, I  can exchange $5 for a salad
> After I exchange $X for something else, I don't have $X anymore
>
> or whatever, and that expresses the structure of the situation more
> nicely than putting the nature of exchange into the logical deduction
> apparatus  There is no need to complicate one's logic just to
> salvage a crappy representational choice...
>
> In linear logic: It is no longer the case that given A implies B and
> given A, one can deduce both A and B ...
>
> In PLN, if one has
>
> A 
> (ImplicationLink A B) 
>
> one 

Re: [opencog-dev] Re: [Link Grammar] Re: probabilistic type theory with records ... variants of categorial grammar & semantics, etc.

[Ben Goertzel]

se aspects of PLN are completely and utterly irrelevant to the proof.
>> The only thing that mattered is that PLN takes, as input, some atoms, and
>> applies some transformation, and generates atoms. That's it.
>>
>> The above theorem is *why* I keep talking about possible worlds and
>> kripke-blah-blah and intuitionistic logic, and linear logic. its got NOTHING
>> TO DO WITH THE ACTUAL PLN RULES!!! the only thing that matters is that there
>> are rules, that get applied in some way.  The generic properties of linear
>> logic and etc. are the generic properties of rule systems and kripke frames.
>> Examples of such rule systems include link-grammar, PLN, NARS, classical
>> logic, and many more.  The details of the specific rule system do NOT alter
>> the fundamental process of rule application aka "parsing" aka "reasoning"
>> aka "natural deduction" aka "sequent calculus".Confusing the details of
>> PLN with the act of parsing is a category error: the logic that describes
>> parsing is not PLN, and PLN dos not describe parsing: its a category error
>> to intermix the two.
>>
>> Phew.
>>
>> What remains to be done:  I believe that what I describe above, the
>> "many-worlds hypothesis" of reasoning, can be used to create a system that
>> is far more efficient than the current PLN backward/forward chainer.  It's
>> not easy, though: the link-parser algorithm struggles with the combinatoric
>> explosion, and has some deep, tricky techniques to beat it down.  ECAN was
>> invented to deal with the explosion in PLN.  There are other ways.
>>
>> By the way: the act of merging the results of a PLN inference back into
>> the original atomspace corresponds, in a very literal sense, to a "wave
>> function collapse". As long as you keep around multiple atomspaces, each
>> containing partial results, you have "many worlds", but every time you
>> discard or merge some of these atomspaces back into one, its a "collapse".
>> That includes some of the TV merge rules that plague the system.
>>
>> Next, I plan to convert this email into a blog post.
>>
>> --linas
>>
>>
>> On Wed, Aug 31, 2016 at 1:05 AM, Ben Goertzel  wrote:
>>>
>>> Regarding link parses and possible worlds...
>>>
>>> In the TTR paper they point out that "possible worlds" is somehow
>>> conceptually misleading terminology, and it may often be better to
>>> think about "possible situations" (in a deep sense each possible
>>> situation is some distribution over possible worlds, but it may rarely
>>> be necessary to go that far)
>>>
>>> In that sense, we can perhaps view the type of a link parse as a
>>> dependent type, that depends upon the situation ... (?)
>>>
>>> This is basically the same as viewing the link-parser itself as a
>>> function that takes (sentence, dictionary) pairs into functions that
>>> map situations into sets of link-parse-links  [but the latter is a
>>> more boring and obvious way of saying it ;p]
>>>
>>> But again, I don't (yet) see why linear logic would be required
>>> here... it seems to me something like TTR with  truth values is
>>> good enough, and we can handle resource management on the "Occam's
>>> razor" level
>>>
>>> As you already know (but others may not have thought about), weighting
>>> possible link parses via their probabilities based on a background
>>> corpus, is itself a form of "resource usage based Occam's razor
>>> weighting".   Because the links and link-combinations with higher
>>> probability based on the corpus, are the ones that the OpenCog system
>>> doing the parsing has more reason to retain in the Atomspace --- thus
>>> for higher-weighted links or link-combinations, the "marginal memory
>>> usage" required to keep those links/link-combinations in memory is
>>> less.  So we can view the probability weighting of a potential parse
>>> as proportional to the memory-utilization-cost of that parse, in the
>>> context of a system with a long-term memory full of other parses from
>>> some corpus (or some body of embodied linguistic experience,
>>> whatever...).
>>>
>>> Currently it seems to me that the probabilistic weighting of parses
>>> (corresponding to possible situations) is already handling
>>> resource-management implicitly and we don't need linear logic to do
>>> that 

Re: [opencog-dev] Re: [Link Grammar] Re: probabilistic type theory with records ... variants of categorial grammar & semantics, etc.

[Ben Goertzel]

Hmm, but the rules of a system like PLN are just predicate logic
formulas themselves, so "reasoning about reasoning" is formally a
sub-case of good old reasoning

The semantics is different for "reasoning about reasoning" ... but if
one is using a sufficiently rich probabilistic logic for reasoning,
then one is a fortiori doing probabilistic-reasoning-about-reasoning,
right? ... which (if one uses  truth values) is richer than
intuitionistic reasoning-about-reasoning, and inclusive of the
former...

I agree we are talking past each other in some way or another
though...  Sometimes email is not optimal.  If will be fun to take
this up F2F sometime, ideally after I've taken a day or so to review
the relevant  math, which exists in my brain at varying levels of
recollection and fuzziness just now...




On Fri, Sep 2, 2016 at 4:18 AM, Linas Vepstas  wrote:
> Hi Ben,
>
> On Thu, Sep 1, 2016 at 12:09 PM, Ben Goertzel  wrote:
>>
>>
>> About Kripke frames etc. --- as I recall that was a model of the
>> semantics of modal logic with a Possibly operator as well as a
>> Necessarily operator   But in PLN we have a richer notion of
>> possibility than in a standard modal logic,
>
>
> Hey, I'm guessing that you're tired from travel, as here you repeat the same
> confusion from before. There is a difference between "reasoning" (which is
> what PLN does) and "reasoning about reasoning" (which is what I am talking
> about).
>
> What I am talking about applies to any rule-based system whatsoever, its not
> specific to PLN. As long as you keep going back to PLN, you will have
> trouble figuring out what I'm saying.   This is why I keep trying to create
> non-PLN examples. But every time I create a non-PLN example, you zip back to
> PLN, and that misses the point of it all.
>
> -- linas
>
>>
>>
>>
>> On Thu, Sep 1, 2016 at 6:36 AM, Linas Vepstas 
>> wrote:
>> > And so here is the blog post -- its a lightly reformatted version of
>> > this
>> > email, with lots of links to wikipedia and a few papers.
>> >
>> >
>> > http://blog.opencog.org/2016/08/31/many-worlds-reasoning-about-reasoning/
>> >
>> > I really really hope that this clarifies something that is often seen as
>> > mysterious.
>> >
>> > --linas
>>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/CAHrUA340RO1zNghUpNsB5ij3m%3Dq2hxGdW_xZfFsGXC4JW9EpMQ%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdw16NP3qXob3ufu3z9FWDEmMXpbK96uvhBucakcK6ANg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: [Link Grammar] Re: probabilistic type theory with records ... variants of categorial grammar & semantics, etc.

[Ben Goertzel]

Linas,

On Sat, Sep 3, 2016 at 10:50 AM, Linas Vepstas  wrote:
> Today, by default, with the way the chainers are designed, the various
> different atomspaces are *always* merged back together again (into one
> single, global atomspace), and you are inventing things like "distributional
> TV" to control how that merge is done.
>
> I am trying to point out that there is another possibility: one could, if
> desired, maintain many distinct atomspaces, and only sometimes merge them.
> So, for just a moment, just pretend you actually did want to do that.  How
> could it actually be done?  Because doing it in the "naive" way is not
> practical.  Well, there are several ways of doing this more efficiently.
> One way is to create a new TV, which stores the pairs (atomspace-id,
> simple-TV)  Then, if you wanted to merge two of these "abstract" atomspaces
> into one, you could just *erase* the atomspace-id.  Just as easy as that --
> erase some info. You could even take two different (atomspace-id, simple-TV)
> pairs and mash them into one distributional TV.

I note that we used to have something essentially equivalent to this,
for basically this same reason.

It was called CompositeTruthValue, and was a truth value object that
contained mutliple truth values, indexed by a certain ID.The ID
was a version-ID not an atomspace-ID, but same difference...

A dude named Linas Vepstas got rid of this mechanism, because he
(probably correctly) felt it was a poor software design ;)

The replacement methodology is to use EmbeddedTruthValueLink and
ContextAnchorNode , as in the example

Evaluation
  PredicateNode "thinks"
  ConceptNode "Bob"
  ContextAnchorNode "123"

EmbeddedTruthValueLink <0>
  ContextAnchorNode "123"
  Inheritance Ben sane

which uses more memory but does not complicate the core code so much...

-- Ben




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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBemuyPOSGtqr6hedCJ%2Bm3mo9fGpP%2BJ_a5zNnKa8rqciOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: [Link Grammar] Re: probabilistic type theory with records ... variants of categorial grammar & semantics, etc.

[Ben Goertzel]

On Sat, Sep 3, 2016 at 9:59 AM, Linas Vepstas  wrote:
> Hi Nil,
>
>>
>>>
>>> These same ideas should generalize to PLN:  although PLN is itself a
>>> probabilistic logic, and I do not advocate changing that, the actual
>>> chaining process, the proof process of arriving at conclusions in PLN,
>>> cannot be, must not be.
>>>
>>> I hope the above pins down the source of confusion, when we talk about
>>> these things.  The logic happening at the proof level, the ludics level,
>>> is very different from the structures representing real-world knowledge.
>>
>>
>> Oh, it's a lot clearer then! But in the case of PLN inference control we
>> want to use meta-learning anyway, not "hacks" (sorry if I upset certain)
>> like linear logic or intuitionistic logic.
>
>
> Well, hey, that is like saying that 2+2=4 is a hack --
>
> The ideas that I am trying to describe are significantly older than PLN, and
> PLN is not some magical potion that somehow is not bound by the rules of
> reality, that can in some supernatural way violate the laws of mathematics.

Hmm, no, but forms of logic with a Possibly operator are kinda crude
-- they basically lump all non-crisp truth values into a single
category, which is not really the most useful thing to do in most
cases...

Intuitionistic is indeed much older than probabilistic logic; but my
feeling is it is largely superseded by probabilistic logic in terms of
practical utility and relevance...

It's a fair theoretical point, though, that a lot of the nice theory
associated with intuitionistic logic could be generalized and ported
to probabilistic logic -- and much of this mathematical/philosophical
work has not been done...

As for linear logic, I'm still less clear on the relevance.   It is
clear to me that integrating resource-awareness into the inference
process is important, but unclear to me that linear logic or affine
logic are good ways to do this in a probabilistic context.   It may be
that deep integration of probabilistic truth values provides better
and different ways to incorporate resource-awareness...

As for "reasoning about reasoning", it's unclear to me that this
requires special treatment in terms of practicalities of inference
software   Depending on one's semantic formalism, it may or may
not require special treatment in terms of the formal semantics of
reasoning  It seems to me that part of the elegance of dependent
types is that one can suck meta-reasoning cleanly into the same
formalism as reasoning.   This can also be done using type-free
domains (Dana Scott's old work, etc.)   But then there are other
formalisms where meta-reasoning and base-level reasoning are
formalized quite differently...

-- Ben

-- 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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBf5o6Yau1GGFw9%2B9ppYzV2M9rMqOrU7wNrhMdWoYdsaMA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: [Link Grammar] Re: probabilistic type theory with records ... variants of categorial grammar & semantics, etc.

[Ben Goertzel]

Hmm, I don't feel like I'm brushing you off.   I'm actually trying to
understand why you think linear or affine logic is needed --- I don't
get why, I suspect you have some intuition or knowledge here that I'm
not grokking, and I'd honestly love more
clarification/elaboration/explanation from you...

About ContextLink / CompositeTruthValue -- an interesting relevant
question is whether we want/need to use it in the PLN backward chainer
which Nil is now re-implementing  Quite possibly we do...



On Sat, Sep 3, 2016 at 12:11 PM, Linas Vepstas  wrote:
> Yes. I am starting to get very annoyed. Whenever I talk about
> CompositeTruthValue, which I did earlier, I get the big brushoff. Now, when
> I finally was able to sneak it back into the conversation, I once again get
> the big brushoff.
>
> I am starting to get really angry about this. I am spending wayyy too much
> time writing these emails, and all I get is blank stares and the occasional
> snide remark back.  This is just not that complicated, but as long as you do
> not bother to apply your considerable brainpower to all of this, the
> conversation is utterly completely stalled.
>
> I'm pretty angry right now.
>
> --linas
>
>
> On Fri, Sep 2, 2016 at 10:44 PM, Ben Goertzel  wrote:
>>
>> Linas,
>>
>> On Sat, Sep 3, 2016 at 10:50 AM, Linas Vepstas 
>> wrote:
>> > Today, by default, with the way the chainers are designed, the various
>> > different atomspaces are *always* merged back together again (into one
>> > single, global atomspace), and you are inventing things like
>> > "distributional
>> > TV" to control how that merge is done.
>> >
>> > I am trying to point out that there is another possibility: one could,
>> > if
>> > desired, maintain many distinct atomspaces, and only sometimes merge
>> > them.
>> > So, for just a moment, just pretend you actually did want to do that.
>> > How
>> > could it actually be done?  Because doing it in the "naive" way is not
>> > practical.  Well, there are several ways of doing this more efficiently.
>> > One way is to create a new TV, which stores the pairs (atomspace-id,
>> > simple-TV)  Then, if you wanted to merge two of these "abstract"
>> > atomspaces
>> > into one, you could just *erase* the atomspace-id.  Just as easy as that
>> > --
>> > erase some info. You could even take two different (atomspace-id,
>> > simple-TV)
>> > pairs and mash them into one distributional TV.
>>
>> I note that we used to have something essentially equivalent to this,
>> for basically this same reason.
>>
>> It was called CompositeTruthValue, and was a truth value object that
>> contained mutliple truth values, indexed by a certain ID.The ID
>> was a version-ID not an atomspace-ID, but same difference...
>>
>> A dude named Linas Vepstas got rid of this mechanism, because he
>> (probably correctly) felt it was a poor software design ;)
>>
>> The replacement methodology is to use EmbeddedTruthValueLink and
>> ContextAnchorNode , as in the example
>>
>> Evaluation
>>   PredicateNode "thinks"
>>   ConceptNode "Bob"
>>   ContextAnchorNode "123"
>>
>> EmbeddedTruthValueLink <0>
>>   ContextAnchorNode "123"
>>   Inheritance Ben sane
>>
>> which uses more memory but does not complicate the core code so much...
>>
>> -- Ben
>>
>>
>>
>>
>> --
>> Ben Goertzel, PhD
>> http://goertzel.org
>>
>> Super-benevolent super-intelligence is the thought the Global Brain is
>> currently struggling to form...
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "link-grammar" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to link-grammar+unsubscr...@googlegroups.com.
>> To post to this group, send email to link-gram...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/link-grammar.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "link-grammar" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to link-grammar+unsubscr...@googlegroups.com.
> To post to this group, send email to link-gram...@googlegroups.com.
> Visit this group at https://groups.google.com/group/link-grammar.
>
> For

Re: [opencog-dev] Re: [Link Grammar] Re: probabilistic type theory with records ... variants of categorial grammar & semantics, etc.

[Ben Goertzel]

hey... yes it's true that I have a shitload of less interesting things
to do this weekend, so I'm not reflecting on this stuff at great depth
at the moment... but I did spent some time reviewing papers on types
and categories and logic last week while flying around ...

Perhaps a useful way to move this discussion in a productive direction
would be to focus on some particular example or small set of examples?
  Some of these things we're discussing are not going to be
practically relevant in OpenCog for a while, but some of them might be
important for Nil's near-future work on backward chaining and
inference control...

What I'm thinking is to posit a specific example of a real-world
situation and corresponding reasoning problem and then write down how
it would be formulated using

-- classical logic
-- intuitionistic logic
-- PLN

and then identify a corresponding "reasoning about reasoning" problem
and write down how ti would be formulated in these various ways... and
see how the semantics can be formalized or otherwise expressed in each
case...

Regarding inference control, I could then use said example as an
illustration of my prior suggestion regarding
probabilistic-programming-based inference control... and perhaps you
could use it to explain how you think linear or affine logic can be
useful for inference control?

I could come up with an example or two myself but I'm afraid I might
come up with one that doesn't fully illustrate the points you're
trying to make...

Going through this stuff in detail in the context of some specific
example might help un-confuse others besides you, me and Nil who are
listening into this thread as well...

This is not urgent but could be interesting...

ben


On Sat, Sep 3, 2016 at 12:17 PM, Linas Vepstas  wrote:
> GOD DAMN IT BEN
>
> Stop writing these ninny emails, and start thinking about what the hell is
> going on.  I've explained this six ways from Sunday, and I get the
> impression that you are just skimming everything I write, and not bothering
> to read it, much less think about it.
>
> I know you are really really smart, and I know you can understand this
> stuff, (cause its really not that hard)  but you are simply not making the
> effort to do so.  You are probably overwhelmed with other work -- OK --
> great -- so we can maybe follow up on this later on. But reading your
> responses is just plain highly unproductive, and just doesn't lead anywhere.
> Its not interesting, its not constructive, it doesn't solve any of the
> current problems in front of us.
>
> --linas
>
> On Fri, Sep 2, 2016 at 10:50 PM, Ben Goertzel  wrote:
>>
>> On Sat, Sep 3, 2016 at 9:59 AM, Linas Vepstas 
>> wrote:
>> > Hi Nil,
>> >
>> >>
>> >>>
>> >>> These same ideas should generalize to PLN:  although PLN is itself a
>> >>> probabilistic logic, and I do not advocate changing that, the actual
>> >>> chaining process, the proof process of arriving at conclusions in PLN,
>> >>> cannot be, must not be.
>> >>>
>> >>> I hope the above pins down the source of confusion, when we talk about
>> >>> these things.  The logic happening at the proof level, the ludics
>> >>> level,
>> >>> is very different from the structures representing real-world
>> >>> knowledge.
>> >>
>> >>
>> >> Oh, it's a lot clearer then! But in the case of PLN inference control
>> >> we
>> >> want to use meta-learning anyway, not "hacks" (sorry if I upset
>> >> certain)
>> >> like linear logic or intuitionistic logic.
>> >
>> >
>> > Well, hey, that is like saying that 2+2=4 is a hack --
>> >
>> > The ideas that I am trying to describe are significantly older than PLN,
>> > and
>> > PLN is not some magical potion that somehow is not bound by the rules of
>> > reality, that can in some supernatural way violate the laws of
>> > mathematics.
>>
>> Hmm, no, but forms of logic with a Possibly operator are kinda crude
>> -- they basically lump all non-crisp truth values into a single
>> category, which is not really the most useful thing to do in most
>> cases...
>>
>> Intuitionistic is indeed much older than probabilistic logic; but my
>> feeling is it is largely superseded by probabilistic logic in terms of
>> practical utility and relevance...
>>
>> It's a fair theoretical point, though, that a lot of the nice theory
>> associated with intuitionistic logic could be generalized and ported
>> to probabilistic logic -- and much of this mathema

Re: [opencog-dev] Re: [Link Grammar] Re: probabilistic type theory with records ... variants of categorial grammar & semantics, etc.

[Ben Goertzel]

I will read your message carefully tonight or sometime in the next few
days when I'm not in a hurry...

But I will respond to this one point first, hoping to spur you on to
provide more detail on your thinking...

On Sat, Sep 3, 2016 at 1:24 PM, Linas Vepstas  wrote:
> Backward and forward chaining are very crude, very primitive tools. Far
> superior algorithms have been invented. I'm quite sure that we can do a lot
> lot better than merely backward/forward chaining in PLN.  But we can't get
> there until we start talking at the correct level of abstraction.

I do agree on that point.

The previous implementation of the backward chainer (by William Ma)
fell apart because of some "plumbing" related to lambdas and
variables   Nil's re-implementation will get that plumbing right.
But even with correct variable-management plumbing, yeah, forward and
backward chaining are extremely crude mechanisms that are not
sufficient for AGI in themselves...

I wonder if you would like to try to spell out in slightly more detail
one of the alternatives you are thinking of, though  This would be
potentially relevant to Nil's work during the next couple months...

You have mentioned Viterbi and forward-backward algorithms before, and
I understand how those work for standard belief propagation in Bayes
nets and Markov chains etc., but I don't yet see how to apply that
idea in a general logic context tractably  Of course one can
alternate btw forward and backward steps, or do them concurrently, but
that's not really what you're getting at...

Probably the point in the above paragraph ties in with the
probabilistic-programming stuff I wrote about and linked to before,
but I haven't figured out exactly how yet...

Anyway I gotta leave the computer and take my f**king broken car to
the shop now, but I will read this stuff and reflect on it with more
care sometime in the next few days when the time emerges...

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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdRe%2BAbB4PFcZGBNTUE1XK%3DEvyXNCQ%3DeXWPSWK-8HxmRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: [Link Grammar] Re: probabilistic type theory with records ... variants of categorial grammar & semantics, etc.

[Ben Goertzel]

ily accurate regarding different situations, to different
degrees….)

 In some cases there will be contradictory interpretations that cannot
(or are very unlikely to) both be accurate.   In this case, if we
don’t have enough evidence to distinguish, we may want to keep both
around in the Atomspace, wrapped in different contexts.   For
instance, we may do this with multiple parses of a sentence and their
ensuing logical interpretations.  Or, in PLN, the Rule of Choice
specifies that we should do this if we have two very different
estimates of the truth value of the same Atom (keep them separate
rather than merge them via some sort of weighted average).



FORWARD AND BACKWARD CHAINING, ITERATED GOAL-ORIENTED PROBABILISTIC
OBJECT/TRANSFORMATION CHOICE, WHAT ELSE?

 Forward and backward chaining are clearly somewhat crude control
mechanisms; however, they are what are standardly used in
theorem-provers.   It’s not clear what great alternatives exist in a
general setting.

 However, one alternative suggested by the above “meta-learning”
approach to inference control is to just use sampling based on the
specified distributions p(A,G) and p(T,G).If the transformations
involved include both e.g. forward and backward applications of PLN
logic rules, then this sort of sampling approach is going to combine
“forward and backward chains” in a manner guided by the distributions.
When the most likely-looking inference steps are forward, the process
will do forward chaining a while.  When the most likely-looking
inference steps are backward, the process will do backward chaining a
while.  Sometimes it will mix up forward and backward steps freely.

On Sat, Sep 3, 2016 at 1:58 PM, Ben Goertzel  wrote:
> I will read your message carefully tonight or sometime in the next few
> days when I'm not in a hurry...
>
> But I will respond to this one point first, hoping to spur you on to
> provide more detail on your thinking...
>
> On Sat, Sep 3, 2016 at 1:24 PM, Linas Vepstas  wrote:
>> Backward and forward chaining are very crude, very primitive tools. Far
>> superior algorithms have been invented. I'm quite sure that we can do a lot
>> lot better than merely backward/forward chaining in PLN.  But we can't get
>> there until we start talking at the correct level of abstraction.
>
> I do agree on that point.
>
> The previous implementation of the backward chainer (by William Ma)
> fell apart because of some "plumbing" related to lambdas and
> variables   Nil's re-implementation will get that plumbing right.
> But even with correct variable-management plumbing, yeah, forward and
> backward chaining are extremely crude mechanisms that are not
> sufficient for AGI in themselves...
>
> I wonder if you would like to try to spell out in slightly more detail
> one of the alternatives you are thinking of, though  This would be
> potentially relevant to Nil's work during the next couple months...
>
> You have mentioned Viterbi and forward-backward algorithms before, and
> I understand how those work for standard belief propagation in Bayes
> nets and Markov chains etc., but I don't yet see how to apply that
> idea in a general logic context tractably  Of course one can
> alternate btw forward and backward steps, or do them concurrently, but
> that's not really what you're getting at...
>
> Probably the point in the above paragraph ties in with the
> probabilistic-programming stuff I wrote about and linked to before,
> but I haven't figured out exactly how yet...
>
> Anyway I gotta leave the computer and take my f**king broken car to
> the shop now, but I will read this stuff and reflect on it with more
> care sometime in the next few days when the time emerges...
>
> ben



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdtbLCmQUzqHtJ1g0rfd_Rbhtuij3xx5ObFAoBF1-1OTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: [Link Grammar] Re: probabilistic type theory with records ... variants of categorial grammar & semantics, etc.

[Ben Goertzel]

> MAPPING SYNTAX TO LOGIC
>
>  "RelEx + RelEx2Logic” maps syntactic structures into logical
> structures.   It takes in structures that care about left vs. right,
> and outputs symmetric structures that don’t care about left vs. right.
>   The output of this semantic mapping framework, given a sentence, can
> be viewed as a set of type judgments, i.e. a set of assignations of
> terms to types.(Categorially, assigning term t to type T
> corresponds to an arrow “t \circ ! : Gamma ---> T” where ! is an arrow
> pointing to the unit of the category and Gamma is the set of type
> definitions of the typed lambda calculus in question, and \circ is
> function composition) .

One philosophically nice observation here is: Frege's "principle of
compositionality" here corresponds to the observation that there is a
morphism from the asymmetric monoidal category corresponding to link
grammar, into the symmetric locally cartesian closed category
corresponding to lambda calculus w/ dependent types...

This principle basically says that you can get the meaning of the
whole by combining the meaning of the parts, in language...

The case of "Every man who has a donkey, beats it" illustrates that in
order to get compositionality for weird sentences like this, you
basically want to have dependent types in your lambda calculus at the
logic end of your mapping...

-- 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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBeG7g9VCWqr_wDp_WsW3bNoNseazL%3D0pXRqSyBqjoMgjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: [Link Grammar] Re: probabilistic type theory with records ... variants of categorial grammar & semantics, etc.

[Ben Goertzel]

o deep structures
that parallel syntactic structure, are likely to be more easily
learned using probabilistic reasoning  So one would expect surface
syntax to emerge via multiple constraints include

-- ease of tweakability into deep structures that parallel semantic structure

-- ease of comprehension and production of surface structure

I believe Jackendoff made this latter point a few times...

-- Ben




On Sat, Sep 3, 2016 at 10:13 PM, Ben Goertzel  wrote:
>> MAPPING SYNTAX TO LOGIC
>>
>>  "RelEx + RelEx2Logic” maps syntactic structures into logical
>> structures.   It takes in structures that care about left vs. right,
>> and outputs symmetric structures that don’t care about left vs. right.
>>   The output of this semantic mapping framework, given a sentence, can
>> be viewed as a set of type judgments, i.e. a set of assignations of
>> terms to types.(Categorially, assigning term t to type T
>> corresponds to an arrow “t \circ ! : Gamma ---> T” where ! is an arrow
>> pointing to the unit of the category and Gamma is the set of type
>> definitions of the typed lambda calculus in question, and \circ is
>> function composition) .
>
> One philosophically nice observation here is: Frege's "principle of
> compositionality" here corresponds to the observation that there is a
> morphism from the asymmetric monoidal category corresponding to link
> grammar, into the symmetric locally cartesian closed category
> corresponding to lambda calculus w/ dependent types...
>
> This principle basically says that you can get the meaning of the
> whole by combining the meaning of the parts, in language...
>
> The case of "Every man who has a donkey, beats it" illustrates that in
> order to get compositionality for weird sentences like this, you
> basically want to have dependent types in your lambda calculus at the
> logic end of your mapping...
>
> -- Ben



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBeiYW9cqG_gBSXyeQWb_JL7Np5QT6y5YaP-ueQdq%2B6LBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Fwd: [open-nars] credit assignment

[Ben Goertzel]

It would be Interesting to compare PLN with NARS on these simple credit
assignment ish examples
-- Forwarded message --
From: "Pei Wang" 
Date: Sep 5, 2016 2:59 AM
Subject: [open-nars] credit assignment
To: "open-nars" 
Cc:

In AI, "credit assignment" is the problem of distributing the overall
credit (or blame) to the involved steps. Back-prop in ANN is for a similar
problem -- to adjust the weights on a path to get a desired overall result.
I'm trying to use a simple example to should how it is handled in NARS.

Here is the situation: from  b>,  c>, and  d>, the system
derives  d> (as well as some other conclusions). If now the system is
informed that  d> is false, it will surely change its belief on this
statement. Now the problem is: how much it should change its beliefs on  b>,  c>, and  d>, and in what process?

In the attached text file, I worked out the example step by step, using the
default truth-value for the inputs. In the attached spreadsheet, the whole
process is coded, so you can change the input values (in green) to see how
the other values are changed accordingly. In particular, you should try (1)
giving different confidence values to  b>,  c>, and  d>,
and (2) giving confirming observation on  d>.

In the spreadsheet, there are two places where a conclusion can be derived
in two different paths and the truth-values may be different. I have both
results listed, and in the system the choice rule will pick the one that
has a higher confidence.

This example can be extended into more than three steps. One interesting
result is that the beliefs at the ends ( b> and  d>) are
adjusted more than the ones in the middle ( c>), which I think can be
justified.

This result can be used in comparing NARS with other models, such as deep
learning or non-classic logic systems (non-monotonic, para-consistent,
probabilistic, etc.).

Comments, issues, and additions?

Regards,

Pei

-- 
You received this message because you are subscribed to the Google Groups
"open-nars" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to open-nars+unsubscr...@googlegroups.com.
To post to this group, send email to open-n...@googlegroups.com.
Visit this group at https://groups.google.com/group/open-nars.
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBe2ghAOnMXAqO7pckGFVpf5FEh-b%2B5rcPqPEgAN0QgasQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

// 1: input
 b>. {1}

// 2: input
 c>. {2}

// 3: input
 d>. {3}

// 4: from 1+2
 c>. %1.00;0.81% {1,2}

// 5: from 2+3
 d>. %1.00;0.81% {2,3}

// 6: from 3+4
 d>. %1.00;0.73% {1,2,3}

// 7: from 1+5
 d>. %1.00;0.73% {1,2,3}

// 8: input 
 d>. %0% {4}

// 9: from 6+8 or 7+8
 d>. %0.23;0.92% {1,2,3,4}

// 10: from 1+8
 d>. %0.00;0.45% {1,4}

// 11: from 5+10
 d>. %0.84;0.84% {1,2,3,4}

// 12: from 3+8
 c>. %0.00;0.45% {3,4}

// 13: from 4+12
 c>. %0.84;0.84% {1,2,3,4}

// 14: from 4+8
 d>. %0.00;0.42% {1,2,4}

// 15: from 3+14
 d>. %0.92;0.91% {1,2,3,4}

// 16: from 5+8
 b>. %0.00;0.42% {1,2,4}

// 17: from 1+16
 b>. %0.92;0.91% {1,2,3,4}

// 18: from 3+10
 c>. %0.00;0.29% {1,3,4}

// 19: from 2+18
 c>. %0.96;0.904% {1,2,3,4}

// 20: from 1+12
 c>. %0.00;0.29% {1,3,4}

// 21: from 2+20
 c>. %0.96;0.904% {1,2,3,4}



revision-example.xlsx
Description: MS-Excel 2007 spreadsheet

Re: [opencog-dev] OpenCog and Concept Search

[Ben Goertzel]

It's certainly possible to use OpenCog at a platform and toolset for
creating a concept search engine...   I sorta feel like the ways of
doing so fall into two categories though...

1) ways that, while they can be done inside Opencog, could be done
more easily outside OpenCog

2) ways that are quite hard, though very interesting, because they
require implementing some custom inference control heuristics for
guiding PLN backward chaining as it estimates semantic similarity
between phrases (based on the background knowledge loaded into the
Atomspace)

...

I.e. if you just want to build links between words, and cluster words
based on their similarities, etc. then OpenCog can be used as a
framework, but may not add that much value.  But if you want to
extract meanings from phrases and then deal with the subtletly of
estimating similarity between the semantic structures corresponding to
phrases, then OpenCog does potentially add huge value, but it's not a
trivial road to follow..

-- Ben



On Sat, Sep 10, 2016 at 4:01 PM, Amirouche Boubekki
 wrote:
> Héllo,
>
> I am looking to build a concept search engine. I want to know if there is
> prior work done using
> opencog in particular or similar approaches that could help in this task.
> And more generaly is there work done in the field of text mining using
> opencog.
>
> Do you know any papers in the field of text retrieval and text mining that I
> could use to help me in this task? I mostly interested in approaches that
> apply to opencog, but could be interested in other approaches.
>
> Do you think concept search could be implemented in opencog? What are the
> relevant part of
> opencog I should have a look at?
>
> Best regards,
>
>
> Amirouche
>
>
> PS: If you interested in search engines and text retrieval, you might be
> interested by a recent dump of hackernews I've done using the new HN API. I
> extracted urls which have a score of at least 3. It's around 500k urls of
> mostly computer science related articles:
> http://hyperdev.fr/data/hn/hn.urls.txt.xz (8 MB)
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/9752b39d-0cb0-4f35-82eb-4babb0a145ba%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBfu%3DYqC-6QzVc8jqTvDkzSkf2EEN%2B9j8mGcPN_yoHZ2Jg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: opencog with crawled data

[Ben Goertzel]

You probably want to run a bunch of sentences through the full NLP
pipeline, including Relex and R2L, and then do pattern mining on the
set of logical-semantic patterns that result...



On Sat, Sep 10, 2016 at 10:36 AM, Linas Vepstas  wrote:
> Hi,
>
> On Wed, Sep 7, 2016 at 4:57 AM,  wrote:
>>
>>
>> I think, i should do the following (?!)
>>
>> write probably a python script that produces the following output for
>> every json file:
>>
>> (EvaluationLink
>> (PredicateNode "sentence, location and body")
>> (ListLink
>>  (SentenceNode "an unique string ")
>>  (EvaluationLink
>>  (PredicateNode " coordinates, country, continent, body")
>>  (ListLink
>> (ConceptNode "-86.3222")
>> (ConceptNode  "32.3934")
>> (ConceptNode  "US" )
>> (ConceptNode  "northamerica")
>>  (ConceptNode  ".we need a new channel trump
>>tv!!.)
>>   .
>>   .
>>   . )))
>>
>>
>> Then i can give this to pattern miner.
>>
>> Am i missing anything here?
>
>
> Well, the pattern miner won't perform any parsing of the sentences for you,
> so the most likely thing it will do is find that there's lots of things with
> (ConceptNode  "US" ) in them, and that this is highly correlated with
> (ConceptNode  "northamerica")  After that, it might find patterns in the
> lat/log.  It does NOT do any string compares of the names of any nodes.
>
> Unless you put at least WordNodes in there, you will get no text analysis.
>
> --linas
>
>>
>>
>>
>> Thanks in advance.
>>
>>
>>
>> On Tuesday, September 6, 2016 at 4:05:43 PM UTC+2, vishnup...@gmail.com
>> wrote:
>>>
>>> Hello all,
>>>
>>>>> I have attached a small example Json file, which is generated from
>>>>> twitter stream. I will be getting lots of Json chunks like this. How can i
>>>>> give this to pattern miner. i.e. can i convert it to hypergraph? What are
>>>>> the steps involved?. what would be the best way to start with.
>>>>
>>>> Any guidelines would be very much helpful.
>>>
>>>
>>> Thanks in advance
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/CAHrUA35xEmMUgKyYVPqOufs-0LucDNCuNsoTmpGWgsrg29CcNg%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdaV2YN1txVweKPAFrcO98C0Dxh5odryeg7iK_foHXv1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Fringe of consciousness, importance spreading

[Ben Goertzel]

A somewhat interesting point came up in discussions w/ Misgana re ECAN today...

So far we have been working on two methods of attention allocation:

-- spreading importance from everything in the AttentionalFocus, frequently

-- spreading importance from everything in the Atomspace, but more
slowly (by sampling Atoms from the Atomspace with probability
proportional to STI, and then spreading from each Atom as it's
sampled)

But we have seen a need now for a third method

-- iterating through every X in the AttentionalFocus, and spreading
importance K links out from X (where, say, K=2 or 3)

The practical use-case that made this requirement clear was: rapidly
boosting the importance of question-answers, that contain words which
are in the AF  The question-answers are ImplicationLinks, which
point to ListLinks, which point to words ... so to get STI to the
ImplicationLink, a word in the AF needs to send STI to the ListLink
which then needs to send STI to the ImplicationLink...

But more generally one can view this as an importance-spreading agent
aimed at spreading activity from the AttentionalFocus to the "Fringe"
of consciousness -- those things that one can feel at the back of
one's mind, on the edge of one's consciousness ... one is aware they
are there but not quite aware of what they are, but one can generally
with effort pull them into one's awareness...

Sometimes spreading enough STI into the Fringe will cause something in
the Fringe to get boosted into the AttentionalFocus 

-- Ben

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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdGNipWfnguuZY%2ByyGtnCxAKoXfqoTiYMSsGcqj0rQ5Mw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Fringe of consciousness, importance spreading

[Ben Goertzel]

On Tue, Sep 13, 2016 at 12:49 AM, Roman Treutlein  wrote:
> Do you just spread it from your Source to it's Targets and then use these
> Targets as a new source?


yah, that was my thinking... not too fancy but I don't see what else to do...



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBenw8R7dthjXzgmbtKBMg861oA%2BqyHn1VJVbxYsuiU9pg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Fringe of consciousness, importance spreading

[Ben Goertzel]

> Rather than introduce a new third method, it seems to me that we could simply 
> replace the spreading of importance from everything in the AF with the 
> spreading of importance K links out, where the value of K might be determined 
> from context.


I just worry that would result in the internal AF STI-spreading
happening too slowly, thus screwing up attractor-formation dynamics
inside the AF ...

After all, spreading 3 links out from X may take 100x or 1000x or 10Kx
more effort than spreading only from X, right?



>The “third method” really just seems to me to be a generalized version of AF 
>spreading rather than a new method. As Roman points out, the actual mechanics 
>of how to spread K links out also needs to be determined.
>
> —matt
>
>> On Sep 12, 2016, at 10:01 AM, Ben Goertzel  wrote:
>>
>> A somewhat interesting point came up in discussions w/ Misgana re ECAN 
>> today...
>>
>> So far we have been working on two methods of attention allocation:
>>
>> -- spreading importance from everything in the AttentionalFocus, frequently
>>
>> -- spreading importance from everything in the Atomspace, but more
>> slowly (by sampling Atoms from the Atomspace with probability
>> proportional to STI, and then spreading from each Atom as it's
>> sampled)
>>
>> But we have seen a need now for a third method
>>
>> -- iterating through every X in the AttentionalFocus, and spreading
>> importance K links out from X (where, say, K=2 or 3)
>>
>> The practical use-case that made this requirement clear was: rapidly
>> boosting the importance of question-answers, that contain words which
>> are in the AF  The question-answers are ImplicationLinks, which
>> point to ListLinks, which point to words ... so to get STI to the
>> ImplicationLink, a word in the AF needs to send STI to the ListLink
>> which then needs to send STI to the ImplicationLink...
>>
>> But more generally one can view this as an importance-spreading agent
>> aimed at spreading activity from the AttentionalFocus to the "Fringe"
>> of consciousness -- those things that one can feel at the back of
>> one's mind, on the edge of one's consciousness ... one is aware they
>> are there but not quite aware of what they are, but one can generally
>> with effort pull them into one's awareness...
>>
>> Sometimes spreading enough STI into the Fringe will cause something in
>> the Fringe to get boosted into the AttentionalFocus 
>>
>> -- Ben
>>
>> --
>> Ben Goertzel, PhD
>> http://goertzel.org
>>
>> Super-benevolent super-intelligence is the thought the Global Brain is
>> currently struggling to form...
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To post to this group, send email to opencog@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/CACYTDBdGNipWfnguuZY%2ByyGtnCxAKoXfqoTiYMSsGcqj0rQ5Mw%40mail.gmail.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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/1F463D95-D0D5-4B95-9D4D-092C0EEFDDFC%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBepQVSPMh__wu%2BR2yUjQmCT6ofUr0enxcJttGM0Xbamzg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Fringe of consciousness, importance spreading

[Ben Goertzel]

I'm still thinking on this...

I understand that it would be cleaner software design wise not to add
a third agent -- but I am worrying about the dynamics... it seems that
to get the dynamics right inside the AF we want STI to be coursing
around really fast within the AF, and that this will get screwed up if
the AF importance-spreading loop has to wait for spreading from the
fringe which may be a couple orders of magnitude slower than spreading
just from the AF ...



On Tue, Sep 13, 2016 at 2:20 AM, Roman Treutlein  wrote:
> Using this for all AF spreading with a default K of 1 and using a higher K
> with a certain probability. Seems like a cleaner solution then have 2
> different spreading mechanisms for the AF.
>
>
> On Monday, September 12, 2016 at 7:27:50 PM UTC+2, Matthew Ikle wrote:
>>
>> Ahh — I was thinking that the default setting for K would be one but that
>> this would change for specific contexts.
>>
>> On Sep 12, 2016, at 10:59 AM, Ben Goertzel  wrote:
>>
>> Rather than introduce a new third method, it seems to me that we could
>> simply replace the spreading of importance from everything in the AF with
>> the spreading of importance K links out, where the value of K might be
>> determined from context.
>>
>>
>>
>> I just worry that would result in the internal AF STI-spreading
>> happening too slowly, thus screwing up attractor-formation dynamics
>> inside the AF ...
>>
>> After all, spreading 3 links out from X may take 100x or 1000x or 10Kx
>> more effort than spreading only from X, right?
>>
>>
>>
>> The “third method” really just seems to me to be a generalized version of
>> AF spreading rather than a new method. As Roman points out, the actual
>> mechanics of how to spread K links out also needs to be determined.
>>
>> —matt
>>
>> On Sep 12, 2016, at 10:01 AM, Ben Goertzel  wrote:
>>
>> A somewhat interesting point came up in discussions w/ Misgana re ECAN
>> today...
>>
>> So far we have been working on two methods of attention allocation:
>>
>> -- spreading importance from everything in the AttentionalFocus,
>> frequently
>>
>> -- spreading importance from everything in the Atomspace, but more
>> slowly (by sampling Atoms from the Atomspace with probability
>> proportional to STI, and then spreading from each Atom as it's
>> sampled)
>>
>> But we have seen a need now for a third method
>>
>> -- iterating through every X in the AttentionalFocus, and spreading
>> importance K links out from X (where, say, K=2 or 3)
>>
>> The practical use-case that made this requirement clear was: rapidly
>> boosting the importance of question-answers, that contain words which
>> are in the AF  The question-answers are ImplicationLinks, which
>> point to ListLinks, which point to words ... so to get STI to the
>> ImplicationLink, a word in the AF needs to send STI to the ListLink
>> which then needs to send STI to the ImplicationLink...
>>
>> But more generally one can view this as an importance-spreading agent
>> aimed at spreading activity from the AttentionalFocus to the "Fringe"
>> of consciousness -- those things that one can feel at the back of
>> one's mind, on the edge of one's consciousness ... one is aware they
>> are there but not quite aware of what they are, but one can generally
>> with effort pull them into one's awareness...
>>
>> Sometimes spreading enough STI into the Fringe will cause something in
>> the Fringe to get boosted into the AttentionalFocus 
>>
>> -- Ben
>>
>> --
>> Ben Goertzel, PhD
>> http://goertzel.org
>>
>> Super-benevolent super-intelligence is the thought the Global Brain is
>> currently struggling to form...
>>
>> --
>> 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/CACYTDBdGNipWfnguuZY%2ByyGtnCxAKoXfqoTiYMSsGcqj0rQ5Mw%40mail.gmail.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 

Re: [opencog-dev] Re: Embodied Language

[Ben Goertzel]

Thanks Linas!

I know putting together this sort of quality documentation takes a lot
of time and effort; but as you know it's critical for enabling others
to assist with extending your work on this stuff...

My current thinking is that in the next phase we can have concurrent
work on learning-based and hard-coding-based extensions of the current
prototype work.  But let's discuss this in depth once you've completed
the document...

-- Ben


On Fri, Sep 16, 2016 at 12:03 PM, Linas Vepstas  wrote:
>
> On Thu, Sep 15, 2016 at 3:30 AM, AmeBel  wrote:
>>
>> Thanks Linas,
>>
>> that is extremely helpful. Can't wait for 0.03 :-)
>
>
> Here it is!  The centerpiece here is the diagram on page 11, with the
> backing text on pages 9 and 10
>
> Some confusing text on the (new) page 14 was fixed up.
>
> It will be a few more days before I generate the next version. The stuff
> that was mostly easy to write was written, the next parts will take more
> effort.
>
> --linas
>>
>>
>>
>>>>
>>>> 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/7eacea5d-a872-4941-a4de-ba0af793e96e%40googlegroups.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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/CAHrUA34MQdz7u4Gsuj4%2BmpPJj%2BhLu-NVX0gOZ0FrkwxHemNgVg%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBeGBVcpobyG_sjqs-ma-Kj0mOAAKsaoFWJHd%2BAcNvSoOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] OpenCV for preliminary visual processing?

[Ben Goertzel]

sing OpenCV for
>>>> face-tracking webcams attached to servos, and blob isolating security
>>>> cameras if you wanted specific examples to look up.
>>>>
>>>>
>>>> --
>>>> 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+unsubscr...@googlegroups.com.
>>>>
>>>>
>>>> To post to this group, send email to opencog@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/1baaeade-567a-4456-aaa3-85e2b003fc7b%40googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "opencog" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/opencog/31yT3osM_zI/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> opencog+unsubscr...@googlegroups.com.
>>> To post to this group, send email to opencog@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/CAHrUA37v2zxE7nTbqrBtw65k539v_wW1JLX2%3D2jgC3bkDoyqsw%40mail.gmail.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+unsubscr...@googlegroups.com.
>> To post to this group, send email to opencog@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/CABpkOB-4HYkmtoqnBNpWaqdRKwou-w9CPevYOtNDYxGiJL9N%3Dg%40mail.gmail.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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/CAHrUA34J1i2qe-KTOUEZ%2B8gXXWhW1jmUoDWQt2H%3DTY7copfXRw%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBf1qsF21PyHU9V7t_nRPNtyiqn5FMjOtPeyFFrqMBzNhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] OpenCV for preliminary visual processing?

[Ben Goertzel]

Ah, OK, I get it  Yeah, having openCog know the size and color and
direction of blobs would be nice... I'm not quite sure what to do with
it immediately though...

I mean, for the "deep learning vision in OpenCog" direction we're
gonna feed fine-grained visual data (pixels, voxels) into neural nets
wrapped in Grounded SchemaNodes associated with RegionNodes in the
TimeSpaceMap...

OTOH, for hand-coding simple response rules for a robot or avatar
controlled by OpenCog, you kinda need to know what you're seeing not
just that you're seeing a red blob in a certain position, moving
toward a blue blob...

So one could argue that knowing where blobs of various colors are and
where they're moving is

-- too low-level for hand-coding response rules for an opencog agent

-- not low-level enough to fuel deep visual learning in opencog

... but maybe I'm misunderstanding something?

ben

On Sat, Sep 17, 2016 at 11:18 PM, Noah Bliss  wrote:
> The concept of building a 3d map of the environment in atomspace certainly
> would be a better goal of there had to be a choice between the two. I'll
> definitely read up on kinfu before starting any sort of work.
>
> A few simple examples of information gained through a more mature OpenCV
> implementation could consist of the following:
>
> A simple place to start that would have little overhead and export atoms
> easily used could be:
>
> Knowing environment. Consistent items not the focus.
>
> Blob statistics, delimited by motion
> Size of blob
> Color of blob
> Location on fov
> Speed and direction
> Acceleration
>
> Advanced sampling:
> Division of blob into sections, quarters horizontally,
> Shape/size/color/edge flat or rounded statistics of that quadrant
> Vertical division by the same standards.
>
> Obviously this would not be the end. We could divide a blob into more
> slices, account for variation in background, etc. We would need a more
> advanced way to get more information from a visual feed to get it anywhere
> near human-like. But we could at least get more useful data than we
> currently are.
>
> This kind of implementation could potentially augment other more "logical"
> representations of the environment by providing a more analog "eye-like"
> processing system. It also has the advantage of being potentially faster to
> implement and scale.
>
> I don't see this implementation ever being a replacement for any sort of 3d
> map formation, but rather a low-overhead way of quickly making sense of raw
> visual input without pumping raw video into atomspace.
>
>
> On Sat, Sep 17, 2016, 01:06 Ben Goertzel  wrote:
>>
>> Noah,
>>
>> OpenCV, as you know, is basically a toolkit, not an integrated system
>>
>> Right now, indeed, the vision processing we have hooked up to OpenCog
>> is restricted to
>>
>> -- face detection, face tracking, face recognition
>> -- visual saliency identification
>> -- luminance-change detection
>>
>> which is all pretty simple...
>>
>> We have previously experimented with using kinfu to make a 3D map of a
>> robot's surroundings OpenCog's TimeSpaceMap is well-suited to
>> represent the output of kinfu (or similar) in a way that's integrated
>> with the Atomspace...
>>
>> We have also played a bit with Region-CNNs, as a way of identifying
>> what objects are where in a visual scene (initially from a closed
>> class of objects)
>>
>> So if I were going to integrate additional external vision tools with
>> OpenCog, I'd probably start with kinfu-or-similar, plus
>> (Region-CNN-with-trained-models)-or-similar...
>>
>> Medium term, it's more interesting to integrate deep NN vision into
>> OpenCog, which Yenat is working on in our Addis office, but that's a
>> research project, whereas feeding output of kinfu and Region-CNN into
>> OpenCog is "just" complex software integration and training/tuning,
>> not really original research...
>>
>> Anyway I am curious what specific  visual functions you are thinking of
>> adding?
>>
>> -- Ben G
>>
>>
>>
>> On Sat, Sep 17, 2016 at 9:54 AM, Linas Vepstas 
>> wrote:
>> >
>> >
>> > On Fri, Sep 16, 2016 at 8:41 PM, Noah Bliss  wrote:
>> >>
>> >> Thank you for the info Linas,
>> >>
>> >> I'll look at the current code and see if I can get a more complete
>> >> implementation of OpenCV started. You mentioned another dev's overly
>> >> simple
>> >> integration which, while better than nothing, hardly fulfills our g

Re: [opencog-dev] Re: ImplicationLink?

[Ben Goertzel]

st expects. The problem with using
>>> either
>>> ScopeLink or LambdaLink is that it becomes impossible to have a
>>> stable
>>> variable name -- it can be alpha-converted to anything, so any
>>> algo that
>>> depends on having a fixed, well-known variable name will fail.
>>>
>>> In this case -- I am not sure -- if you want ImplicationLink to
>>> be
>>> scoped, then the unit test is wrong.  But is the unit test is
>>> right,
>>> then implication link must not be scoped.  I cannot tell which
>>> one is
>>> wanted.
>>>
>>> --linas
>>>
>>>
>>>
>>> On Tue, Oct 11, 2016 at 12:12 PM, Nil Geisweiller
>>> mailto:ngeis...@googlemail.com>
>>> <mailto:ngeis...@googlemail.com
>>>
>>> <mailto:ngeis...@googlemail.com>>> wrote:
>>>
>>>  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, thus making the
>>> variables in it
>>>  implicitly scoped.  Then you added the file
>>> ImplicationLink.cc,
>>>  and have
>>>  notes in there, complaining about how variables are
>>> implcitly
>>>  scoped.
>>>  The wiki page for it,
>>> http://wiki.opencog.org/w/ImplicationLink
>>> <http://wiki.opencog.org/w/ImplicationLink>
>>>  <http://wiki.opencog.org/w/ImplicationLink
>>> <http://wiki.opencog.org/w/ImplicationLink>> still
>>>  says things that are wrong (re alpha conversion -- each
>>> lambda gets
>>>  alpha converted, so the "sugar syntax" section cannot
>>> possibly
>>>  be right).
>>>
>>>  I'm asking, because I'm trying to fix #910 by doing the
>>> alpha
>>>  conversion
>>>  correctly, and the result of the fix is that unit tests
>>> with
>>>  implication
>>>  links in them now fail.  The whole thing smells bad.
>>>
>>>  Either ImplicationLinks do inherit from ScopeLink, in
>>> which
>>>  case, there
>>>  should be no complaints about how the ScopeLink works:
>>> it does
>>>  the right
>>>  thing.  If you don't like what the scopeLink does, then
>>>  ImplicationLinks
>>>  should NOT inherit from it ...
>>>
>>>  In either case, the wiki page needs fixing, because the
>>> alpha
>>>  conversion
>>>  conversation we had recently renders that page
>>> incoherent.
>>>
>>>  I don't really care, one way or the other, but I do need
>>> to
>>>  understand
>>>  the intended design well enough to be able to fix bugs,
>>> and
>>>  right now, I
>>>  don't understand what ImplicationLink is, or how its
>>> supposed to
>>>  work.
>>>
>>>  --linas
>>>
>>>
>>>
>>>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/CAHrUA35w5rCVqPgSYr8EcmJHGRKT-g8P5%2BtoFfh2Fg2Hu06FnA%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBd9QTQn2qdtrGh42-NnYHQQ2VvyP%3Dcurryfb_tMLsEUhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: ImplicationLink?

[Ben Goertzel]

alpha converted, so the "sugar syntax" section
>>> cannot
>>>  possibly
>>>   be right).
>>>
>>>   I'm asking, because I'm trying to fix #910 by
>>> doing the
>>>  alpha
>>>   conversion
>>>   correctly, and the result of the fix is that
>>> unit tests
>>>  with
>>>   implication
>>>   links in them now fail.  The whole thing
>>> smells bad.
>>>
>>>   Either ImplicationLinks do inherit from
>>> ScopeLink, in which
>>>   case, there
>>>   should be no complaints about how the
>>> ScopeLink works:
>>>  it does
>>>   the right
>>>   thing.  If you don't like what the scopeLink
>>> does, then
>>>   ImplicationLinks
>>>   should NOT inherit from it ...
>>>
>>>   In either case, the wiki page needs fixing,
>>> because the
>>>  alpha
>>>   conversion
>>>   conversation we had recently renders that page
>>> incoherent.
>>>
>>>   I don't really care, one way or the other, but
>>> I do need to
>>>   understand
>>>   the intended design well enough to be able to
>>> fix bugs, and
>>>   right now, I
>>>   don't understand what ImplicationLink is, or
>>> how its
>>>  supposed to
>>>   work.
>>>
>>>   --linas
>>>
>>>
>>>
>>>
>>>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/CAHrUA35RygO2MWjZJ2MfEA2TCvBC8kjvFDVvj2-CNmqP2e9PLQ%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBe%3DzQ2XZ1HxtUfujgB_LvRFmig7eia_KOxh8dSZsLSn3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: ImplicationLink?

[Ben Goertzel]

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, that more explicit articulation of logical structures
in Atomspace reduces confusion, and is thus worthwhile even when it
makes things a bit less elegant...



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBe9JN9zB47m3CXvZvU-1U54unrUz0_-wcPVTHfgUhRSqQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] symbolic grounding

[Ben Goertzel]

Symbol grounding is in principle no big issue for a system that maps
both language and non-linguistic perception into the same
representational framework...

There are a few little implementation and teaching/training details though...

Ruiting and I are actually working on a paper that mathematically
models the use of logic to provide grounding of language regarding
perceptions and actions, as being developed in OpenCog... I'll share
it when it's done...

ben

On Wed, Oct 19, 2016 at 7:13 AM, Daniel Gross  wrote:
> Hi all,
>
> I recently stumbled (again) over some articles on the symbolic grounding
> problem. I got curious, how does OpenCog deal with symbolic grounding, in
> particular, of the autonomous kind ...
>
> thank you,
>
> Daniel
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/e3122cd7-7124-4a5c-8a0f-a089aef339b6%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBd7CFcBueXSo5ReWN-Pr56YU1xKq-JoAOm0GB2e4FLo2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] 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...

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBcdZ%2BVabVDquRyAjGrWP-BJmQgO6w%2BiD%2Bpdp8%2Bb_gzYOA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Re: EvidenceCountTV

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

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

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

[opencog-dev] Re: EvidenceCountTV

[Ben Goertzel]

Yes, those 2 points would satisfy our current needs... thx...
On Oct 21, 2016 1:23 PM, "Nil Geisweiller"  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 opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBeveKYR6CSupoCgDUabfQq%2B%3DPG1jOiwn-zyZgOwhQ8AbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Is automatic alpha-conversion evil?

[Ben Goertzel]

Nil,

Just brainstorming here, but perhaps the command for adding an Atom
should have an option that the user can set, which determines whether
the results would be alpha-converted or not

The default would be to do the alpha-conversion (which would be
appropriate if the variable names are say randomly generated, and thus
of no particular importance to the user -- the alpha conversion is
then just preventing odd collisions between randomly generated
variable names created by two different processes)

However, if the user wants they can override this default and specify
"no alpha conversion", and then it is their responsibility to check
and be sure their chosen VariableNode names are not going to be used
in a way that creates some conflict ...

This option would need to be added to Scheme, python, Haskell
bindings, but also to the core API for adding scoped links, I guess...

I am only about 83.456% sure I understand the problem here...

-- Ben



On Fri, Oct 21, 2016 at 11:55 PM, 'Nil Geisweiller' via opencog
 wrote:
> Hi,
>
> I start to think that automatic alpha-conversion is evil.
>
> First let me recall what it does. Say you've added
>
> (Scope (VariableList (Variable "$X") (Variable "$Y"))
>(And (Variable "$X") (Variable "$Y")))
>
> and you subsequently add
>
> (Scope (And (Variable "$gold") (Variable "$silver")))
>
> then recalling the handle of that last addition, you'd get the first
> alpha-equivalent scope, which is
>
> (Scope (VariableList (Variable "$X") (Variable "$Y"))
>(And (Variable "$X") (Variable "$Y")))
>
> This is rather confusing to the user, but even worse the pattern matcher
> behaves differently with the former or the latter. If you use the former to
> match grounds containing variables "$X" and "$Y" it may not work due to the
> pattern matcher discarding self-matches. The latter would match UNLESS the
> former has been previously added, because the variables "$gold" and
> "$silver" would be silently replaced by "$X" and "$Y". This is horribly
> confusing to the user!
>
> Second, it seems rather arbitrary to try to detect this kind of equivalence
> while there's an infinity of others. For instance
>
> (And (Variable "$X") (And (Variable "$Y"))
>
> is equivalent to
>
> (And (Variable "$X") (Variable "$Y"))
>
> For these reasons I think semantic equivalence detection shouldn't be
> incorporated into the AtomSpace. The AtomSpace should take care of the
> syntax only (OK, with the exception of unordered links), as it's always
> been, and this task should differed to another process working above the
> AtomSpace.
>
> It was suggested a while ago to have a normal form reduction engine for the
> AtomSpace, similar to MOSES', and such an engine could be used to reduce
> while adding atoms, if the user chooses so. This is a much cleaner way to
> handle that. Also since semantic equivalence is undecidable, there will
> always be a battle between completeness and performance. Another reason to
> have this ever growing monster above the AtomSpace rather than in it.
>
> OK, I don't know if I've convinced you, or even if I've convinced myself,
> but it's really a discussion we need to have.
>
> Opinions welcome.
>
> Nil
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/580A3A75.1020708%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.



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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBenW9A10kjH%3Ds%2Bmkk-rR9gwP5eWEtOcmnCZzip%3DNXTjcA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: EvidenceCountTV

[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

On Fri, Oct 21, 2016 at 4:27 PM, 'Nil Geisweiller' via opencog
 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" >> <mailto:ngeis...@googlemail.com>> 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
>>>  

[opencog-dev] Cogistry: Accelerating Algorithmic Chemistry via Cognitive Synergy

[Ben Goertzel]

Some funky, partly-new AGI / Alife ideas I cooked up...

http://blog.opencog.org/2016/10/25/cogistry-accelerating-algorithmic-chemistry-via-cognitive-synergy/

This would be a new sort of cognitive process living within OpenCog,
building on, leveraging and enhancing the various others...

Not that we don't have enough work to do already...


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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdpoCqrzMPXMHUhuO-VDEVk6n4FvEb83egiCHu10oY9Zw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Hong Cogathon Dec 2016

[Ben Goertzel]

We crazy Hong Konger OpenCog/Hansonites be at it again ... Nov 28-Dec 9 ...

http://opencog.org/2016/10/hong-cog-a-thon-dec-2016/

http://wiki.opencog.org/w/Hong_Cogathon_Dec_2016

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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdTaQBp%3D9%3D1KSfZ0VGBHkj%2B%3DS8L3p56kq2BErAYvP3A3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Python Vs Scheme shell for interacting w/ opencog

[Ben Goertzel]

The Scheme shell is strongly preferred  at the moment, because it is
less buggy and better maintained, and because the set of Scheme
bindings is more complete

There's of course a self-reinforcing aspect here: Everyone uses the
Scheme shell because it works better .. and it works better because it
gets better maintained and extended because everyone uses it...

-- Ben


On Fri, Oct 28, 2016 at 8:43 PM, Apil Tamang
 wrote:
> All,
> So from what I know so far, there're at least two ways to interact w/ the
> cogserver for manipulating atomspace. They'd be the 'Python' and the
> high-level 'Scheme' shell exposed by default at 18001. My question: which
> one is generally preferred. I feel like I just see a lot more of the latter.
> Is there a reason why scheme code is preferred... if that indeed is the
> case?
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/b92fec3c-3890-463e-b03d-74fe9772adfd%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBcx0awufJ_8tekRUoYabBtyZ1NPdc0b9oALL7M1Sy%2BUpA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Hong Cogathon Dec 2016

[Ben Goertzel]

Yah ... we'll do another one sometime in the first half of next year
with more notice ... this one sorta came together semi last minute due
to some Hanson-cog stuff, and then I figured why not invite other
OpenCoggers in case someone is available...

Actually I'd been thinking to do a Cogathon in Ethiopia (halfway
between the US and HK, close to Europe, and we have an office there
too), but it seems best to wait for that till the politics settles
down there at the moment ... currently e.g. the gov't seems to have
made mobile Internet access very difficult (whereas it used too be
fine in the cities)

As for interactions w/ remote folks -- definitely it makes sense to
stream the seminars and to record better videos than was done last
time   However, beyond the seminars, where a general
"hackathon-type" event is concerned, it strikes me that mixing F2F
with online modalities may not be that wise.   The beauty of F2F is
that we can discuss stuff while walking to lunch, and can mess around
with the AI on the Hanson robots with minimal hassle, etc. etc. ...
There's pretty much no way to share that experience with remote folks,
and constraining F2F folks to do stuff that can easily be shared in
real time w/ remote folks doesn't make much sense...

However, it does strike me that it would be possible and interesting
to do some sort of "purely online Cogathon" at some point, as a
separate event   Delivering seminar or tutorial type content via
live video-chat is not difficult, and collaborative coding via Github
and Slack/MatterMost/whatever would work perfectly well   I like
this idea more than trying to too fully online-ify a F2F event   I
think a purely online Cogathon could work great if both "insiders" and
newbies decided to put time into it   Perhaps we should try that
after this upcoming F2F cogathon and before the next F2F one...

ben



On Sat, Oct 29, 2016 at 5:16 AM, Matt Chapman  wrote:
> I wish that had been announced sooner. 4 weeks notice is a bit short to get
> 2 weeks off work.
>
> +1 for supporting remote participants. If I can figure out a way to make it
> in person, I'm willing to take responsibility for trying to help make that
> happen...
>
> All the Best,
>
> Matt
>
> --
> Standard Disclaimer:
> Please interpret brevity as me valuing your time, and not as any negative
> intention.
>
> On Fri, Oct 28, 2016 at 5:18 AM, Ben Goertzel  wrote:
>>
>> We crazy Hong Konger OpenCog/Hansonites be at it again ... Nov 28-Dec 9
>> ...
>>
>> http://opencog.org/2016/10/hong-cog-a-thon-dec-2016/
>>
>> http://wiki.opencog.org/w/Hong_Cogathon_Dec_2016
>>
>> --
>> Ben Goertzel, PhD
>> http://goertzel.org
>>
>> “I tell my students, when you go to these meetings, see what direction
>> everyone is headed, so you can go in the opposite direction. Don’t
>> polish the brass on the bandwagon.” – V. S. Ramachandran
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To post to this group, send email to opencog@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/CACYTDBdTaQBp%3D9%3D1KSfZ0VGBHkj%2B%3DS8L3p56kq2BErAYvP3A3w%40mail.gmail.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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/CAPE4pjA53u2%3Dq33ki__L7tFpOQRk-FZRx2__S9hd-jE8pjtORw%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdDmFPSYwZkXjFBB92c6z4OoY9-nAkDF6jU%2BqYx0C2WhA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Is the open source AtomSpace?

[Ben Goertzel]

Hi Tom,

Hmm, it's true that the best Atomspaces I'm aware of are for
proprietary projects (a Hanson Robotics one with some
robot-character-personality stuff; and one for a consulting project
that has a customer's product catalogue and related info loaded into
it...)

There is a bio-Atomspace with a bunch of bio-ontologies in it, but
that's kinda specialized...

Creating a good Atomspace for public use, is a good project that
should be done, I agree...

Senna has made the best start for this, I think, via writing code to
import Simple English Wikipedia into the Atomspace, and saving a bunch
of these Atoms in postgres...

We could perhaps put a big Postgres DB on AWS somewhere, containing
Atoms resultant from parsing Simple English Wikipedia.   That would be
a start.

Be aware however that parsing Simple English Wikipedia currently
results in a lot of Atoms, i.e. way more than you're gonna fit in RAM
one one machine unless you have a supercomputer...

ben


On Sat, Oct 29, 2016 at 6:33 AM,   wrote:
> Specifically - I am trying to do the formalization of the legal knowledge
> and I find it necessary to use the real-world concepts, e.g. formalization
> of the VAT tax law requires ontologies of goods, of delivery terms, of
> company types. It would be easier to contribute in already existing
> knowledge base than to build it from scratch.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/b5f6352c-38e0-4a1b-a257-7c850937e022%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBcxZsytD06gAjT%3D2e92xGvtNqWjYRbbY-D2gwZSSzeHpw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: ImplicationLink?

[Ben Goertzel]

If we have

> ImplicationScopeLink
>  VariableNode  x
>  P(x)
>  Q(x)

then e.g. PLN can assign this a truth value equal to

Sum_x ( max( P(x), Q(x)) ) / Sum_x P(x)

or

Sum_x ( P(x) * Q(x) ) / Sum_x P(x)

but may assign a quite different truth value for

ForAllLink
VariableNode x
ImplicationLink
P(x)
Q(x)


PLN does assign these two constructs different uncertain truth values,
so this is not just a theoretical difference...

Other uncertain logic frameworks may also assign the two constructs
different TVs, I would think...

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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdtK5m7DKJQ8gdE8YV9GPx9nzyTR2PK%3DF8s%3DHZsK7UTTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: ImplicationLink?

[Ben Goertzel]

On Mon, Nov 7, 2016 at 11:28 PM, Linas Vepstas  wrote:
> OK, that makes sense.  In that case, though, why not invent a new
> SpecialAllLink which has the desired properties?  Inventing one new link for
> this would be more economical, and less confusing than having six new links:
>
> ImplicationScope
> IntentionalImplicationScope
> ExtensionalImplicationScope
> EquivalenceScope
> IntensionalEquivalenceScope
> ExtensionalEquivalenceScope
>
> which is what the current code does.
>
> Besides, come the day you want to change the PLN formula, or create yet
> another one, you would just need a NewFormulaLink  instead of six new links.
>
> --linas
>
> On Mon, Nov 7, 2016 at 4:23 PM, Ben Goertzel  wrote:
>>
>> If we have
>>
>> > ImplicationScopeLink
>> >  VariableNode  x
>> >  P(x)
>> >  Q(x)
>>
>> then e.g. PLN can assign this a truth value equal to
>>
>> Sum_x ( max( P(x), Q(x)) ) / Sum_x P(x)
>>
>> or
>>
>> Sum_x ( P(x) * Q(x) ) / Sum_x P(x)
>>
>> but may assign a quite different truth value for
>>
>> ForAllLink
>> VariableNode x
>> ImplicationLink
>> P(x)
>> Q(x)
>>
>>
>> PLN does assign these two constructs different uncertain truth values,
>> so this is not just a theoretical difference...
>>
>> Other uncertain logic frameworks may also assign the two constructs
>> different TVs, I would think...
>>
>> ben
>> --
>> Ben Goertzel, PhD
>> http://goertzel.org
>>
>> “I tell my students, when you go to these meetings, see what direction
>> everyone is headed, so you can go in the opposite direction. Don’t
>> polish the brass on the bandwagon.” – V. S. Ramachandran
>
>



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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdSXCBkxvtaF2MWjQZOrRZN6AFPOCviM9CzjCQx-SK29A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: ImplicationLink?

[Ben Goertzel]

I think this may be what the

AverageQuantifierLink

used to do?

Then we could say

AverageQuantifierLink
VariableNode x
ImplicationLink
P(x)
Q(x)

and this would do what PLN needs... and if Bob had a different kind of
logic with its own formulas he could have

BobsQuantifierLink
VariableNode x
ImplicationLink
P(x)
Q(x)

But I'm not sure this would satisfy all Nil's current requirements?

ben

On Mon, Nov 7, 2016 at 11:28 PM, Linas Vepstas  wrote:
> OK, that makes sense.  In that case, though, why not invent a new
> SpecialAllLink which has the desired properties?  Inventing one new link for
> this would be more economical, and less confusing than having six new links:
>
> ImplicationScope
> IntentionalImplicationScope
> ExtensionalImplicationScope
> EquivalenceScope
> IntensionalEquivalenceScope
> ExtensionalEquivalenceScope
>
> which is what the current code does.
>
> Besides, come the day you want to change the PLN formula, or create yet
> another one, you would just need a NewFormulaLink  instead of six new links.
>
> --linas
>
> On Mon, Nov 7, 2016 at 4:23 PM, Ben Goertzel  wrote:
>>
>> If we have
>>
>> > ImplicationScopeLink
>> >  VariableNode  x
>> >  P(x)
>> >  Q(x)
>>
>> then e.g. PLN can assign this a truth value equal to
>>
>> Sum_x ( max( P(x), Q(x)) ) / Sum_x P(x)
>>
>> or
>>
>> Sum_x ( P(x) * Q(x) ) / Sum_x P(x)
>>
>> but may assign a quite different truth value for
>>
>> ForAllLink
>> VariableNode x
>> ImplicationLink
>> P(x)
>> Q(x)
>>
>>
>> PLN does assign these two constructs different uncertain truth values,
>> so this is not just a theoretical difference...
>>
>> Other uncertain logic frameworks may also assign the two constructs
>> different TVs, I would think...
>>
>> ben
>> --
>> Ben Goertzel, PhD
>> http://goertzel.org
>>
>> “I tell my students, when you go to these meetings, see what direction
>> everyone is headed, so you can go in the opposite direction. Don’t
>> polish the brass on the bandwagon.” – V. S. Ramachandran
>
>



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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBfN2v3pECbWxUec-R9KEA2ZakWqSfwNTRqQvD7txYMVEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] OpenCog pattern miner

[Ben Goertzel]

Shujing, perhaps you can help with this?

Hedra, it would be good if you could give precise instructions for
replicating the problem that will make it easier for Shujing or Nil to
help...

Thanks
Ben
On Nov 9, 2016 08:07, "Hedra Seid"  wrote:

> Hello
>
> I have been working with OpenCog pattern miner and it sometimes stack and
> stop mining at some point ... Have waited for Pattern miner result more
> than half an hour where the atomspace contains only 55 atoms and it stops
> at 40%. Any solutions?
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/4ef5fae7-dd3f-410a-ae26-c9c4e8ee4f50%40googlegroups.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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBc_Kpk3NwhPqg4RScY7ACnhbERS3JW6iZVxGtR6KFMnTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] OpenCog pattern miner

[Ben Goertzel]

Hedra,

I suggest you should upload to some repository the actual data that
you loaded into the Pattern Miner, and the exact script that you ran
to launch the pattern miner

That way Nil or Shujing can follow the exact steps that you did, and
see exactly how the bug was encountered.

Without a clear way to replicate the bug, it may be hard for them to debug it

I would like them to be able to exactly replicate what you did on
their machines...

thanks
ben

On Wed, Nov 9, 2016 at 9:36 AM, Hedra Seid  wrote:
> Okay, Ben
>
> I checked the pattern miner with the provided example corpus file and it
> works fine. But the problem is it sometimes stop mining with unknown reason
> for me.
>
> Here is what I tried
>
> we are working on applying OpenCog pattern miner as a dialogue assistance to
> help the customer service in providing answers mining what has been said
> before (or mining from the knowledge base atomspace).
>
> - We have dialogues parsed and loaded to the atomspace, and loading the
> opencog pattern miner module, the cogserver results the  following
>
> Error: instance link contains variables:
> (VariableNode "$wF0EfmscF9F25N7BAoBtBNmDChd5Ep0Cd9q0") ; [111651][111516]
>
> - We write the Atomese representation of each dialogues (like the aiml to
> atomese representations) and load to the atomspace and start the opencog
> mining
>
> here the pattern miner works and generates output files, but only the 2gram
> results are extracted.
>
> - adding some knowledge tried the same data but the pattern miner stoped
> mining reaching 40% ... calculating the surprisingness
>
> On Wed, Nov 9, 2016 at 11:57 AM, Ben Goertzel  wrote:
>>
>> Shujing, perhaps you can help with this?
>>
>> Hedra, it would be good if you could give precise instructions for
>> replicating the problem that will make it easier for Shujing or Nil to
>> help...
>>
>> Thanks
>> Ben
>>
>> On Nov 9, 2016 08:07, "Hedra Seid"  wrote:
>>>
>>> Hello
>>>
>>> I have been working with OpenCog pattern miner and it sometimes stack and
>>> stop mining at some point ... Have waited for Pattern miner result more than
>>> half an hour where the atomspace contains only 55 atoms and it stops at 40%.
>>> Any solutions?
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To post to this group, send email to opencog@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/4ef5fae7-dd3f-410a-ae26-c9c4e8ee4f50%40googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> With Regards!
>
> Hedra Seid
>



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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBf9awK%3Dj_PUuHF7L%2BmVkmJVHptxCWFKH5ZEMUcPWocH%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] how does the concepts of PLN fit into the opencog system

[Ben Goertzel]

Yes, there are not yet any systematic hands-on tutorials, sorry...

OpenCog is not just a toolkit or framework.   However, it can
certainly be used that way, and has profitably been used that way
sometimes.

If you look at "Engineering General Intelligence", especially volume
2, you will find a comprehensive cognitive architecture aimed at
human-level AGI.   The current OpenCog system implements parts of this
design, and also includes some other stuff  However, the whole
integrated design as described in that book is not yet ready and
usable... only some pieces are there  So for now, you can use
those existing pieces for something, or you can work on trying to
complete that whole design .. or you can add new stuff out of your own
head ;) ...

In the overall cognitive architecture, PLN can be used in many ways...
it can be used to help figure out how to achieve system goals, but
also for many other kinds of inference...

If you want to work on using OPenCog to control an autonomous agent,
then one option is to join our effort to make OpenCog control the
Hanson Robot heads (and the avatar model thereof that exists in
Blender)   This is the only current initiative to try to use
OpenCog as an integrated cognitive architecture rather than a
toolkit/framework..

-- Ben G

On Sat, Nov 12, 2016 at 9:11 PM, Apil Tamang
 wrote:
> Been reading through the PLN book, largely because I really couldn't get
> hands-on on any examples or tutorials exploring various concepts of opencog
> in a more streamlined way. I am starting to get the impression that much of
> opencog is really just a framework for doing advanced machine learning work.
> Let me know how true that is.
>
> Not really griping here either. PLN has been a good read. A good insight to
> have at this point is how PLN is relevant to the opencog framework. This
> might help me understand how PLN is used in a more practical context. The
> wiki page gives a little, it is far from what I'd call a satisfactory
> exposition. Where is the integration between concepts form PLN and Opencog
> itself ? Does PLN really just extend opencog, for that matter?
>
> Thanks for any feedback.
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/3fab4600-16aa-47e6-98ed-a7aab243eb0a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdyodo4pknv%3DbHK26cnF0-zjF2kckt81q9%3Dt%2BBco%2BGhwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] how does the concepts of PLN fit into the opencog system

[Ben Goertzel]

HEAD is the Hanson Environment for Application Development, which is a
separate body of code used to simulate and control the robot heads,
and also to interface between the robot heads and OpenCog

The AGI design is called CogPrime or PrimeAGI ... and is distinct
conceptually from the OpenCog software platform... but these
distinctions are often fudgy in practice...

I am thinking to do an interactive session for remote developers
sometime later in in December, rather than during the F2F Cogathon ...
I think it's a mistake to mix the two things up too much...



On Sun, Nov 13, 2016 at 3:39 AM, Apil Tamang
 wrote:
> Thanks for the response. I believe that this is what you coined as
> 'CogPrime', yes !? Do you guys call it 'OpenCog' these days, or maybe just
> the 'Head', as ominous as the latter sounds :)
>
> It'd be nice to try and join the initiative on the Hanson robotic head. I'm
> just not sure where to start from... yet.
>
> Are there any planned remote interactive session(s) during the december
> hackathon event, by any chance?
>
> On Saturday, November 12, 2016 at 4:54:27 PM UTC-5, Ben Goertzel wrote:
>>
>> Yes, there are not yet any systematic hands-on tutorials, sorry...
>>
>> OpenCog is not just a toolkit or framework.   However, it can
>> certainly be used that way, and has profitably been used that way
>> sometimes.
>>
>> If you look at "Engineering General Intelligence", especially volume
>> 2, you will find a comprehensive cognitive architecture aimed at
>> human-level AGI.   The current OpenCog system implements parts of this
>> design, and also includes some other stuff  However, the whole
>> integrated design as described in that book is not yet ready and
>> usable... only some pieces are there  So for now, you can use
>> those existing pieces for something, or you can work on trying to
>> complete that whole design .. or you can add new stuff out of your own
>> head ;) ...
>>
>> In the overall cognitive architecture, PLN can be used in many ways...
>> it can be used to help figure out how to achieve system goals, but
>> also for many other kinds of inference...
>>
>> If you want to work on using OPenCog to control an autonomous agent,
>> then one option is to join our effort to make OpenCog control the
>> Hanson Robot heads (and the avatar model thereof that exists in
>> Blender)   This is the only current initiative to try to use
>> OpenCog as an integrated cognitive architecture rather than a
>> toolkit/framework..
>>
>> -- Ben G
>>
>> On Sat, Nov 12, 2016 at 9:11 PM, Apil Tamang
>>  wrote:
>> > Been reading through the PLN book, largely because I really couldn't get
>> > hands-on on any examples or tutorials exploring various concepts of
>> > opencog
>> > in a more streamlined way. I am starting to get the impression that much
>> > of
>> > opencog is really just a framework for doing advanced machine learning
>> > work.
>> > Let me know how true that is.
>> >
>> > Not really griping here either. PLN has been a good read. A good insight
>> > to
>> > have at this point is how PLN is relevant to the opencog framework. This
>> > might help me understand how PLN is used in a more practical context.
>> > The
>> > wiki page gives a little, it is far from what I'd call a satisfactory
>> > exposition. Where is the integration between concepts form PLN and
>> > Opencog
>> > itself ? Does PLN really just extend opencog, for that matter?
>> >
>> > Thanks for any feedback.
>> >
>> >
>> > --
>> > 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/3fab4600-16aa-47e6-98ed-a7aab243eb0a%40googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Ben Goertzel, PhD
>> http://goertzel.org
>>
>> “I tell my students, when you go to these meetings, see what direction
>> everyone is headed, so you can go in the opposite direction. Don’t
>> polish the brass on the bandwagon.” – V. S. Ramacha

Re: [opencog-dev] OpenCog pattern miner

[Ben Goertzel]

Thanks Hedra!

Nil -- I hate to distract you from the BC, but could you please take a
look at this sometime soon?  It seems Shu Jing is too busy to help
out, and I know you have played a bit with the Pattern Miner a few
months ago...

thx
ben

On Mon, Nov 14, 2016 at 7:27 AM, Hedra Seid  wrote:
> Hi Ben, Sorry for my late reply ...
>
> Here attached are the scheme files I used to apply the OpenCog pattern miner
>
> STEPS I followed
>
> 1. Start opencog server with the config file  -c
> ../lib/opencog_patternminer.conf and relex server
>
> 2. Telnet to opencog server on port 17001
>
> 3. Access the scheme shell
>
> 4. (use-modules (opencog) (opencog nlp) (opencog nlp chatbot) (opencog nlp
> relex2logic))
>
> I import those modules to use (nlp-parse) and let relex parse the sentences
> in the dialogue but it creates a VariableNode instance which the Pattern
> miner considers as an error node type to have. To fix this I have to make
> the atomspace free.
>
> 5. (clear)
>
> 6. (load-scm-from-file "test-dialogue.scm")
> (load-scm-from-file "back-ground.scm")
>
> here the atomspace contains 9900 atoms
>
> 7. Exit the scheme shell and load the test pettern miner agent module
>
>loadmodule
> /home/tanksha/opencog_ws/opencog/build/opencog/learning/PatternMiner/libTestPatternMinerAgent.so
>
> 8. From the opencog server I got this
> Listening on port 17001
> Debug: PatternMining start! Max gram = 4, mode = Depth_First
> Start thread 0 from 0 to 7467
> 0% completed in Thread 0.
>
> It stays like this for a long time ... the percent doesn’t increase.
>
>
>
>
> On Fri, Nov 11, 2016 at 2:56 PM, Ben Goertzel  wrote:
>>
>> Hedra,
>>
>> I suggest you should upload to some repository the actual data that
>> you loaded into the Pattern Miner, and the exact script that you ran
>> to launch the pattern miner
>>
>> That way Nil or Shujing can follow the exact steps that you did, and
>> see exactly how the bug was encountered.
>>
>> Without a clear way to replicate the bug, it may be hard for them to debug
>> it
>>
>> I would like them to be able to exactly replicate what you did on
>> their machines...
>>
>> thanks
>> ben
>>
>> On Wed, Nov 9, 2016 at 9:36 AM, Hedra Seid  wrote:
>> > Okay, Ben
>> >
>> > I checked the pattern miner with the provided example corpus file and it
>> > works fine. But the problem is it sometimes stop mining with unknown
>> > reason
>> > for me.
>> >
>> > Here is what I tried
>> >
>> > we are working on applying OpenCog pattern miner as a dialogue
>> > assistance to
>> > help the customer service in providing answers mining what has been said
>> > before (or mining from the knowledge base atomspace).
>> >
>> > - We have dialogues parsed and loaded to the atomspace, and loading the
>> > opencog pattern miner module, the cogserver results the  following
>> >
>> > Error: instance link contains variables:
>> > (VariableNode "$wF0EfmscF9F25N7BAoBtBNmDChd5Ep0Cd9q0") ;
>> > [111651][111516]
>> >
>> > - We write the Atomese representation of each dialogues (like the aiml
>> > to
>> > atomese representations) and load to the atomspace and start the opencog
>> > mining
>> >
>> > here the pattern miner works and generates output files, but only the
>> > 2gram
>> > results are extracted.
>> >
>> > - adding some knowledge tried the same data but the pattern miner stoped
>> > mining reaching 40% ... calculating the surprisingness
>> >
>> > On Wed, Nov 9, 2016 at 11:57 AM, Ben Goertzel  wrote:
>> >>
>> >> Shujing, perhaps you can help with this?
>> >>
>> >> Hedra, it would be good if you could give precise instructions for
>> >> replicating the problem that will make it easier for Shujing or Nil
>> >> to
>> >> help...
>> >>
>> >> Thanks
>> >> Ben
>> >>
>> >> On Nov 9, 2016 08:07, "Hedra Seid"  wrote:
>> >>>
>> >>> Hello
>> >>>
>> >>> I have been working with OpenCog pattern miner and it sometimes stack
>> >>> and
>> >>> stop mining at some point ... Have waited for Pattern miner result
>> >>> more than
>> >>> half an hour where the atomspace contains only 55 atoms and it stops
>> >>> at 40%.
>> >>> Any solutions?
>> >

Re: [opencog-dev] OpenCog pattern miner

[Ben Goertzel]

Nil,

Well, we do need to use the pattern miner for a couple projects pretty
soon... but that doesn't mean it has to be your job to fix it up...

It would be great though if you could write down a detailed list of
what you feel needs to be done to fix it up, so Hedra can give it a
shot (and maybe you can do some of the tricker bits?) ...

ben

On Mon, Nov 14, 2016 at 11:04 AM, Nil Geisweiller
 wrote:
> Hi,
>
> the last time I reviewed the pattern miner I found that it was not ready for
> general use, and estimated it would take me about 2 weeks to put it in
> shape. I had started this branch for that
> https://github.com/ngeiswei/opencog/commits/hack-pattern-miner
>
> Anyway, I'll have a look at it within the next couple days, who knows, it
> might not be much.
>
> Hedra, could you create an issue on the opencog repo (basically re-pasting
> your report and attaching your files there)? If you can reduce the KB and
> dialogue size it's even better, maybe it could serve as a unit test.
>
> Thanks,
> Nil
>
>
> On 11/14/2016 12:17 PM, Ben Goertzel wrote:
>>
>> Thanks Hedra!
>>
>> Nil -- I hate to distract you from the BC, but could you please take a
>> look at this sometime soon?  It seems Shu Jing is too busy to help
>> out, and I know you have played a bit with the Pattern Miner a few
>> months ago...
>>
>> thx
>> ben
>>
>> On Mon, Nov 14, 2016 at 7:27 AM, Hedra Seid  wrote:
>>>
>>> Hi Ben, Sorry for my late reply ...
>>>
>>> Here attached are the scheme files I used to apply the OpenCog pattern
>>> miner
>>>
>>> STEPS I followed
>>>
>>> 1. Start opencog server with the config file  -c
>>> ../lib/opencog_patternminer.conf and relex server
>>>
>>> 2. Telnet to opencog server on port 17001
>>>
>>> 3. Access the scheme shell
>>>
>>> 4. (use-modules (opencog) (opencog nlp) (opencog nlp chatbot) (opencog
>>> nlp
>>> relex2logic))
>>>
>>> I import those modules to use (nlp-parse) and let relex parse the
>>> sentences
>>> in the dialogue but it creates a VariableNode instance which the Pattern
>>> miner considers as an error node type to have. To fix this I have to make
>>> the atomspace free.
>>>
>>> 5. (clear)
>>>
>>> 6. (load-scm-from-file "test-dialogue.scm")
>>>  (load-scm-from-file "back-ground.scm")
>>>
>>> here the atomspace contains 9900 atoms
>>>
>>> 7. Exit the scheme shell and load the test pettern miner agent module
>>>
>>> loadmodule
>>>
>>> /home/tanksha/opencog_ws/opencog/build/opencog/learning/PatternMiner/libTestPatternMinerAgent.so
>>>
>>> 8. From the opencog server I got this
>>> Listening on port 17001
>>> Debug: PatternMining start! Max gram = 4, mode = Depth_First
>>> Start thread 0 from 0 to 7467
>>> 0% completed in Thread 0.
>>>
>>> It stays like this for a long time ... the percent doesn’t increase.
>>>
>>>
>>>
>>>
>>> On Fri, Nov 11, 2016 at 2:56 PM, Ben Goertzel  wrote:
>>>>
>>>>
>>>> Hedra,
>>>>
>>>> I suggest you should upload to some repository the actual data that
>>>> you loaded into the Pattern Miner, and the exact script that you ran
>>>> to launch the pattern miner
>>>>
>>>> That way Nil or Shujing can follow the exact steps that you did, and
>>>> see exactly how the bug was encountered.
>>>>
>>>> Without a clear way to replicate the bug, it may be hard for them to
>>>> debug
>>>> it
>>>>
>>>> I would like them to be able to exactly replicate what you did on
>>>> their machines...
>>>>
>>>> thanks
>>>> ben
>>>>
>>>> On Wed, Nov 9, 2016 at 9:36 AM, Hedra Seid  wrote:
>>>>>
>>>>> Okay, Ben
>>>>>
>>>>> I checked the pattern miner with the provided example corpus file and
>>>>> it
>>>>> works fine. But the problem is it sometimes stop mining with unknown
>>>>> reason
>>>>> for me.
>>>>>
>>>>> Here is what I tried
>>>>>
>>>>> we are working on applying OpenCog pattern miner as a dialogue
>>>>> assistance to
>>>>> help the customer service in providing answers mining what has been
>>>>> said
&

Re: [opencog-dev] Destin status?

[Ben Goertzel]

pretty  much that's zombie code... Ralf Mayet is working on building
something conceptually DeSTIN-like within the Atomspace, but that's a
new project which won't use the old DeSTIN code...

On Tue, Nov 15, 2016 at 4:08 AM,   wrote:
> Hello!
> I want to try destin for object detection. I've managed to build it from
> master branch but import fails with error:
> ImportError: dynamic module does not define init function (init_pydestin)
>
> So first question: is there a working revision?
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/78ca229c-bf79-4e5a-b192-4dc03649e0a4%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBekSX6q2_eTxfvFOaKjyOtjk1nMJcAdj6b-LcUNMU55sw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Is automatic alpha-conversion evil?

[Ben Goertzel]

Too ugly...

More later...

On Nov 16, 2016 8:43 PM, "'Nil Geisweiller' via opencog" <
opencog@googlegroups.com> wrote:

> Another option would be to defined quoted atom types corresponding to all
> scope links, like
>
> QuotedImplicationScopeLink
>
> Or
>
> ImplicationScopeLocalQuoteLink
>
> which would inherit a LocalQuoteLink.
>
> It has the advantage of being compact, unambiguous and circumvent the
> alpha-conversion issue altogether.
>
> What do you think?
>
> Nil
>
> On 11/16/2016 01:34 PM, Nil Geisweiller wrote:
>
>> I'm back to this issue.
>>
>> The notion of LocalQuote is indeed incompatible with systematic
>> alpha-conversion.
>>
>> Consider this pattern
>>
>> (Get
>> (VariableList
>>(TypedVariable
>>   (Variable "$X")
>>   (Type "TypedVariableLink"))
>>(TypedVariable
>>   (Variable "$P")
>>   (Type "PredicateNode"))
>>(TypedVariable
>>   (Variable "$Q")
>>   (Type "PredicateNode"))
>> (LocalQuote
>>(ImplicationScope
>>   (Variable "$X")
>>   (Variable "$P")
>>   (Variable "$Q"
>>
>> This fetches ImplicationScope links.
>>
>> If the following
>>
>> (ImplicationScope
>> (Variable "$X")
>> (Variable "$P")
>> (Variable "$Q"))
>>
>> happen to be alpha-equivalent to something with different variable names
>> it will render the Bind link invalid.
>>
>> Indeed alpha-conversion shouldn't be triggered in that case, the right
>> idea is that the ImplicationScope, when quoted corresponds to a
>> DIFFERENT atom than the one not being quoted. Also of course if we
>> decide to not perform systematic alpha-conversion then this problem
>> doesn't arise.
>>
>> I'm re-iterating my question. Do we really want automatic
>> alpha-conversion to begin with?
>>
>> If the answer is yes then I suppose we need a way to tell that the
>> quoted version is different than then unquoted version.
>>
>> Nil
>>
>> On 10/22/2016 03:34 AM, Ben Goertzel wrote:
>>
>>> Nil,
>>>
>>> Just brainstorming here, but perhaps the command for adding an Atom
>>> should have an option that the user can set, which determines whether
>>> the results would be alpha-converted or not
>>>
>>> The default would be to do the alpha-conversion (which would be
>>> appropriate if the variable names are say randomly generated, and thus
>>> of no particular importance to the user -- the alpha conversion is
>>> then just preventing odd collisions between randomly generated
>>> variable names created by two different processes)
>>>
>>> However, if the user wants they can override this default and specify
>>> "no alpha conversion", and then it is their responsibility to check
>>> and be sure their chosen VariableNode names are not going to be used
>>> in a way that creates some conflict ...
>>>
>>> This option would need to be added to Scheme, python, Haskell
>>> bindings, but also to the core API for adding scoped links, I guess...
>>>
>>> I am only about 83.456% sure I understand the problem here...
>>>
>>> -- Ben
>>>
>>>
>>>
>>> On Fri, Oct 21, 2016 at 11:55 PM, 'Nil Geisweiller' via opencog
>>>  wrote:
>>>
>>>> Hi,
>>>>
>>>> I start to think that automatic alpha-conversion is evil.
>>>>
>>>> First let me recall what it does. Say you've added
>>>>
>>>> (Scope (VariableList (Variable "$X") (Variable "$Y"))
>>>> (And (Variable "$X") (Variable "$Y")))
>>>>
>>>> and you subsequently add
>>>>
>>>> (Scope (And (Variable "$gold") (Variable "$silver")))
>>>>
>>>> then recalling the handle of that last addition, you'd get the first
>>>> alpha-equivalent scope, which is
>>>>
>>>> (Scope (VariableList (Variable "$X") (Variable "$Y"))
>>>> (And (Variable "$X") (Variable "$Y")))
>>>>
>>>> This is rather confusing to the user, but even worse the pattern matcher
>>>> beh

Fwd: [opencog-dev] Variables, names, etc.

[Ben Goertzel]

Nil,

I just dug up and looked through our dialogue on this topic from a
year ago... see below...

ben

-- Forwarded message --
From: 'Nil Geisweiller' via opencog 
Date: Mon, Sep 7, 2015 at 6:42 PM
Subject: Re: [opencog-dev] Variables, names, etc.
To: opencog@googlegroups.com


A solution would be to have VariableNode uniqueness determined by name
+ scope, and to have that variable nodes indexed not just by names,
but by names and scope.

This would allow variable nodes with same names but different scopes
to be seen as different atoms.

Of course since the scope creation comes after variable node creation,
this process of attaching the scope to the node variable can only be
after variable node creation, but I don't think that would be a
problem, a variable would be seen global till it gets a scope.

But I have not a good idea of how much work on the AtomSpace core code
that would take... It seems it would require to change the atomspace
API to have get_variable_node(, [scope]), as opposed to
using get_node(VARIABLE_NODE, ), etc.

Nil

On 09/06/2015 12:49 AM, Linas Vepstas wrote:
>
> Well, no, cause if you did this, you would be changing the name for
> everyone who is holding it, in every scope.  You only want to change the
> name in the local scope.
>
> --linas
>
> On Thu, Sep 3, 2015 at 8:11 PM, Ben Goertzel  <mailto:b...@goertzel.org>> wrote:
>
> That could immediately be made to happen with UUIDs, right?  Changing
> the name could be done without changing the UUID, if one wanted...
>
> On Fri, Sep 4, 2015 at 6:44 AM, Linas Vepstas
> mailto:linasveps...@gmail.com>> wrote:
>  > No comment about Nil's emails (viz I agree).
>  >
>  > As I re-read what I just wrote, I realize that the very first
> thing I talk
>  > about and the very last thing are related.  It would be
> super-cool if there
>  > was an "alpha-handle"  that always pointed at the same
> "variable", no matter
>  > what alpha-renaming was done on it.
>  >
>  > Not sure how to make that work.  Perhaps this "alpha-handle" is
> the same
>  > thing as the "handle" of the opencog books???
>  >
>  > --linas
>  >
>  > On Thu, Sep 3, 2015 at 5:35 PM, Linas Vepstas
> mailto:linasveps...@gmail.com>>
>
>  > wrote:
>  >>
>  >> Phew, long email.
>  >>
>  >> Replying point by point:
>  >>
>  >> Adopting the convention #1 is fine by me.  I did not mean to
> discourage it
>  >> in any way.  I was gravitating towards #2 only because it seemed
> that
>  >> everyone wanted an automatic solution.
>  >>
>  >> I'd like to point out one ugly bit that comes with #2: it breaks
> naive
>  >> expectations in the scheme/python/c++ language bindings.  So,
> for example:
>  >>
>  >> (define vx (VariableNode "$x"))
>  >> (define fa (ForAllLink (VariableNode "$x") ...)
>  >>
>  >> The propsal #2 would automatically replace (VariableNode "$x") by
>  >> (VariableNode "$x-666") which is fine, but when the naive
> programmer tries
>  >> to use vx they won't get what they thought they should.   This
> is an issue
>  >> not just for scheme, but for python and C++ and haskell as
> well.  Its one
>  >> reason I did NOT like #2.
>  >>
>  >> 
>  >> However, for the garbage-collecting-in-the-chainer point:  as
> best as I
>  >> can tell, following #1 as a convention does not in any way fix
> this.   As
>  >> currently designed, the chainer creates "temporary" BindLinks,
> performs a
>  >> query, and then (I assume) deletes the BindLinks.   As best as I
> understand,
>  >> adopting #1 will not avoid the need for these temporaries.  Can
> you or
>  >> William clarify this?
>  >>
>  >> If the temporaries cannot be avoided, then I'm not sure why
> there's an
>  >> issue: yes, performance could be improved by avoiding copies
> with renamed
>  >> variables in them, but its not obviously a bottleneck.
>  >>
>  >> -
>  >> For #3, Its straight-forward to run queries against the backing
> store.  It
>  >> was designed for this :-)  During the matching process, there is
> a step
>  >> where one explores 

Re: [opencog-dev] Is automatic alpha-conversion evil?

[Ben Goertzel]

Nil,

I just reviewed our dialogue on this from a year ago...

It seems what we provisionally concluded there was that the chainer
should do alpha-conversion on the fly in the course of pattern
matching ... but that the Atomspace shouldn't do alpha-conversion
"automatically" in any other sense [unless we want to add some Reduct
type engine on the Atomspace, which could do alpha-conversion along
with other normalizations, but that becomes a separate issue]

We also discussed a cog-new-var command that could be used to minimize
the complexities of alpha-conversions... (via reducing the incidence
of redundant variable names)

In this case, the alpha-conversion done by the chainer in the course
of doing its business, would need to handle LocalQuoteLink
correctly...

The choice of the chainer to do alpha-conversion but not (yet) more
general types of reduction, would be made because alpha-conversion is
cheaper and easier and of such broad utility.   Later versions of the
chainer might do more general reductions as part of their ordinary
business, as well...

I may be missing something; a year ago when William and I were talking
about this, my head was fully immersed in the problem, but it's less
the case right now...

-- Ben




On Wed, Nov 16, 2016 at 8:34 PM, 'Nil Geisweiller' via opencog
 wrote:
> I'm back to this issue.
>
> The notion of LocalQuote is indeed incompatible with systematic
> alpha-conversion.
>
> Consider this pattern
>
> (Get
>(VariableList
>   (TypedVariable
>  (Variable "$X")
>  (Type "TypedVariableLink"))
>   (TypedVariable
>  (Variable "$P")
>  (Type "PredicateNode"))
>   (TypedVariable
>  (Variable "$Q")
>  (Type "PredicateNode"))
>(LocalQuote
>   (ImplicationScope
>  (Variable "$X")
>  (Variable "$P")
>  (Variable "$Q"
>
> This fetches ImplicationScope links.
>
> If the following
>
> (ImplicationScope
>(Variable "$X")
>(Variable "$P")
>(Variable "$Q"))
>
> happen to be alpha-equivalent to something with different variable names it
> will render the Bind link invalid.
>
> Indeed alpha-conversion shouldn't be triggered in that case, the right idea
> is that the ImplicationScope, when quoted corresponds to a DIFFERENT atom
> than the one not being quoted. Also of course if we decide to not perform
> systematic alpha-conversion then this problem doesn't arise.
>
> I'm re-iterating my question. Do we really want automatic alpha-conversion
> to begin with?
>
> If the answer is yes then I suppose we need a way to tell that the quoted
> version is different than then unquoted version.
>
> Nil
>
>
> On 10/22/2016 03:34 AM, Ben Goertzel wrote:
>>
>> Nil,
>>
>> Just brainstorming here, but perhaps the command for adding an Atom
>> should have an option that the user can set, which determines whether
>> the results would be alpha-converted or not
>>
>> The default would be to do the alpha-conversion (which would be
>> appropriate if the variable names are say randomly generated, and thus
>> of no particular importance to the user -- the alpha conversion is
>> then just preventing odd collisions between randomly generated
>> variable names created by two different processes)
>>
>> However, if the user wants they can override this default and specify
>> "no alpha conversion", and then it is their responsibility to check
>> and be sure their chosen VariableNode names are not going to be used
>> in a way that creates some conflict ...
>>
>> This option would need to be added to Scheme, python, Haskell
>> bindings, but also to the core API for adding scoped links, I guess...
>>
>> I am only about 83.456% sure I understand the problem here...
>>
>> -- Ben
>>
>>
>>
>> On Fri, Oct 21, 2016 at 11:55 PM, 'Nil Geisweiller' via opencog
>>  wrote:
>>>
>>> Hi,
>>>
>>> I start to think that automatic alpha-conversion is evil.
>>>
>>> First let me recall what it does. Say you've added
>>>
>>> (Scope (VariableList (Variable "$X") (Variable "$Y"))
>>> (And (Variable "$X") (Variable "$Y")))
>>>
>>> and you subsequently add
>>>
>>> (Scope (And (Variable "$gold") (Variable "$silver")))
>>>
>>> then recalling the handle of that last addition, you'd get the first
>>> alpha-equ

Re: [opencog-dev] Is automatic alpha-conversion evil?

[Ben Goertzel]

Opening a GitHub issue may be a good idea, but I want to clarify that
what Nil is talking about may be a "missing, potentially useful
feature" rather than a bug per se..


On Thu, Nov 17, 2016 at 12:13 PM, Linas Vepstas  wrote:
> Look, if there is a bug, open a bug report. I'm nervous about these kind of
> blanket statements about what's best and what is not best.  The atomspace is
> already complicated, adding more complexity to it is not a solution.
>
> --linas
>
> On Wed, Nov 16, 2016 at 8:27 PM, Ben Goertzel  wrote:
>>
>> Nil,
>>
>> I just reviewed our dialogue on this from a year ago...
>>
>> It seems what we provisionally concluded there was that the chainer
>> should do alpha-conversion on the fly in the course of pattern
>> matching ... but that the Atomspace shouldn't do alpha-conversion
>> "automatically" in any other sense [unless we want to add some Reduct
>> type engine on the Atomspace, which could do alpha-conversion along
>> with other normalizations, but that becomes a separate issue]
>>
>> We also discussed a cog-new-var command that could be used to minimize
>> the complexities of alpha-conversions... (via reducing the incidence
>> of redundant variable names)
>>
>> In this case, the alpha-conversion done by the chainer in the course
>> of doing its business, would need to handle LocalQuoteLink
>> correctly...
>>
>> The choice of the chainer to do alpha-conversion but not (yet) more
>> general types of reduction, would be made because alpha-conversion is
>> cheaper and easier and of such broad utility.   Later versions of the
>> chainer might do more general reductions as part of their ordinary
>> business, as well...
>>
>> I may be missing something; a year ago when William and I were talking
>> about this, my head was fully immersed in the problem, but it's less
>> the case right now...
>>
>> -- Ben
>>
>>
>>
>>
>> On Wed, Nov 16, 2016 at 8:34 PM, 'Nil Geisweiller' via opencog
>>  wrote:
>> > I'm back to this issue.
>> >
>> > The notion of LocalQuote is indeed incompatible with systematic
>> > alpha-conversion.
>> >
>> > Consider this pattern
>> >
>> > (Get
>> >(VariableList
>> >   (TypedVariable
>> >  (Variable "$X")
>> >  (Type "TypedVariableLink"))
>> >   (TypedVariable
>> >  (Variable "$P")
>> >  (Type "PredicateNode"))
>> >   (TypedVariable
>> >  (Variable "$Q")
>> >  (Type "PredicateNode"))
>> >(LocalQuote
>> >   (ImplicationScope
>> >  (Variable "$X")
>> >  (Variable "$P")
>> >  (Variable "$Q"
>> >
>> > This fetches ImplicationScope links.
>> >
>> > If the following
>> >
>> > (ImplicationScope
>> >(Variable "$X")
>> >(Variable "$P")
>> >(Variable "$Q"))
>> >
>> > happen to be alpha-equivalent to something with different variable names
>> > it
>> > will render the Bind link invalid.
>> >
>> > Indeed alpha-conversion shouldn't be triggered in that case, the right
>> > idea
>> > is that the ImplicationScope, when quoted corresponds to a DIFFERENT
>> > atom
>> > than the one not being quoted. Also of course if we decide to not
>> > perform
>> > systematic alpha-conversion then this problem doesn't arise.
>> >
>> > I'm re-iterating my question. Do we really want automatic
>> > alpha-conversion
>> > to begin with?
>> >
>> > If the answer is yes then I suppose we need a way to tell that the
>> > quoted
>> > version is different than then unquoted version.
>> >
>> > Nil
>> >
>> >
>> > On 10/22/2016 03:34 AM, Ben Goertzel wrote:
>> >>
>> >> Nil,
>> >>
>> >> Just brainstorming here, but perhaps the command for adding an Atom
>> >> should have an option that the user can set, which determines whether
>> >> the results would be alpha-converted or not
>> >>
>> >> The default would be to do the alpha-conversion (which would be
>> >> appropriate if the variable names are say randomly generated, and thus
>> >> of no particular impor

Re: [opencog-dev] Is automatic alpha-conversion evil?

[Ben Goertzel]

I think our conclusion in 2015 was that processes like the chainer should
do alpha conversion on the fly... so we should supply a utility function
making it easy for anyone to invoke alpha conversion in a particular set of
atoms..

On Nov 17, 2016 3:54 PM, "'Nil Geisweiller' via opencog" <
opencog@googlegroups.com> wrote:

> The reason I didn't want to open a bug report just yet is because I wanted
> to discuss whether we really want to check alpha-equivalence whenever a new
> scope link is added to the atomspace (and subsequently consider both equal
> and return the previous one to the user).
>
> Nil
>
> On 11/17/2016 05:13 AM, Linas Vepstas wrote:
>
>> Look, if there is a bug, open a bug report. I'm nervous about these kind
>> of blanket statements about what's best and what is not best.  The
>> atomspace is already complicated, adding more complexity to it is not a
>> solution.
>>
>> --linas
>>
>> On Wed, Nov 16, 2016 at 8:27 PM, Ben Goertzel > <mailto:b...@goertzel.org>> wrote:
>>
>> Nil,
>>
>> I just reviewed our dialogue on this from a year ago...
>>
>> It seems what we provisionally concluded there was that the chainer
>> should do alpha-conversion on the fly in the course of pattern
>> matching ... but that the Atomspace shouldn't do alpha-conversion
>> "automatically" in any other sense [unless we want to add some Reduct
>> type engine on the Atomspace, which could do alpha-conversion along
>> with other normalizations, but that becomes a separate issue]
>>
>> We also discussed a cog-new-var command that could be used to minimize
>> the complexities of alpha-conversions... (via reducing the incidence
>> of redundant variable names)
>>
>> In this case, the alpha-conversion done by the chainer in the course
>> of doing its business, would need to handle LocalQuoteLink
>> correctly...
>>
>> The choice of the chainer to do alpha-conversion but not (yet) more
>> general types of reduction, would be made because alpha-conversion is
>> cheaper and easier and of such broad utility.   Later versions of the
>> chainer might do more general reductions as part of their ordinary
>> business, as well...
>>
>> I may be missing something; a year ago when William and I were talking
>> about this, my head was fully immersed in the problem, but it's less
>> the case right now...
>>
>> -- Ben
>>
>>
>>
>>
>> On Wed, Nov 16, 2016 at 8:34 PM, 'Nil Geisweiller' via opencog
>> mailto:opencog@googlegroups.com>> wrote:
>> > I'm back to this issue.
>> >
>> > The notion of LocalQuote is indeed incompatible with systematic
>> > alpha-conversion.
>> >
>> > Consider this pattern
>> >
>> > (Get
>> >(VariableList
>> >   (TypedVariable
>> >  (Variable "$X")
>> >  (Type "TypedVariableLink"))
>> >   (TypedVariable
>> >  (Variable "$P")
>> >  (Type "PredicateNode"))
>> >   (TypedVariable
>> >  (Variable "$Q")
>> >  (Type "PredicateNode"))
>> >(LocalQuote
>> >   (ImplicationScope
>> >  (Variable "$X")
>> >  (Variable "$P")
>> >  (Variable "$Q"
>> >
>> > This fetches ImplicationScope links.
>> >
>> > If the following
>> >
>> > (ImplicationScope
>> >(Variable "$X")
>> >(Variable "$P")
>> >(Variable "$Q"))
>> >
>> > happen to be alpha-equivalent to something with different variable
>> names it
>> > will render the Bind link invalid.
>> >
>> > Indeed alpha-conversion shouldn't be triggered in that case, the
>> right idea
>> > is that the ImplicationScope, when quoted corresponds to a
>> DIFFERENT atom
>> > than the one not being quoted. Also of course if we decide to not
>> perform
>> > systematic alpha-conversion then this problem doesn't arise.
>> >
>> > I'm re-iterating my question. Do we really want automatic
&

Re: [opencog-dev] Is automatic alpha-conversion evil?

[Ben Goertzel]

If the Atomspace does silently perform alpha-conversion upon Atom
insertion, I don't see why any technical problem would occur as a
result of this?

If a human inserts some VariableNodes with names that she likes, it's
obnoxious for the Atomspace to automagically rename these ... for this
reason it seems that automatic alpha-conversion on insertion is
somewhat problematic   Though I guess one could create a
workaround like

NamedVariableNode "F"

which allows creation of VariableNodes whose names won't be changed..
or we could just accept that VariableNodes may get renamed by the
system and do stuff like

ReferenceLink
 LabelNode "F"
 VariableNode "12345"

where the "12345" name can be revised by the system if it wants to...

ben




On Thu, Nov 17, 2016 at 4:51 PM, 'Nil Geisweiller' via opencog
 wrote:
>
>
> On 11/17/2016 09:09 AM, Ben Goertzel wrote:
>>
>> I think our conclusion in 2015 was that processes like the chainer
>> should do alpha conversion on the fly... so we should supply a utility
>> function making it easy for anyone to invoke alpha conversion in a
>> particular set of atoms..
>
>
> The URE does alpha-conversion whenever necessary as to avoid name capture,
> there's no problem here. The problem comes from the fact that the atomspace
> may silently perform alpha-conversion when a scope link is added, ultimately
> there are solutions to address any problem resulting from such implicit
> conversions, but I can't help it, there's a part of me that feels ambivalent
> about it...
>
> Anyway, I'll open a github issue whenever I encounter the problem I'm trying
> to describe in real life situation.
>
> Nil
>
>>
>>
>> On Nov 17, 2016 3:54 PM, "'Nil Geisweiller' via opencog"
>> mailto:opencog@googlegroups.com>> wrote:
>>
>> The reason I didn't want to open a bug report just yet is because I
>> wanted to discuss whether we really want to check alpha-equivalence
>> whenever a new scope link is added to the atomspace (and
>> subsequently consider both equal and return the previous one to the
>> user).
>>
>> Nil
>>
>> On 11/17/2016 05:13 AM, Linas Vepstas wrote:
>>
>> Look, if there is a bug, open a bug report. I'm nervous about
>> these kind
>> of blanket statements about what's best and what is not best.  The
>> atomspace is already complicated, adding more complexity to it
>> is not a
>> solution.
>>
>> --linas
>>
>> On Wed, Nov 16, 2016 at 8:27 PM, Ben Goertzel > <mailto:b...@goertzel.org>
>> <mailto:b...@goertzel.org <mailto:b...@goertzel.org>>> wrote:
>>
>> Nil,
>>
>> I just reviewed our dialogue on this from a year ago...
>>
>> It seems what we provisionally concluded there was that the
>> chainer
>> should do alpha-conversion on the fly in the course of pattern
>> matching ... but that the Atomspace shouldn't do
>> alpha-conversion
>> "automatically" in any other sense [unless we want to add
>> some Reduct
>> type engine on the Atomspace, which could do
>> alpha-conversion along
>> with other normalizations, but that becomes a separate issue]
>>
>> We also discussed a cog-new-var command that could be used
>> to minimize
>> the complexities of alpha-conversions... (via reducing the
>> incidence
>> of redundant variable names)
>>
>> In this case, the alpha-conversion done by the chainer in
>> the course
>> of doing its business, would need to handle LocalQuoteLink
>> correctly...
>>
>> The choice of the chainer to do alpha-conversion but not
>> (yet) more
>> general types of reduction, would be made because
>> alpha-conversion is
>> cheaper and easier and of such broad utility.   Later
>> versions of the
>> chainer might do more general reductions as part of their
>> ordinary
>> business, as well...
>>
>> I may be missing something; a year ago when William and I
>> were talking
>> about this, my head was fully immersed in the problem, but
>> it's less
>> the case 

Re: [opencog-dev] Extract Alternative Sentences

[Ben Goertzel]

perl ;p

On Thu, Nov 17, 2016 at 6:33 PM, Roman Treutlein  wrote:
> Hey Linas,
>
> I have the follow definition in for a Lojban Predicate:
>
> bacru: x1 utters verbally/says/phonates/speaks [vocally makes sound] x2.
>
> ignoring the things in brackets I get:
>
> x1 utters verbally/says/phonates/speaks x2.
>
> Now I would like to extract individual sentences from this:
>
> x1 utters verbally x2
> x1 says x2
> x1 phonates x2
> x1 speaks x2
>
> Do you know of any tool that allows me to do this easily?
>
> best Regards
>
> /Roman
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/6b9fa1a6-995c-44ff-9d0a-9f2c2cdfaeb4%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBedLVueMNmbF3y36jx5r-UAROfKcbrnOQZ3s-p8Jyp9tQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Extract Alternative Sentences

[Ben Goertzel]

Hi Linas,

Roman already has built a parser (in Haskell) that maps Lojban
sentences into Atomese structures

I think I know how to use this to make a replacement for RelEx2Logic,
by using a parallel English-Lojban corpus, and then using the pattern
miner to find patterns from the set of pairs of the form

 (link parser output for English sentence S,
Lojban->Atomese parser output for Lojban cognate S' of English sentence S)

What Roman is now doing is assembling the parallel English-Lojban
corpus, from various existing fragmentary parallel English-Lojban
corpora...

One of these corpora is a Lojban dictionary with definitions that look like

> x1 utters verbally/says/phonates/speaks x2.

for each Lojban word So he is simply facing the small programming
task of translating these definitions into sets of English sentences,
i.e. in the above example

> Now I would like to extract individual sentences from this:
>
> x1 utters verbally x2
> x1 says x2
> x1 phonates x2
> x1 speaks x2

This could be done using a fairly simple script but he is wondering if
there's some elegant parsing framework that could be used to deal with
the forward-slashes between phrases... I guess ...

ben



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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBeH18kkdxvQv%2BTu56zjthrnkwusaAi4Hc5O7WVmXJ9%2BHA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Extract Alternative Sentences

[Ben Goertzel]

On Fri, Nov 18, 2016 at 7:55 AM, Ben Goertzel  wrote:
> I think I know how to use this to make a replacement for RelEx2Logic,
> by using a parallel English-Lojban corpus, and then using the pattern
> miner to find patterns from the set of pairs of the form
>
>  (link parser output for English sentence S,
> Lojban->Atomese parser output for Lojban cognate S' of English sentence S)

I am going to write a couple pages explaining the above in detail,
sometime in the next week, for use by Roman and Rui Ting...

Note that if we changed to a different link grammar dictionary (e.g.
one that was learned by unsupervised learning, hint hint) then we
would just need to re-run this pattern-mining process and we'd get a
new R2L-like-system-of-transformations transforming the output from
the new link grammar dictionary into nice PLN-friendly logical
links...

ben

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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBcz3wpeeMGwJC6K%2BFKCzidqzPsjURY6qe76x5HiE6nwzQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Extract Alternative Sentences

[Ben Goertzel]

Hmm... yeah for cases like

On Fri, Nov 18, 2016 at 5:21 PM, Roman Treutlein  wrote:
> x1 is a quantity of/is made of chalk from source x2 in form x3.

either you either need to get pretty fancy or fix them by hand...

I mean, in this case "is a quantity of" happens to start with the same
word as "is made from" so you could use a heuristic based on that; but
what if you had

x1 is a quantity of/ gets made from chalk from source x2 in form x3.

Then you'd need to use grammar to tell that the phrase boundary was
around "is a quantity of" rather than around, say, "a quantity of" ...
you'd need to try various options and parse them...

A fun idea would be to replace \ with "or", so that e.g.

x1 is a quantity of/is made of chalk from source x2 in form x3.

would become

x1 is a quantity of or is made of chalk from source x2 in form x3.

But one suspects the link parser might choke on many of these perverse
sentences, and improving the link dictionary in this way would be a
lot more work than just writing a perl (or whatever) script handling
an ugly list of special cases...

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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBcQbOv7zZ9tzj-OkXbtPz4M4_EKz9fhFM6wQumJnPQbZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] How much longer?

[Ben Goertzel]

No major setbacks, no major jumps forward, just steady progress

Our current goal is to have a humanoid robot with basic
common-sensical sentience regarding itself and its environment within
3 years ... and a full human adult level AGI within 9 years 
According to my best judgment we are on track.

ben

On Sun, Nov 20, 2016 at 9:57 PM, Gaurav Gautam  wrote:
> Hi,
>
> I was just wondering if there is any revisions to the estimate of the
> timeline to achieving General Intelligence. Any major setbacks or jump
> forwards?
>
> Yours sincerely
> Gaurav Gautam
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/2691445b-d42d-4f66-9e2d-328a3a6a6188%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdX39H6cwuko-pNFQTJgMc8uUsWiE45GRqwuNp%3DOWa_GQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Link Parse to Logic via Lojban

[Ben Goertzel]

I added a lot more detail to the "Link parse to logic via Lojban" page ...

http://wiki.opencog.org/w/Link_Parse_to_Logic_via_Lojban

It's only moderately easy reading for those who aren't familiar with
Lojban, because the Lojban will look weird.   But once you get past
that, it's pretty simple... and this is the only viable approaches
I've thought of for getting rid of the R2L rules without getting rid
of a lot of functionality (until we have embodied perception and
action based learning working a lot better than we do) ...

With this plus the unsupervised link-grammar-dictionary learning Linas
is likely to work on next year, we can finally have all the large
heaps of nasty doo-doo out of OpenCog ...  and replaced with cool
stuff ;) ...


-- Ben


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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBfBi8GbUbSHU_6JSFNsL%2BcxU_6azC2NdERNjDkyzDxBHg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Link Parse to Logic via Lojban

[Ben Goertzel]

No patents are being filed on this stuff, but it's pretty clearly
being publicly disclosed on the Internet in our wiki site and our
Github repo...

I don't think anyone's gonna steal a wacky idea like this one ...
nobody outside a small circle will have interest in it till after it's
implemented and proved ... and by that point the the code will be open
for anyone to use ...

ben

On Mon, Nov 21, 2016 at 10:44 AM, Ed Pell  wrote:
> I hope you guys are filing patents or public disclosure on EVERYTHING.
>
> Ed
>
> On Sunday, November 20, 2016 at 11:24:24 AM UTC-5, Ben Goertzel wrote:
>>
>> I added a lot more detail to the "Link parse to logic via Lojban" page ...
>>
>> http://wiki.opencog.org/w/Link_Parse_to_Logic_via_Lojban
>>
>> It's only moderately easy reading for those who aren't familiar with
>> Lojban, because the Lojban will look weird.   But once you get past
>> that, it's pretty simple... and this is the only viable approaches
>> I've thought of for getting rid of the R2L rules without getting rid
>> of a lot of functionality (until we have embodied perception and
>> action based learning working a lot better than we do) ...
>>
>> With this plus the unsupervised link-grammar-dictionary learning Linas
>> is likely to work on next year, we can finally have all the large
>> heaps of nasty doo-doo out of OpenCog ...  and replaced with cool
>> stuff ;) ...
>>
>>
>> -- Ben
>>
>>
>> --
>> Ben Goertzel, PhD
>> http://goertzel.org
>>
>> “I tell my students, when you go to these meetings, see what direction
>> everyone is headed, so you can go in the opposite direction. Don’t
>> polish the brass on the bandwagon.” – V. S. Ramachandran
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/5d2e1c77-1fd5-418a-b03a-7949f0bfaf3f%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBdM3Aax5RWRoqGsTPA27HKzY9WXugQhmcMukjDZbzmrDg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Trying to understand how solving TruthQuery works

[Ben Goertzel]

ot;)
>> >   (DefinedLinguisticConceptNode "past_infinitive")
>> >)
>> > )
>> > )
>> >
>> > |
>> >
>> >
>> > Soo, about this part:
>> >
>> > |
>> > (EvaluationLink
>> >   (DefinedLinguisticPredicateNode "Truth Value")
>> >   (EvaluationLink
>> >  (PredicateNode
>> > "win@72e29756-e848-4eb8-8924-407072e74d5e")
>> >   )
>> >   (VariableNode "$O1UKaXxsl6dTKvIOxy67sJqT5cVPhF4uSq6o")
>> >)
>> > |
>> >
>> > What do the nested EvaluationLink here mean?
>> >
>> > And what steps will the bc follow to ground the variable to this
>> > (if that's how it works):
>> >
>> > |
>> > (EvaluationLink
>> >   (PredicateNode
>> > "won@349785b2-b0c2-4feb-bd51-29d7fffefc73")
>> >   (ListLink
>> >  (ConceptNode
>> > "Japan@2d483477-9a2d-4049-968f-8f7120f43e51")
>> >  (ConceptNode
>> > "game@85e71213-577b-4aa2-8412-da49e62ba2f4")
>> >   )
>> >)
>> >     |
>> >
>> >
>> > I appreciate any help on this! (and sorry if these are trivial
>> > things)
>> >
>> > --
>> > 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
>> > <mailto:opencog+u...@googlegroups.com>.
>> > To post to this group, send email to ope...@googlegroups.com
>> > <mailto:ope...@googlegroups.com>.
>> > Visit this group at https://groups.google.com/group/opencog
>> > <https://groups.google.com/group/opencog>.
>> > To view this discussion on the web visit
>> >
>> > https://groups.google.com/d/msgid/opencog/a1e990db-df73-4372-8ef5-0931a0a8cb69%40googlegroups.com
>> >
>> > <https://groups.google.com/d/msgid/opencog/a1e990db-df73-4372-8ef5-0931a0a8cb69%40googlegroups.com?utm_medium=email&utm_source=footer>.
>> > For more options, visit https://groups.google.com/d/optout
>> > <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+u...@googlegroups.com
>> > <mailto:opencog+u...@googlegroups.com>.
>> > To post to this group, send email to ope...@googlegroups.com
>> > <mailto: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/CAHrUA35K0Rrz%3DoCGgE8j%2BO3nRip3%2Bv2OWPretcEuXXkU7zEAwA%40mail.gmail.com
>> >
>> > <https://groups.google.com/d/msgid/opencog/CAHrUA35K0Rrz%3DoCGgE8j%2BO3nRip3%2Bv2OWPretcEuXXkU7zEAwA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>> > 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/2cca81b3-5d2a-4ac2-adff-d8dc620bb06d%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBfZEBjRMW9%3DU-VO7gtdfwQ8O%2Bu5K5M61MJSGMs6T3htMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Making WordNode multi-lingual... ProtoAtom once again...

[Ben Goertzel]

As we embark on more seriously using Lojban within OpenCog... and
prepare to embark on putting Chinese there ... I have realized it may
be bad that WordNode currently is language-independent...

I guess this is probably not the right design (and is a reflection of
the fact that we've only dealt with English in the Atomspace so
far)...

A short-term hack to fix this would be to introduce e.g.
EnglishWordNode, ChineseWordNode, etc. as subtypes of WordNode.

A less annoying fix ("annoying" because the proliferation of
hard-wired Atom types is annoying) would be to complete the ProtoAtom
implementation (not fundamentally hard to do, just tedious), which
would allow us to have ProtoAtoms indicating "English" and "Chinese"
etc. and link them from WordNodes to indicate the language they
correspond to

We should discuss moving forward on ProtoAtom during the Cogathon...




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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBfNLBSjv1HOGVF8yO9MUxkzm1RhkepOLmapvhJT8s%3DUkA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Making WordNode multi-lingual... ProtoAtom once again...

[Ben Goertzel]

It just seems like a huge waste of memory to have that EvaluationLink
and PredicateNode for every word in the dictionary (and also a minor
waste of processing time following those links)... this is the sort of
wastage that ProtoAtom should be good at eliminating...

Let's take time to discuss the "momentous" decisions you  mention
regarding ProtoAtom while you're in HK this time around...

ben



On Tue, Nov 22, 2016 at 11:47 AM, Linas Vepstas  wrote:
> Hi Ben,
>
> Can you explain why you need to have a ChineseWordNode?
>
> A simpler solution is to use EvaluationLinks, as normal:
>
> e.g.
> EvaluatinoLink
>   PredicateNode "Cantonese"
>   ListLink
> WordNode "jau mou wifi-aaa"
>
> which has the same form as marking the tense, number, mood, etc. of the
> word.
>
> Finishing the protoatom work is not "tedious"; rather, there are a few
> remaining important architectural issues that need to be decided on. They
> are not simple decisions, they've got some strong pro& cons reprecussions,
> which is why that work was deferred.  They're decidable, but they are
> "momentous".
>
> --linas
>
>
> On Mon, Nov 21, 2016 at 7:16 PM, Ben Goertzel  wrote:
>>
>> As we embark on more seriously using Lojban within OpenCog... and
>> prepare to embark on putting Chinese there ... I have realized it may
>> be bad that WordNode currently is language-independent...
>>
>> I guess this is probably not the right design (and is a reflection of
>> the fact that we've only dealt with English in the Atomspace so
>> far)...
>>
>> A short-term hack to fix this would be to introduce e.g.
>> EnglishWordNode, ChineseWordNode, etc. as subtypes of WordNode.
>>
>> A less annoying fix ("annoying" because the proliferation of
>> hard-wired Atom types is annoying) would be to complete the ProtoAtom
>> implementation (not fundamentally hard to do, just tedious), which
>> would allow us to have ProtoAtoms indicating "English" and "Chinese"
>> etc. and link them from WordNodes to indicate the language they
>> correspond to
>>
>> We should discuss moving forward on ProtoAtom during the Cogathon...
>>
>>
>>
>>
>> --
>> Ben Goertzel, PhD
>> http://goertzel.org
>>
>> “I tell my students, when you go to these meetings, see what direction
>> everyone is headed, so you can go in the opposite direction. Don’t
>> polish the brass on the bandwagon.” – V. S. Ramachandran
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To post to this group, send email to opencog@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/CACYTDBfNLBSjv1HOGVF8yO9MUxkzm1RhkepOLmapvhJT8s%3DUkA%40mail.gmail.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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/CAHrUA37-02HtUrUTJc43vDK%2BbH-KeqRJY-1T_%2B3eXkZC3y_yHA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBcuAJ0YnXyrj3_Yw8MNhm8R2cMEy44TVaO65-%2BBWRRkxw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Making WordNode multi-lingual... ProtoAtom once again...

[Ben Goertzel]

After some discussion at the office yesterday, I realized that having
ProtoAtom would allow us to reduce the memory footprint of stuff like

EvaluationLink
 PredicateNode "English"
 WordNode "dumbass"

or

MemberLink
WordNode "dumbass"
ConceptNode "English words"

or whatever...

If TVs and AVs were implemented as ProtoAtoms, then they would be
optional, so we could create some MemberLInks e.g. without them

This would just require various cognitive process to know what to do
when encountering an Atom with no TV or AV

For example:

-- PLN could assume, when encountering a MemberLink or EvaluationLink
with no TV, that a certain default TV (perhaps (1,1) ) should be
assumed

-- ECAN could have its forgetting agent and all its other agents
ignore Atoms with no AV... except that when an Atom A is forgotten,
all the links coming out of A that have no AV are also forgotten

So rather than having "English" as a property be a ProtoAtom, we would
have "English" as a property connected to the WordNode for an English
word with a very lightweight link, indicating the fact that we don't
want to bother doing reasoning or attention allocation on this
link

This is not a huge point in the end, but it's one among many examples
of the flexibility that would come from putting TV and AV in the
Atomspace instead of having them as hard-coded structures...

-- Ben

On Tue, Nov 22, 2016 at 12:11 PM, Ben Goertzel  wrote:
> It just seems like a huge waste of memory to have that EvaluationLink
> and PredicateNode for every word in the dictionary (and also a minor
> waste of processing time following those links)... this is the sort of
> wastage that ProtoAtom should be good at eliminating...
>
> Let's take time to discuss the "momentous" decisions you  mention
> regarding ProtoAtom while you're in HK this time around...
>
> ben
>
>
>
> On Tue, Nov 22, 2016 at 11:47 AM, Linas Vepstas  
> wrote:
>> Hi Ben,
>>
>> Can you explain why you need to have a ChineseWordNode?
>>
>> A simpler solution is to use EvaluationLinks, as normal:
>>
>> e.g.
>> EvaluatinoLink
>>   PredicateNode "Cantonese"
>>   ListLink
>> WordNode "jau mou wifi-aaa"
>>
>> which has the same form as marking the tense, number, mood, etc. of the
>> word.
>>
>> Finishing the protoatom work is not "tedious"; rather, there are a few
>> remaining important architectural issues that need to be decided on. They
>> are not simple decisions, they've got some strong pro& cons reprecussions,
>> which is why that work was deferred.  They're decidable, but they are
>> "momentous".
>>
>> --linas
>>
>>
>> On Mon, Nov 21, 2016 at 7:16 PM, Ben Goertzel  wrote:
>>>
>>> As we embark on more seriously using Lojban within OpenCog... and
>>> prepare to embark on putting Chinese there ... I have realized it may
>>> be bad that WordNode currently is language-independent...
>>>
>>> I guess this is probably not the right design (and is a reflection of
>>> the fact that we've only dealt with English in the Atomspace so
>>> far)...
>>>
>>> A short-term hack to fix this would be to introduce e.g.
>>> EnglishWordNode, ChineseWordNode, etc. as subtypes of WordNode.
>>>
>>> A less annoying fix ("annoying" because the proliferation of
>>> hard-wired Atom types is annoying) would be to complete the ProtoAtom
>>> implementation (not fundamentally hard to do, just tedious), which
>>> would allow us to have ProtoAtoms indicating "English" and "Chinese"
>>> etc. and link them from WordNodes to indicate the language they
>>> correspond to
>>>
>>> We should discuss moving forward on ProtoAtom during the Cogathon...
>>>
>>>
>>>
>>>
>>> --
>>> Ben Goertzel, PhD
>>> http://goertzel.org
>>>
>>> “I tell my students, when you go to these meetings, see what direction
>>> everyone is headed, so you can go in the opposite direction. Don’t
>>> polish the brass on the bandwagon.” – V. S. Ramachandran
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To post to this group, send email to opencog@googlegroups.com.
>>> Visit this group at https://groups.google.com/g

Re: [opencog-dev] project recommendation

[Ben Goertzel]

Doing something interesting/useful with the existing and working, but
little-utilized, concept blending code (and extending this code along
the way) would be a good project for someone with significant
experience/knowledge and 10 hrs/ week to contribute...

On Sat, Nov 26, 2016 at 11:53 PM,   wrote:
> Hi Ben,
>
> I just finished reading AGI revolution. I really liked its breadth and
> optimism. I have an undergrad and masters degree in Computer Science and
> have taken AI/Machine learning courses in the masters program I was in about
> 6 years ago. However, I have not applied that knowledge in my work since
> then.
>
> The concept that interests me the most is creativity. I see a post on
> Cogistry that looks really interesting but it seems to be a new idea that
> may not be ready to be implemented yet? Also I see concept blending here at
> http://wiki.opencog.org/w/Ideas#Concept_Formation. I thought this had
> already been worked on in the past though?
>
> Any ideas of what I can work on concerning creativity? Ideally I would like
> to work as part of a team. Since I work full time now, I have about 10 hours
> a week I can contribute.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/844b619c-dfcf-47ed-b767-0c4192b5d4e9%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBcDmE0WTgLVRixQXuDgG9Tvp%2B9YME-2NQYokfS3mG2fPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] ConceptNode lojban gibberish

[Ben Goertzel]

I believe it's an instance node, which we'd normally write as

PredicateNode "mi'arpe'u_123"

or some such...

On Wed, Nov 30, 2016 at 6:58 PM, 'Nil Geisweiller' via opencog
 wrote:
> Just read http://wiki.opencog.org/w/Link_Parse_to_Logic_via_Lojban the
> proposal looks awesome to me.
>
> Just curious, where the prefix gibberish of node names such as
>
> PredicateNode (stv 1.0 0.0) "nMtuPfmIJBTgtPV),5on___mi'arpe'u"
>
> come from?
>
> Also it occurs to me that the pattern miner can be seen as a big ass PLN
> rule, and thus should be callable by the BC (or an adequately customized
> version of it), as opposed to be solely used in conjunction with the FC as
> described.
>
> Nil
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/4bbdb5aa-c2b6-1791-bb2a-425180c6de9b%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.



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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBf3YLutKQ0fqfyj8gyD8KqLv3PE4nsKD_gND3wcAPob0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] surprisingness regarding constant terms

[Ben Goertzel]

Amen,

Here is a quick write-up of the idea regarding surprisingness I
mentioned at the office today...

Suppose we have an Atom-expression without variables, and want to
evaluate its surprisingness.   Or, suppose we have an expression with
variables, but want to evaluate its surprisingness with respect to the
constant terms it contains.

Some examples of such expressions would be

1)
Inheritance Amen man

2)
Inheritance Amen smokes

3)
AND
   Inheritance Amen man
   Inheritance Amen genius

4)
AND
   Inheritance Amen $X
   Inheritance Ben $X
   EvaluationLink
  PredicateNode “understands”
  ConceptNode “Bob”
  VariableNode $X

5)
Inheritance Amen Amen


I suggest that one way to evaluate the surprisingness in such a case is:

For each constant term T (or in general, each combination of terms) in
the expression:

— create a modified version of the expression, in which that term (or
term-set) T is replaced with a variable  V_T

— determine an appropriate context C_T for V_T

— calculate the surprisingness of the expression’s truth-value
relative to C_T for V_T

The surprisingness of the expression can then be evaluated as the sum
of the surprisingness values for the terms.   So, if there is any term
for which “templatizing” on that term (replacing that term with a
variable) produces surprisingness, the expression as a whole is
considered surprising to a certain degree.

For instance

Inheritance Amen smokes

could be modified into

Inheritance $V_Amen smokes

and if the context for $V_Amen is chosen as Human, then the
surprisingness would be calculated by comparing the truth value of

Inheritance Amen smokes

to that of

Inheritance Human smokes

By this method

Inheritance Amen smokes

becomes evaluated as more surprising than

Inheritance Amen man

On the other hand,

Inheritance Amen Amen

is evaluated as completely unsurprising, no matter what the context,
because for any context the truth value of

Inheritance $V_Amen $V_Amen

is 1, which is the same as the truth value of

Inheritance Amen Amen

Example 4) above can be used to illustrate the more advanced case
mentioned above, in which one templatizes sets of terms rather than
individual terms.  One could look at

AND
   Inheritance $V_Amen $X
   Inheritance $V_Ben $X
   EvaluationLink
  PredicateNode “understands”
  ConceptNode “Bob”
  VariableNode $X

and then consider the context for the pair ($V_Amen, $V_Ben) as the
pair (Human, Human), i.e. the set of pairs of humans.

For a first application it will be OK to just templatize individual
terms.  Templatizing sets of terms, however, is necessary to deal with
expressions that are only surprising in terms of the way they
interrelate two terms in respect to their relationship with other
terms.

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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBfiwPzDiBM00vE43mN%3DyZ6194X%3D3q0zaj%2B%2BT_3o-9NP%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.