Re: [opencog-dev] Contributing to Opencog

['Nil Geisweiller' via opencog]

On 10/08/2017 11:43 AM, Linas Vepstas wrote:
So, the question is: what's the base tech?  Starting with SAT solvers 
seems like too low a level.  I like answer-set programming (ASP) because 
it explicitly deals with first-order logic and therefore is a natural 
fit for PLN.  (and of course, the ASP solvers are now blazingly fast).   
A third possibility would be a theorem prover, like Coq or whatever, but 
these might be a poor fit for PLN. I dunno


They might all be OK, depending on the task. The problem I'm seeing is 
how to turn a backward chainer query *with variables* into theorem(s) in 
these formalisms.


I guess I would know how to turn

Evaluation P A

where P and A are fully defined into a Coq theorem, but what if A is 
replaced by X


Evaluation P X

and we want to find inference chains instantiating as many X so that P(X).

Can these tools do that?

I suppose ASP can. But can a general automatic prover like Coq can? I 
don't know.


I would be tempted to try first with a crisped version of PLN itself, as 
this would require almost no effort.


Of course existing tools can be a lot more efficient than crisp-PLN, at 
least for some tasks, I doubt for everything though. For that, 
ultimately nothing is gonna beat meta-learning I believe, so that would 
be my only reserve for spending time on these other tools. But I agree 
that it's a very interesting pursue.


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/9e6bc02e-7eca-512f-1c17-eb8b01c78563%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Linas Vepstas]

On Sun, Oct 8, 2017 at 1:42 PM, Amirouche Boubekki <
amirouche.boube...@gmail.com> wrote:

>
>
> On Sat, Oct 7, 2017 at 4:12 PM Linas Vepstas 
> wrote:
>
>
>> For the last ten years, I've been thinking of the atomspace as a "graph
>> database". In the last 6+ months, I'm starting to realize that this is the
>> wrong viewpoint. I think I know a better one, but it takes some explaining.
>>
>
> What is your new viewpoint?
>

This one:  https://github.com/opencog/atomspace/tree/master/opencog/sheaf

I quote:

... a simple and convenient mechanism for working with graphs "locally", by
making the nearest-neighbors of a vertex apparent.

The traditional textbook-canonical way of specifying a graph is to state
that it is a set of vertexes, and a set of edges that connect pairs of
vertexes. The problem with this description is that given any vertex, one
has no idea of what edges are connected to it, without scanning the entire
set of edges. Another problem is that vertexes and edges are not
composable; that is, when they are composed together, they are no longer
vertexes or edges, but a more general type: a "subgraph". By contrast,
sheaves carry local information, and are composable.

Given a vertex V, a "section" is defined as a set of pairs (V,E) of that
vertex V and all edges E that are attached to it. That's it! Very simple! A
section can be envisioned as a "spider", with the vertex V as the body of
the spider, and the edges as the legs of the spider.

Sections are composable, in that several can be connected together by
joining ("connecting") edges. The result is still a section, in that it has
a central blob as the spider-body, and a whole bunch of legs sticking out.
Composing sections in such a way that the edges connect only in legal ways
is called "parsing".

Another way of visualizing sections is to envision a jigsaw-puzzle piece
instead of a spider. The vertex V is a label on the puzzle-piece, and each
leg is a tab or slot on the puzzle-piece. The tabs or slots are now
obviously connectors: this emphasizes that jigsaw-puzzle pieces can be
connected together legally only when the connectors fit together. Again:
the act of fitting together puzzle-pieces in a legal fashion is termed
"parsing".

In standard mathematical terminology, the spider-body or jigsaw-label is
called the "germ". It is meant to evoke the idea of a germinating seed, as
will become clear below.

Diagramatic illustrations of jig-saw puzzle-pieces can be found here:

   - Sleator, Temperley, Parsing English with a Link Grammar
   

   - Bob Coeke, New Scientist: Quantum Links Let Computers Read
   


--linas

-- 
*"The problem is not that artificial intelligence will get too smart and
take over the world," computer scientist Pedro Domingos writes, "the
problem is that it's too stupid and already has." *

-- 
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/CAHrUA36MpPL1e_3TPq0k%2BBwrKwA%2B_w0oF45DczGSPxiXnmVEug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Linas Vepstas]

On Sun, Oct 8, 2017 at 10:54 AM, Nil Geisweiller 
wrote:

> On 10/07/2017 04:39 PM, Linas Vepstas wrote> So here's a completely
> different but related idea:  First, use a crisp
>
>> reasoner to deduce what happens whenever strength>0..  Next, do it
>> again, but now for strength>0.8.  (but still using the crisp reasoner: just
>> take strength>0.8 to mean "true"). This should have a "broader" set of
>> consequences.  Do it again for strength>0.6 - this causes even more
>> possibilities to be explored.
>>
>> It seems like these three cases can be treated as "lower bounds" of what
>> we might expect PLN to find.   That these could be used to guide/limit what
>> PLN explores.
>>
>> Alternately, if this was fast enough, you could do this 100 times for 100
>> different truth cutoffs, and build up a distributional TV...
>>
>
> That's an interesting idea. You could
>
> 1. Sample the probability of each atom in the KB (axioms) according to
> their TV
> 2. Sample, according to this probabilities, whether the axiom is true or
> false
> 3. Run crisp-PLN over the dicretized theory, save the output
> 4. repeat 2. N times to obtain a probability of the output
> 5. repeat 1. M times to obtain a second order probability to regenerate
> the output TV
>
> I suppose this type of crisp-PLN monte-carlos simulation should converge
> to PLN. The advantage could be real though, assuming PLN complexity grows
> with exp(alpha*L), and the complexity of crisp-PLN grows with exp(beta*L),
> with beta < alpha, L being the length of the proof, we'd reach a point
> where where M*N*exp(beta*L) < exp(alpha*L).
>


Ah, well, in this rephrasing, you've converted it into a
probabilisitic-programming problem.  I recall both you and I were at AGI
2015 and there were several papers on this, and clearly work stretching
back a decade or more ... but that work, those papers were always focused
on programming languages, and not on logic.  I want to smack my forehead
and say "but of course!" and wonder/marvel how it is that this hasn't been
done before (maybe it has been, and we don't know?)

Ben was mumbling something to me about adding probabilistic programming to
opencog, but I did not understand what he was trying to achieve.  This, by
contrast, seems to be a well-defined, well-contained problem, which could
give some decent results.  It also has the benefit of allowing you to start
with low values of M,N to get a rough estimate, and refine over time.

So, the question is: what's the base tech?  Starting with SAT solvers seems
like too low a level.  I like answer-set programming (ASP) because I know
it well, and it explicitly deals with first-order logic and therefore is a
natural fit for PLN.  (and of course, the ASP solvers are now blazingly
fast).   A third possibility would be a theorem prover, like Coq or
whatever,

>
> Certainly an idea to keep in mind.
>
> Nil
>
>
>
>> I find this idea exciting!  It seems plausible, doable ...
>>
>> --linas
>>
>>
>>
>> Nil
>>
>>


-- 
*"The problem is not that artificial intelligence will get too smart and
take over the world," computer scientist Pedro Domingos writes, "the
problem is that it's too stupid and already has." *

-- 
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/CAHrUA37O-3VsYdCap_9FQzfiWm5rRrqZF7FnT%3DTa4_8DBtiO%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Amirouche Boubekki]

On Sat, Oct 7, 2017 at 4:12 PM Linas Vepstas  wrote:


> For the last ten years, I've been thinking of the atomspace as a "graph
> database". In the last 6+ months, I'm starting to realize that this is the
> wrong viewpoint. I think I know a better one, but it takes some explaining.
>

What is your new viewpoint?

-- 
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/CAL7_Mo-nDMHGkcPgUvzkQHVkaapzeKHfKm8%2BX2LR_%2BaLzLpTmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to OpenCog

[Linas Vepstas]

On Sat, Oct 7, 2017 at 3:34 PM, Mark Waser  wrote:

>
>
> I’ve read this mailing list for years.  It seems that the repo being
> broken is far, far more common than not.
>

Perhaps it seems that way, but its false.  In actual fact, over the course
of the last ten years, the repo has been broken about a dozen times, never
for more than a day or two, and of those breakages, perhaps only one has
been reported on  the mailing list.

The reports you see on the mailing list are always "user errors". The one
from two days ago is infuriatingly egregious.  The user apparently didn't
know what gcc was. What can you do with people like that?  From their point
of view, its all very broken, but that is not the reality.

The only viable audience for opencog, at this time, are developers with
extensive knowledge & interest in AI.  College students, even grad
students, encountering Linux and programming for the first time in their
lives, and struggling with it, do not count.  A class or two in java
programming does not making one a programmer.

Working with software is like playing the piano. Anyone can do it.  You
just hit the keys, and sounds come out.

--linas

-- 
*"The problem is not that artificial intelligence will get too smart and
take over the world," computer scientist Pedro Domingos writes, "the
problem is that it's too stupid and already has." *

-- 
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/CAHrUA36tb9620-g%2BaLH7auEwRuEoVEDt%3DykCX3-o2_YFT_T-YA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Linas Vepstas]

Hi Curtis,

On Sun, Oct 8, 2017 at 11:15 AM, Curtis Michael Faith <
curtis.m.fa...@gmail.com> wrote:

>
>
> 3) We should be thinking of semantic flows instead of the atoms of state
> that result from changes in flows. Semantic flows represent isomorphisms of
> state applied to a sub-graph.
>

Not to make your head explode, or anything like that, but there is some
synchronicity in the universe.  Yesterday's news includes an obit for *Vladimir
Voevodsky https://plus.google.com/u/0/+johncbaez999/posts/VhWp7s1PYp3
 *which
contains remarks similar in flavor: "infinity-groupoids are sets in the
next dimension".

Voevodsky is known for instigating work on the HoTT book -- Homotopy Type
Theory -- which basically shows how computer programs, logical proofs and
similar "discrete" networks can be "continuously" transformed
homotopically, isomorphically into one-another.  It is this work that has
revolutinzed theorem provers (such as Coq, or Ben's favorite, Agda) in
mathematics.  I've been trying to steal ideas from that general area and
apply them to opencog/atomese.

The book is free, and anyone interested in what a "type" is should read at
least the first few chapters. The types of that book are more-or-less
exactly the same thing as the types in opencog, or the types in
link-grammar.



> This happens to be the starting point for SingulairyNET agents. What flows
> in as data and what flows out as results? So we are working on this problem
> at the high-level while I and others are thinking about how best to
> represent the abstract constructs definable in atomese.
>

I promised earlier to write a smart contract in atomese, and I haven't
forgotten that promise. The current stumbling block is how to define a
container in atomese. (a container being a secure "sandbox" in which crypto
operations can be safely performed away from the eyes of spies.)

>
> In many ways, I see these times for AGI as akin to the early days of
> programming when we first made the jump from machine language to assembly
> language and then we got C and Fortran and Cobol, with the semantics tied
> much more closely and directly to the problem domain: whether systems- or
> scientific- or business-programming.
>
> So I see OpenCog Atomese as the assembly code for Sophia's mind. We want
> it to stay flexible because we do not want to limit what is possible. But
> it is too much work to write in assembly all the time. we need compressions
> of complexity and a higher-level form for more efficient and expressive
> work at higher levels.
>
> We have not yet built, anyone anywhere yet, the semantic analog to C for
> AI, let alone the more modern variants like Go, Rust, Swift or even Python.
>

Yes.

--linas


> There is an impedance mismatch between the ways that current
> batch-oriented Von-Neumann bottlenecked systems run and the ideal ways that
> a mind wants to learn in parallel. There is a greater need for efficient
> shared semantic context among the many parts communicating. There is a
> greater need for visualization into the implications and nuanced semantics
> implied by the connections.
>
> Much work to be done but all identified and doable.
>
>
>

-- 
*"The problem is not that artificial intelligence will get too smart and
take over the world," computer scientist Pedro Domingos writes, "the
problem is that it's too stupid and already has." *

-- 
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/CAHrUA34QFFnWui1VhKUJY%2Bye6t85Va3kew%2BXj5QzC39iq9%2BsYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Linas Vepstas]

On Sun, Oct 8, 2017 at 10:54 AM, Nil Geisweiller 
wrote:

> On 10/07/2017 04:39 PM, Linas Vepstas wrote> So here's a completely
> different but related idea:  First, use a crisp
>
>> reasoner to deduce what happens whenever strength>0..  Next, do it
>> again, but now for strength>0.8.  (but still using the crisp reasoner: just
>> take strength>0.8 to mean "true"). This should have a "broader" set of
>> consequences.  Do it again for strength>0.6 - this causes even more
>> possibilities to be explored.
>>
>> It seems like these three cases can be treated as "lower bounds" of what
>> we might expect PLN to find.   That these could be used to guide/limit what
>> PLN explores.
>>
>> Alternately, if this was fast enough, you could do this 100 times for 100
>> different truth cutoffs, and build up a distributional TV...
>>
>
> That's an interesting idea. You could
>
> 1. Sample the probability of each atom in the KB (axioms) according to
> their TV
> 2. Sample, according to this probabilities, whether the axiom is true or
> false
> 3. Run crisp-PLN over the dicretized theory, save the output
> 4. repeat 2. N times to obtain a probability of the output
> 5. repeat 1. M times to obtain a second order probability to regenerate
> the output TV
>
> I suppose this type of crisp-PLN monte-carlos simulation should converge
> to PLN. The advantage could be real though, assuming PLN complexity grows
> with exp(alpha*L), and the complexity of crisp-PLN grows with exp(beta*L),
> with beta < alpha, L being the length of the proof, we'd reach a point
> where where M*N*exp(beta*L) < exp(alpha*L).
>


Ah, well, in this rephrasing, you've converted it into a
probabilisitic-programming problem.  I recall both you and I were at AGI
2015 and there were several papers on this, and clearly work stretching
back a decade or more ... but that work, those papers were always focused
on programming languages, and not on logic.  I want to smack my forehead
and say "but of course!" and wonder/marvel how it is that this hasn't been
done before (maybe it has been, and we don't know?)

Ben was mumbling something to me about adding probabilistic programming to
opencog, but I did not understand what he was trying to achieve.  This, by
contrast, seems to be a well-defined, well-contained problem, which could
give some decent results.  It also has the benefit of allowing you to start
with low values of M,N to get a rough estimate, and refine over time.

So, the question is: what's the base tech?  Starting with SAT solvers seems
like too low a level.  I like answer-set programming (ASP) because it
explicitly deals with first-order logic and therefore is a natural fit for
PLN.  (and of course, the ASP solvers are now blazingly fast).   A third
possibility would be a theorem prover, like Coq or whatever, but these
might be a poor fit for PLN. I dunno.

>
> Certainly an idea to keep in mind.


More, my knee-jerk reastion is to say "its an idea we should prusue".

To return to the original thread: in pursuing this idea, how much of it
should be developed as in "independent module", and how much should be
integrated with opencog?   Certainly, it would be dumb to re-invent atoms
yet again, but the idea of a stand-alone module seems to ask for that.

--linas

>
>
> Nil
>
>
>
>> I find this idea exciting!  It seems plausible, doable ...
>>
>> --linas
>>
>>
>>
>> Nil
>>
>>


-- 
*"The problem is not that artificial intelligence will get too smart and
take over the world," computer scientist Pedro Domingos writes, "the
problem is that it's too stupid and already has." *

-- 
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/CAHrUA35D6dfy0YOXckfAxQ8oNf-sg3jWvvCxNDZMaurBxx1qyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

['Nil Geisweiller' via opencog]

On 10/07/2017 04:39 PM, Linas Vepstas wrote> So here's a completely 
different but related idea:  First, use a crisp
reasoner to deduce what happens whenever strength>0..  Next, do it 
again, but now for strength>0.8.  (but still using the crisp reasoner: 
just take strength>0.8 to mean "true"). This should have a "broader" set 
of consequences.  Do it again for strength>0.6 - this causes even more 
possibilities to be explored.


It seems like these three cases can be treated as "lower bounds" of what 
we might expect PLN to find.   That these could be used to guide/limit 
what PLN explores.


Alternately, if this was fast enough, you could do this 100 times for 
100 different truth cutoffs, and build up a distributional TV...


That's an interesting idea. You could

1. Sample the probability of each atom in the KB (axioms) according to 
their TV
2. Sample, according to this probabilities, whether the axiom is true or 
false

3. Run crisp-PLN over the dicretized theory, save the output
4. repeat 2. N times to obtain a probability of the output
5. repeat 1. M times to obtain a second order probability to regenerate 
the output TV


I suppose this type of crisp-PLN monte-carlos simulation should converge 
to PLN. The advantage could be real though, assuming PLN complexity 
grows with exp(alpha*L), and the complexity of crisp-PLN grows with 
exp(beta*L), with beta < alpha, L being the length of the proof, we'd 
reach a point where where M*N*exp(beta*L) < exp(alpha*L).


Certainly an idea to keep in mind.

Nil



I find this idea exciting!  It seems plausible, doable ...

--linas



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/cdce29bd-ab2b-01cb-aa24-9fe16d7d2272%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to OpenCog

[Ben Goertzel]

We haven't done a great job of keeping OpenCog friendly and usable as
a general opensource tool for the world at large, nor at making it
approachable to developers outside our close community...

Pretty much, a close group of people have been using OpenCog for
various applications and contributing to the generic OpenCog codebase
along the way   The code has been kept open source and some effort
has been made to keep the code documented and to keep a wiki up to
date, but the project hasn't really been run or maintained in a way
oriented toward fostering a developer community   This has not
been due to a lack of interest in fostering a developer community, but
just due to the core people involved being perennially swamped with
other stuff...

Indeed, nobody has been actively managing OpenCog as a general OSS
project.   Folks have been maintaining the codebase and repos (Linas,
Amen, Nil, etc.) but some mess has been tolerated there so long as it
doesn't stop our applications from working...

I'm certainly not opposed to project management in general -- e.g. we
have just hired a new software project manager for Hanson Robotics;
and my new SingularityNET project has pretty structured project
management.   It's just a fact that so far there has not been funding
to hire a good project manager for OpenCog as a general OSS project,
and nobody with the right mindset and skillset has emerged to do this
on a volunteer basis (and it's not a very easy job)...

-- ben

On Sat, Oct 7, 2017 at 12:34 PM, Mark Waser  wrote:
> So . . . . let me weigh in . . . .
>
>
>
> I’ve been a professional developer for 37+ years and am constantly using
> open source software for both work and personal endeavors.
>
>
>
> The *worst* thing for me is when the publicly available repo cannot be
> immediately compiled and run due to missing/incomplete instructions or
> errors.
>
>
>
> While this is nearly unavoidable once in a blue moon, it is certainly
> unacceptable when it happens on a regular basis.  It shows an incredible
> lack of professionalism -- much less a tremendous lack of respect for the
> time and effort of others.  At work, it is a termination offense.
>
>
>
> I’ve read this mailing list for years.  It seems that the repo being broken
> is far, far more common than not.
>
>
>
> The fact that the project has so many moving pieces is seriously daunting.
> The fact that you can’t even start analyzing it without repairing it is a
> total non-starter for me – and I suspect, most others, particularly
> professionals who *know* how software projects must be run to ensure
> progress and success.
>
>
>
> I had great hopes for OpenCog once – but I seems that it has done nothing
> but spin in circles except for a few (outstanding) one-programmer pieces
> (that haven’t picked up the traction they deserve because they’ve been
> anchored down by the rest).  I don’t see that changing without a serious
> upgrade in the engineering management of the project.
>
> --
> 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/01d33f68%248e9bf310%24abd3d930%24%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.



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

"I am God! I am nothing, I'm play, I am freedom, I am life. I am the
boundary, I am the peak." -- Alexander Scriabin

-- 
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/CACYTDBdOSGCK9R-Oh9DqY%3Dca2ADevW3i5_%2ByZHnAYD93jGjWXQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Linas Vepstas]

Hi Nil,

On Fri, Oct 6, 2017 at 6:30 AM, Nil Geisweiller 
wrote:

>
>
> On 10/06/2017 02:10 AM, Linas Vepstas wrote:
>
>> it would be nice to have a fast crisp prover so that the system could
>> jump to conclusions, and pln more slowly in the background.
>>
>
> Yes, even for our rule engine alone there is a benefit to that. On top of
> being faster to evaluate, crisp rules tend to have less premises than their
> probabilistic counterparts.
>
> Then the question is how to set the TV of these conclusions. If the axioms
> are crisps with (stv 1 1) or (stv 0 1), then the conclusions would be (stv
> 1 1) or (stv 0 1). But if the axioms are non-crisp, then I guess the crisp
> rules could set (stv 1 Epsilon) or (stv 0 Epsilon), just to express that
> something is possibly true or false. Or else we can create a new TV type
> for it.
>

You don't need a new TV type, You can just store it in parallel, as just
another value on an atom.  Recall that the current TV is stored by saying

atom->setValue (PredicateNode("*-TruthValueKey-*"), some_tv);

you could just store

 atom->setValue (PredicateNode("*-CrispTruthKey-*"), crisp_tv);

and look it up that way, if/when you need it, for example to provide a
"backbone" around which fuzzy explorations can be done.

So here's a completely different but related idea:  First, use a crisp
reasoner to deduce what happens whenever strength>0..  Next, do it
again, but now for strength>0.8.  (but still using the crisp reasoner: just
take strength>0.8 to mean "true"). This should have a "broader" set of
consequences.  Do it again for strength>0.6 - this causes even more
possibilities to be explored.

It seems like these three cases can be treated as "lower bounds" of what we
might expect PLN to find.   That these could be used to guide/limit what
PLN explores.

Alternately, if this was fast enough, you could do this 100 times for 100
different truth cutoffs, and build up a distributional TV...

I find this idea exciting!  It seems plausible, doable ...

--linas



> 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/CAHrUA36c9ShsmARYTzPs6JP61CPjL%2BvAz9zx4yHEG-34tkn%3DzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Contributing to OpenCog

[Mark Waser]

So . . . . let me weigh in . . . . 

 

I’ve been a professional developer for 37+ years and am constantly using open 
source software for both work and personal endeavors.  

 

The *worst* thing for me is when the publicly available repo cannot be 
immediately compiled and run due to missing/incomplete instructions or errors.

 

While this is nearly unavoidable once in a blue moon, it is certainly 
unacceptable when it happens on a regular basis.  It shows an incredible lack 
of professionalism -- much less a tremendous lack of respect for the time and 
effort of others.  At work, it is a termination offense.

 

I’ve read this mailing list for years.  It seems that the repo being broken is 
far, far more common than not.

 

The fact that the project has so many moving pieces is seriously daunting.  The 
fact that you can’t even start analyzing it without repairing it is a total 
non-starter for me – and I suspect, most others, particularly professionals who 
*know* how software projects must be run to ensure progress and success.

 

I had great hopes for OpenCog once – but I seems that it has done nothing but 
spin in circles except for a few (outstanding) one-programmer pieces (that 
haven’t picked up the traction they deserve because they’ve been anchored down 
by the rest).  I don’t see that changing without a serious upgrade in the 
engineering management of the project.

-- 
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/01d33f68%248e9bf310%24abd3d930%24%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Ben Goertzel]

Nuzz, etc.

Just to add a different but related dimension to the discussion -- the
way we are going to wrap OpenCog functionality in SingularityNET
agents is a bit different…

Each agent will carry out a specific functionality, which may be
generic or may be domain-specific

For instance

1) An inference agent may take in a set of premises (perhaps
probabilistically or fuzzily weighted) and a time limit and a range of
effort that’s OK to spend, and output a set of conclusions

2) A question-answering service may take an English-language question
as input, and a time limit and a range of effort that’s OK to spend,
and output a list of answers (which might be English language
sentences and/or URLs to relevant resources)

So the SingularityNET agents will be highly “modularized”, each one
carrying out a well-defined set of tasks (with certain input and
output types), where there is a set of ontologies and each task is
characterized by a set of terms in one or more ontologies...

Behind the scenes, however, to achieve this kind of modularization at
the “user” level (where the user could be after a particular abstract
AI functionality like logical inference, or a particular application
functionality like question answering), does not require a strict
modularity at the underlying OpenCog dynamics level.  For instance it
does not require that the interface between inference and language
processing or evolutionary learning be restricted to a simplistic
interface that hampers the flexibility of such interactions.

In short what we will do in this context is to provide a simplified
way to access (general-purpose or application-specific) *services*
implemented using OpenCog (along with many services implemented using
other tools besides OpenCog — SingularityNET will not be restricted to
OpenCog agents by any means)….  But this does not require a
commensurate simplification of the world experienced by OpenCog AI
developers (i.e. those who are contributing to rather than utilizing
OpenCog AI).

For OpenCog AI development, I think we need better debugging tools,
better visualization tools, better documentation, better tutorials,
etc.  But I am unconvinced that we can have a stricter modularization
without destroying the AGI potential of the platform.   There is a bit
of a challenge here in that the crux of AGI is the interaction and
interpenetration of different functionalities.  This does not rule out
modularity in the sense of software dependency management — one can
make the building of different AI functionalities more separate than
is currently the case.  But it does perhaps rule out making simplified
interfaces that constrain the flexibility of interaction between
different AI modules.  The different Ai modules need to interact via
their common activity updating Atomspace in real-time, and this has
just got to be a complex variety of interactions, with new aspects to
be ongoingly explored as the AGI R proceeds.

— Ben

On Fri, Oct 6, 2017 at 7:30 PM, Mark Nuzz  wrote:
> On Fri, Oct 6, 2017 at 1:37 AM, Ben Goertzel  wrote:
>> ***
>> OTOH, If modules or projects were usable in isolation, and the
>> dependencies could be effectively treated as black boxes (as most
>> software dependencies are), or even simulated/mocked, and if
>> meaningful experimentation and feedback still able to be done within
>> the narrow scope of that one module, then maybe the tutorials won't be
>> so pointless.
>> ***
>>
>> yes, I agree that narrow AI is easier than proto-AGI ... and that if
>> we put more effort into wrapping up OpenCog components so they could
>> be used as pure narrow-AI component in themselves, or for specific
>> narrow applications, then this would attract more developers toward
>> these narrow-AI applications and tools... and work on these narrow
>> applications and tools would indirectly benefit the quest for
>> OpenCog-based AGI...
>>
>> Nevertheless I feel that the bottleneck is not currently wisdom about
>> "what would be nice to do" or "what should be done" but rather the
>> lack of any resources earmarked for making these types of
>> improvements   It's not like OpenCog Foundation has a large staff
>> and budget that is being frittered away on other stuff...   Nearly all
>> current OpenCog dev is happening because of commercial projects
>> wanting to use OpenCog bits and pieces and aspects for various
>> specific purposes, and this sort of funded dev is great but doesn't
>> tend to lead to work focused on making the infrastructure easy for
>> newbies...
>>
>> Tensorflow has wonderful documentation, beautiful visualization,
>> elegant modularization, etc.  It's lovely for what it is.  How much do
>> you think Google spent on these aspects?
>>
>> ben
>>
>
> Perhaps this is close to where the real disagreement is. On one hand,
> the project is striving for modularity in the form of separate
> compilation of modules and components. On the other hand, the idea of
> having 

Re: [opencog-dev] Contributing to Opencog

[Mark Nuzz]

On Fri, Oct 6, 2017 at 1:37 AM, Ben Goertzel  wrote:
> ***
> OTOH, If modules or projects were usable in isolation, and the
> dependencies could be effectively treated as black boxes (as most
> software dependencies are), or even simulated/mocked, and if
> meaningful experimentation and feedback still able to be done within
> the narrow scope of that one module, then maybe the tutorials won't be
> so pointless.
> ***
>
> yes, I agree that narrow AI is easier than proto-AGI ... and that if
> we put more effort into wrapping up OpenCog components so they could
> be used as pure narrow-AI component in themselves, or for specific
> narrow applications, then this would attract more developers toward
> these narrow-AI applications and tools... and work on these narrow
> applications and tools would indirectly benefit the quest for
> OpenCog-based AGI...
>
> Nevertheless I feel that the bottleneck is not currently wisdom about
> "what would be nice to do" or "what should be done" but rather the
> lack of any resources earmarked for making these types of
> improvements   It's not like OpenCog Foundation has a large staff
> and budget that is being frittered away on other stuff...   Nearly all
> current OpenCog dev is happening because of commercial projects
> wanting to use OpenCog bits and pieces and aspects for various
> specific purposes, and this sort of funded dev is great but doesn't
> tend to lead to work focused on making the infrastructure easy for
> newbies...
>
> Tensorflow has wonderful documentation, beautiful visualization,
> elegant modularization, etc.  It's lovely for what it is.  How much do
> you think Google spent on these aspects?
>
> ben
>

Perhaps this is close to where the real disagreement is. On one hand,
the project is striving for modularity in the form of separate
compilation of modules and components. On the other hand, the idea of
having them as architecturally separate components elicits a belief
that it will be treated as narrow AI, and I know how you (rightfully)
feel about narrow AI. There is probably truth in both of our
arguments, but the difference is that I feel that the architecture I
advocate will lead to AGI much faster than otherwise. And I don't
think that this will necessarily shift the focus to the domain of
narrow AI. Rather, it will still be AGI development, but with the
variability in statefulness being greatly reduced, to the point where
a developer will not have to spend time studying the other moving
parts just to get to the point where they can feel comfortable working
on a specific component. This does not necessarily make it narrow AI
by default.

I also believe that it's easier to get resources earmarked for
improvements, when a more effective pitch is made for those
improvements. If there's no wisdom about what should be done, then
there's no proposal/plan that makes sense. And if there's no proposal,
there's no effective pitch. No effective pitch means no money. When
you say that the bottleneck is not A, but rather B; but I say that A
is a crucial step to remedy B, then perhaps this could be an idea for
some determined volunteers to try pursuing. It may not be something
easy or possible for the core crew to do, given the tied up resources,
but it might be possible for a small number of volunteers to
accomplish, given enough motivation.

Most of the money that gets spent by companies like Google on those
top notch architectural aspects, goes toward the leap from being in
the top 10%, to the top 1% of capabilities, or from the top 2% to the
top 0.1%. Talent acquisition involves a bidding war with other
companies, and the economics of it obviously aren't directly
applicable to libre projects... As you might know, Norvig's team
applies narrow AI techniques to the data around hiring and talent
markets, all in the pursuit of having the best talent is concentrated
in that one company. There are plenty of examples of freeware and
libre software with zero budgets, that have elegant architectures.
Inventing them for the first time may be costly, but re-using
paradigms that are already battle-tested and proven, is not
necessarily costly. The catch here is that most programmers don't know
how to do this, as it's not a domain that exists on most projects.
However, it is a domain that I have a personal interest in, so I would
like to help out if anyone else is able to participate...

I think that it would be a better idea at this point if Ivan and I
(and whomever else is interested) could come up with a more specific
proposal on an architectural design based on this discussion, while
also addressing all of your concerns brought up here. I can't promise
we would be successful (you know me well enough to know how terrible I
am at following through with ideas), but I think a more detailed
proposal would be more productive than debating on a mailing list.
Since a lot of the modularization is already there, as you mentioned,
it might not be too much 

Re: [opencog-dev] Contributing to Opencog

[Ben Goertzel]

***
OTOH, If modules or projects were usable in isolation, and the
dependencies could be effectively treated as black boxes (as most
software dependencies are), or even simulated/mocked, and if
meaningful experimentation and feedback still able to be done within
the narrow scope of that one module, then maybe the tutorials won't be
so pointless.
***

yes, I agree that narrow AI is easier than proto-AGI ... and that if
we put more effort into wrapping up OpenCog components so they could
be used as pure narrow-AI component in themselves, or for specific
narrow applications, then this would attract more developers toward
these narrow-AI applications and tools... and work on these narrow
applications and tools would indirectly benefit the quest for
OpenCog-based AGI...

Nevertheless I feel that the bottleneck is not currently wisdom about
"what would be nice to do" or "what should be done" but rather the
lack of any resources earmarked for making these types of
improvements   It's not like OpenCog Foundation has a large staff
and budget that is being frittered away on other stuff...   Nearly all
current OpenCog dev is happening because of commercial projects
wanting to use OpenCog bits and pieces and aspects for various
specific purposes, and this sort of funded dev is great but doesn't
tend to lead to work focused on making the infrastructure easy for
newbies...

Tensorflow has wonderful documentation, beautiful visualization,
elegant modularization, etc.  It's lovely for what it is.  How much do
you think Google spent on these aspects?

ben





On Fri, Oct 6, 2017 at 7:35 AM, Mark Nuzz  wrote:
> On Thu, Oct 5, 2017 at 4:22 PM, Linas Vepstas  wrote:
>> People seem not to read the tutorials... maybe because they don't see the
>> point of doing so?
>>
>
> Do you think my theory is plausible? Tutorials on a large system must
> be greater in scope, and are therefore more likely to be skimmed
> (which leads to a failure in comprehension).
>
> OTOH, If modules or projects were usable in isolation, and the
> dependencies could be effectively treated as black boxes (as most
> software dependencies are), or even simulated/mocked, and if
> meaningful experimentation and feedback still able to be done within
> the narrow scope of that one module, then maybe the tutorials won't be
> so pointless.
>
> --
> 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/CAMyYmr_W%3D%2Bfrxge4iEHhroZq7N2zFjBRU0AnNZsu%3D0F%2B%3Dvcuog%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



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

"I am God! I am nothing, I'm play, I am freedom, I am life. I am the
boundary, I am the peak." -- Alexander Scriabin

-- 
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/CACYTDBcOn02jCovYKeKurTQxVD4x4SwJ4tU%3D8yL5Kkiiw0-wuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

['Nil Geisweiller' via opencog]

On 10/06/2017 02:10 AM, Linas Vepstas wrote:
it would be nice to have a fast crisp prover so that the system could 
jump to conclusions, and pln more slowly in the background.


Yes, even for our rule engine alone there is a benefit to that. On top 
of being faster to evaluate, crisp rules tend to have less premises than 
their probabilistic counterparts.


Then the question is how to set the TV of these conclusions. If the 
axioms are crisps with (stv 1 1) or (stv 0 1), then the conclusions 
would be (stv 1 1) or (stv 0 1). But if the axioms are non-crisp, then I 
guess the crisp rules could set (stv 1 Epsilon) or (stv 0 Epsilon), just 
to express that something is possibly true or false. Or else we can 
create a new TV type for it.


Nil



On Oct 4, 2017 5:45 PM, "'Nil Geisweiller' via opencog" 
> wrote:


On 10/04/2017 11:02 AM, Linas Vepstas wrote> And can implement
algorithms in the graph database-agnostic way and

 use all the industrial power of the best database available.
 Scientists do use commercial off-the-shelf computers for
HPC, why
 not to use industrial software? And similar things we can
say about
 use of external reasoners (linear logic, Coq, Isabelle, etc.).


If you can attach coq to tinkerpop and make it work ... sure.
But you would probably have to completely rewrite both coq and
gremlin in order to do this.  And that is a huge amount of work.


I never tried Coq or Isabelle, but the provers I've tried (E and
Vampire) were using resolution
https://en.wikipedia.org/wiki/Resolution_(logic)
, which doesn't
work for a para-consistent logic like PLN, at least not
out-of-the-box. On top of that PLN is probabilistic (or even
meta-probabilistic we could say). These make it difficult or at best
unnatural to use traditional automatic theorem provers. Maybe
there's an easy way, or a more general framework that I missed, but
that was my impression when I studied the domain.

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/a261e2b5-7d6e-74f9-fe87-cd83304adb2a%40gmail.com

.
For more options, visit https://groups.google.com/d/optout
.

--
You received this message because you are subscribed to the Google 
Groups "opencog" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to opencog+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/CAHrUA343%2BH5CT5zGobgT5hq9sy_iLPSGJUh52WcsgHUPUZNqcw%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/8762676a-e52c-e3b4-9edb-bcd2c21e9aa0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Mark Nuzz]

On Thu, Oct 5, 2017 at 4:22 PM, Linas Vepstas  wrote:
> People seem not to read the tutorials... maybe because they don't see the
> point of doing so?
>

Do you think my theory is plausible? Tutorials on a large system must
be greater in scope, and are therefore more likely to be skimmed
(which leads to a failure in comprehension).

OTOH, If modules or projects were usable in isolation, and the
dependencies could be effectively treated as black boxes (as most
software dependencies are), or even simulated/mocked, and if
meaningful experimentation and feedback still able to be done within
the narrow scope of that one module, then maybe the tutorials won't be
so pointless.

-- 
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/CAMyYmr_W%3D%2Bfrxge4iEHhroZq7N2zFjBRU0AnNZsu%3D0F%2B%3Dvcuog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Linas Vepstas]

People seem not to read the tutorials... maybe because they don't see the
point of doing so?

On Oct 6, 2017 3:10 AM, "Ben Goertzel"  wrote:

> "Modular" and "monolithic" are very general terms.   Could you
> articulate more precisely the ways in which you think OpenCog is
> "monolithic", and in which you think it could be made more "modular"?
>
> My thinking is: the Atomspace is a distinct module (in its own repo,
> it builds separately, etc.), and the various AI processes that can be
> used with the Atomspace are also independently buildable and runnable
> (MOSES, PLN, the NLP pipeline, ECAN, etc.).   Also when we use OpenCog
> for robot control, it communicates with other AI tools that are
> wrapped up in separate ROS nodes.  This already seems pretty modular
> to me.  So I am wondering what other kind of modularity you are
> looking for?
>
> Regarding Ivan's description
>
> ***
> I was referring to an imaginary system where the whole project would
> be a set of modules that work together, connected by well known set of
> interfaces. Each module could be modified or forked out in parallel
> with the original. It would be up to a user, which sub-forks she/he
> would choose to use to run the project, or to base her/his
> contribution on. Probably there would be a need for combination
> maintainers, something like persons that would choose different
> flavors of the project, and would propose their "deejay-combo" to the
> public, optimized for this or that use. Sub-fork combinations of low
> quality would be avoided, while really useful ones would live on.
> ***
>
> I guess one relevant point is that the different AI tools within
> OpenCog can interact in many many different ways.  E.g. there is no
> single, simple interface for interaction between PLN and MOSES; there
> are lots of ways they can interface, conceptually speaking.  And
> figuring out the best ways for them to interface is a current research
> topic...
>
> In building a particular OpenCog application, one can define specific
> interfaces between the various AI components...  But for OpenCog as a
> general platform, the interactions between the components have to
> remain flexible because there are so many interesting ways to do it...
>
> I think the biggest issue with OpenCog is that we need better
> tutorials and documentation.   I guess if we had that people would be
> able to understand the system better and then would also make more
> useful suggestions regarding improving the architecture...
>
> ben
>
>
>
>
>
> -- Ben
>
>
>
> On Fri, Oct 6, 2017 at 2:56 AM, Mark Nuzz  wrote:
> > On Thu, Oct 5, 2017 at 2:13 AM, Ben Goertzel  wrote:
> >
> >> I regret that OpenCog remains so hard to approach.  In large part it
> >> has evolved this way because the vast bulk of funding that has gone
> >> into OpenCog has been oriented toward paying a small group of people
> >> to work, in a hurry, on making OpenCog do something specific   We
> >> have not yet had a big chunk of funding dedicated to making it easy to
> >> use as a platform.  Hopefully that will change soon.
> >
> > This seems to be a very common theme with projects, especially with
> > limited resources. Though OpenCog is unique in the sense that it has
> > survived for so long with so many contributors, so the scale/extent at
> > which this happened is somewhat larger and therefore require greater
> > effort and coordination to really solve.
> >
> > I'm curious about a few things...
> >
> > 1) I know you implied this but I wanted to make sure: Do you see the
> > goal of an easy-to-use opencog architecture as a high priority item?
> >
> > 2) Do you think that the specific architecture direction
> > (modularization) presented by Ivan is generally the way that this
> > should be solved?
> >
> > 3) Has there been any concrete work in mapping out a specific
> > architectural direction to fulfill the goal of making opencog easy to
> > use?
> >
> > 4) Are these decisions that have already been formally agreed upon by
> > the governance of the project? Are there any dissenters among the core
> > developers, to the extent that it might interfere with such plans if
> > executed?
> >
> >
> > I am not quite aware of all the details but I have been trying to keep
> > up with all of the discussions lately in this group. Please forgive me
> > if I am being too pedantic... My impressions are that funding would be
> > easier to come by after these items are figured out in great detail
> > and then incorporated as part of a proposal. Such a proposal could
> > attract enough of the right unpaid volunteers too, as you know.
> >
> >
> > But yeah, I am not claiming by any means to know even remotely close
> > to what Ben knows on this subject. But from my vantage point, I am of
> > the opinion that the monolithic architecture is what's slowing
> > progress, and not the lack of funding. Suppose you get the funds and
> > then you hire the wrong people, 

Re: [opencog-dev] Contributing to Opencog

[Linas Vepstas]

it would be nice to have a fast crisp prover so that the system could jump
to conclusions, and pln more slowly in the background.

On Oct 4, 2017 5:45 PM, "'Nil Geisweiller' via opencog" <
opencog@googlegroups.com> wrote:

> On 10/04/2017 11:02 AM, Linas Vepstas wrote> And can implement
> algorithms in the graph database-agnostic way and
>
>> use all the industrial power of the best database available.
>> Scientists do use commercial off-the-shelf computers for HPC, why
>> not to use industrial software? And similar things we can say about
>> use of external reasoners (linear logic, Coq, Isabelle, etc.).
>>
>>
>> If you can attach coq to tinkerpop and make it work ... sure. But you
>> would probably have to completely rewrite both coq and gremlin in order to
>> do this.  And that is a huge amount of work.
>>
>
> I never tried Coq or Isabelle, but the provers I've tried (E and Vampire)
> were using resolution https://en.wikipedia.org/wiki/Resolution_(logic),
> which doesn't work for a para-consistent logic like PLN, at least not
> out-of-the-box. On top of that PLN is probabilistic (or even
> meta-probabilistic we could say). These make it difficult or at best
> unnatural to use traditional automatic theorem provers. Maybe there's an
> easy way, or a more general framework that I missed, but that was my
> impression when I studied the domain.
>
> 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/ms
> gid/opencog/a261e2b5-7d6e-74f9-fe87-cd83304adb2a%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+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/CAHrUA343%2BH5CT5zGobgT5hq9sy_iLPSGJUh52WcsgHUPUZNqcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Ivan Vodišek]

Mark exactly hit the point I was trying to make. Imho, If I was joining an
open source project, I would like to see availability for programmers to
push any changes to any sub-area of the project without special permission
of a higher force. My thoughts are striving towards decentralization here.
But to make an order in such potentially chaotic conglomerate,
"distribution(s) maintainers" would compose and offer what they think it is
the best for particular use. Programmers would compete by code quality to
be included in future parallel distributions, just like it is the case with
Linux and its distributions. This idea sounds a bit progressive on the
first look, but it might work. It takes some to implement it, but maybe
some source control solutions that Mark proposed would be ready yet now,
without a much an effort.

Just sharing some thoughts, someone might find it useful.


2017-10-05 21:49 GMT+02:00 Mark Nuzz :

> On Thu, Oct 5, 2017 at 12:10 PM, Ben Goertzel  wrote:
> > "Modular" and "monolithic" are very general terms.   Could you
> > articulate more precisely the ways in which you think OpenCog is
> > "monolithic", and in which you think it could be made more "modular"?
> >
> > My thinking is: the Atomspace is a distinct module (in its own repo,
> > it builds separately, etc.), and the various AI processes that can be
> > used with the Atomspace are also independently buildable and runnable
> > (MOSES, PLN, the NLP pipeline, ECAN, etc.).   Also when we use OpenCog
> > for robot control, it communicates with other AI tools that are
> > wrapped up in separate ROS nodes.  This already seems pretty modular
> > to me.  So I am wondering what other kind of modularity you are
> > looking for?
>
> That's good news. My views are that this architecture needs to be
> developed further in order to reap the full benefits of it toward the
> project's goals.
> First and foremost, why are the independent processes part of the main
> opencog repo and not managed as separate projects with their own
> versioning and dependency toolchain? Do we have a fluent understanding
> of the pros and cons of doing it this way versus separate
> repositories? My guess is no, not because the team isn't smart, but
> because the resources seem to be focused on the specific modules
> rather than the architecture as a whole.  But I've learned not to ever
> underestimate the expertise of the team so this is just a wild guess.
>
> By dependency toolchain, I'm only aware of robust tooling for systems
> written in a single language or framework. Examples are npm, nuget,
> rubygems, paket. This reddit thread suggests that C++-based package
> management is a hard problem, and I'm inclined to agree.
> https://www.reddit.com/r/cpp/comments/3d1vjq/is_there_a_c_
> package_manager_if_not_how_do_you/
> However, it may still be worth trying.
>
> The vision that I have with this -- and this is the key point -- is
> that by keeping the modules as separate projects, the perceived
> complexity of the system is greatly reduced. The intimidation factor
> is reduced (for anyone new). The build tools can be simplified. Each
> project can have a concrete release build with a semantic version.
> Docker images could be provided, with pre-built binaries, for each
> major release. Each separate project could be developed independently
> with the assumption that your only required dependencies are those
> which are the latest major releases, and therefore if someone has
> trouble building, for whatever reason, then they can resort to using a
> docker image. Anyone who wants to work on a subproject can hit the
> ground running as there will be more concrete releases. Version 1.15
> of a given project will always be version 1.15. The way I see it now,
> is that we have a one-dimensional master branch for a large chunk of
> modules that exist in the opencog repo, though I see there are some
> efforts to do what I'm suggesting... so we might have the same vision
> but with someone varying ideas on how to execute it.
>
>
>
> >
> > Regarding Ivan's description
> >
> > ***
> > I was referring to an imaginary system where the whole project would
> > be a set of modules that work together, connected by well known set of
> > interfaces. Each module could be modified or forked out in parallel
> > with the original. It would be up to a user, which sub-forks she/he
> > would choose to use to run the project, or to base her/his
> > contribution on. Probably there would be a need for combination
> > maintainers, something like persons that would choose different
> > flavors of the project, and would propose their "deejay-combo" to the
> > public, optimized for this or that use. Sub-fork combinations of low
> > quality would be avoided, while really useful ones would live on.
> > ***
> >
> > I guess one relevant point is that the different AI tools within
> > OpenCog can interact in many many different ways.  E.g. there is no
> > single, 

Re: [opencog-dev] Contributing to Opencog

[Ben Goertzel]

"Modular" and "monolithic" are very general terms.   Could you
articulate more precisely the ways in which you think OpenCog is
"monolithic", and in which you think it could be made more "modular"?

My thinking is: the Atomspace is a distinct module (in its own repo,
it builds separately, etc.), and the various AI processes that can be
used with the Atomspace are also independently buildable and runnable
(MOSES, PLN, the NLP pipeline, ECAN, etc.).   Also when we use OpenCog
for robot control, it communicates with other AI tools that are
wrapped up in separate ROS nodes.  This already seems pretty modular
to me.  So I am wondering what other kind of modularity you are
looking for?

Regarding Ivan's description

***
I was referring to an imaginary system where the whole project would
be a set of modules that work together, connected by well known set of
interfaces. Each module could be modified or forked out in parallel
with the original. It would be up to a user, which sub-forks she/he
would choose to use to run the project, or to base her/his
contribution on. Probably there would be a need for combination
maintainers, something like persons that would choose different
flavors of the project, and would propose their "deejay-combo" to the
public, optimized for this or that use. Sub-fork combinations of low
quality would be avoided, while really useful ones would live on.
***

I guess one relevant point is that the different AI tools within
OpenCog can interact in many many different ways.  E.g. there is no
single, simple interface for interaction between PLN and MOSES; there
are lots of ways they can interface, conceptually speaking.  And
figuring out the best ways for them to interface is a current research
topic...

In building a particular OpenCog application, one can define specific
interfaces between the various AI components...  But for OpenCog as a
general platform, the interactions between the components have to
remain flexible because there are so many interesting ways to do it...

I think the biggest issue with OpenCog is that we need better
tutorials and documentation.   I guess if we had that people would be
able to understand the system better and then would also make more
useful suggestions regarding improving the architecture...

ben





-- Ben



On Fri, Oct 6, 2017 at 2:56 AM, Mark Nuzz  wrote:
> On Thu, Oct 5, 2017 at 2:13 AM, Ben Goertzel  wrote:
>
>> I regret that OpenCog remains so hard to approach.  In large part it
>> has evolved this way because the vast bulk of funding that has gone
>> into OpenCog has been oriented toward paying a small group of people
>> to work, in a hurry, on making OpenCog do something specific   We
>> have not yet had a big chunk of funding dedicated to making it easy to
>> use as a platform.  Hopefully that will change soon.
>
> This seems to be a very common theme with projects, especially with
> limited resources. Though OpenCog is unique in the sense that it has
> survived for so long with so many contributors, so the scale/extent at
> which this happened is somewhat larger and therefore require greater
> effort and coordination to really solve.
>
> I'm curious about a few things...
>
> 1) I know you implied this but I wanted to make sure: Do you see the
> goal of an easy-to-use opencog architecture as a high priority item?
>
> 2) Do you think that the specific architecture direction
> (modularization) presented by Ivan is generally the way that this
> should be solved?
>
> 3) Has there been any concrete work in mapping out a specific
> architectural direction to fulfill the goal of making opencog easy to
> use?
>
> 4) Are these decisions that have already been formally agreed upon by
> the governance of the project? Are there any dissenters among the core
> developers, to the extent that it might interfere with such plans if
> executed?
>
>
> I am not quite aware of all the details but I have been trying to keep
> up with all of the discussions lately in this group. Please forgive me
> if I am being too pedantic... My impressions are that funding would be
> easier to come by after these items are figured out in great detail
> and then incorporated as part of a proposal. Such a proposal could
> attract enough of the right unpaid volunteers too, as you know.
>
>
> But yeah, I am not claiming by any means to know even remotely close
> to what Ben knows on this subject. But from my vantage point, I am of
> the opinion that the monolithic architecture is what's slowing
> progress, and not the lack of funding. Suppose you get the funds and
> then you hire the wrong people, then you're even worse off than before
> because you probably wouldn't get another shot at funding for awhile.
> If it were up to me I would have at least one existing core developer
> be involved with this effort full-time, preferably whomever has the
> most knowledge in modular software architectures.
>
> --
> You received this message because you 

Re: [opencog-dev] Contributing to Opencog

[Mark Nuzz]

On Thu, Oct 5, 2017 at 2:13 AM, Ben Goertzel  wrote:

> I regret that OpenCog remains so hard to approach.  In large part it
> has evolved this way because the vast bulk of funding that has gone
> into OpenCog has been oriented toward paying a small group of people
> to work, in a hurry, on making OpenCog do something specific   We
> have not yet had a big chunk of funding dedicated to making it easy to
> use as a platform.  Hopefully that will change soon.

This seems to be a very common theme with projects, especially with
limited resources. Though OpenCog is unique in the sense that it has
survived for so long with so many contributors, so the scale/extent at
which this happened is somewhat larger and therefore require greater
effort and coordination to really solve.

I'm curious about a few things...

1) I know you implied this but I wanted to make sure: Do you see the
goal of an easy-to-use opencog architecture as a high priority item?

2) Do you think that the specific architecture direction
(modularization) presented by Ivan is generally the way that this
should be solved?

3) Has there been any concrete work in mapping out a specific
architectural direction to fulfill the goal of making opencog easy to
use?

4) Are these decisions that have already been formally agreed upon by
the governance of the project? Are there any dissenters among the core
developers, to the extent that it might interfere with such plans if
executed?


I am not quite aware of all the details but I have been trying to keep
up with all of the discussions lately in this group. Please forgive me
if I am being too pedantic... My impressions are that funding would be
easier to come by after these items are figured out in great detail
and then incorporated as part of a proposal. Such a proposal could
attract enough of the right unpaid volunteers too, as you know.


But yeah, I am not claiming by any means to know even remotely close
to what Ben knows on this subject. But from my vantage point, I am of
the opinion that the monolithic architecture is what's slowing
progress, and not the lack of funding. Suppose you get the funds and
then you hire the wrong people, then you're even worse off than before
because you probably wouldn't get another shot at funding for awhile.
If it were up to me I would have at least one existing core developer
be involved with this effort full-time, preferably whomever has the
most knowledge in modular software architectures.

-- 
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/CAMyYmr-T4gevcMh_2mYHko-YwuRcCK6dyBfGZVwYT%2BuizjH6PQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Ben Goertzel]

> I guess that in the
>> time of making first OpenCog lines, there were no graph databases, the
>> resarch and tools of graph mathcing and mining was only ascent field. But
>> today the situation is far more different - today graph databases and
>> mathcing/mining projects are available. Maybe the development strategy
>> should be changed - maybe one should more extensively use these projects and
>> there is mismatch of requirements then contribute to these speciality
>> projects back and not to try overdo them.

yeah, this makes sense until you look at the details...

One option we have looked at but not fully explored is Apache Ignite,
which is a sort of middleware layer between applications and storage.
It could possibly make sense to use Ignite as the basis for a
distributed OpenCog system -- retaining the current Atomspace as a
"local cache" and using Ignite to handle persistent storage and to
contain policies for interaction between local-cache Atomspaces on
different machines

However, this is easy to say and the hidden rocks may only become
apparent after actually trying it.   If someone feels like prototyping
this, that would be quite interesting.

I can say with confidence there is no other pattern-matching or
pattern-mining framework that does what OpenCog's does, and extending
Neo4J Cypher or whatever is not a viable route to reimplementing what
OpenCog's tools do...

It would require a lot less effort to create nice documentation and
interfaces for OpenCog, than to reimplement OpenCog functions atop
some fashionable platform that is inappropriate for the purpose...

I regret that OpenCog remains so hard to approach.  In large part it
has evolved this way because the vast bulk of funding that has gone
into OpenCog has been oriented toward paying a small group of people
to work, in a hurry, on making OpenCog do something specific   We
have not yet had a big chunk of funding dedicated to making it easy to
use as a platform.  Hopefully that will change soon.

-- Ben G

-- 
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/CACYTDBfAb2dtd1_ce34N7v__Kujj4%2Bk8nM2-mwLNvVseTO6G5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

['Nil Geisweiller' via opencog]

The AtomSpace project should probably be promoted on its own, have its 
own webpage, purpose, reference manual, tutorial, etc.


Also what is missing to get more main stream is a way to define atom 
types within atomese itself, so it could being used as a more neutral 
graph db. That's really the only missing piece since TV and AV have been 
replaced by generic key x value.


Nil

On 10/04/2017 11:02 AM, Linas Vepstas wrote:

hi Alex ... lots of small inline replies below.

On Wed, Oct 4, 2017 at 2:17 AM, Alex > wrote:


I am here since the fall of last year (around year) and if I am
allowed, I would like to make the following thoughts that may make
OpenCog project more attractable in the eyes of developers and users:

1) The first feature of OpenCog is its internal complexity. One can
read two-volume AGI book and wonder about ideas about organizing
mind agents and processing nodes in multiprocessor, distributed
architectures, about load balancing and execution priorities,
internode communication, etc. All these are pretty low level
technicalities that require the expertise of system programmers, but
this is quite rare expertise.

You can use opencog without knowing anything at all about the above 
topics.  If they are boring to you, just ignore them.  If they are 
interesting to you, then perhaps you could be a low-level infrastructure 
developer for opencog.  We need low-level people, but its not for everyone.




I have this discussion in other thread
https://groups.google.com/forum/#!topic/opencog/X_eKhNErmC8

about possibility to use external software and external services
more extensively in OpenCog project. So far OpenCog project is about
graph database, about graph pattern matching and graph pattern
mining, about rule engine - but all these technical services are
separate project today. I guess that in the time of making first
OpenCog lines, there were no graph databases, the resarch and tools
of graph mathcing and mining was only ascent field. But today the
situation is far more different - today graph databases and
mathcing/mining projects are available. Maybe the development
strategy should be changed - maybe one should more extensively use
these projects and there is mismatch of requirements then contribute
to these speciality projects back and not to try overdo them.


Opencog is far more advanced than any of these other projects.  I wish 
the people who created these other projects had worked on opencog 
instead. Oh well.


E.g. I do not believe that it is economically feasibile to
reimplement graph database. There are graph database projects, there
is ThinkerPop (JDBC) like interface and there is Gremlin (SQL) like
language.


The opencog query language is far more advanced than tinkerpop.  It is 
unfortunate that the tinkerpop folks decided to invent something new, 
instead of using what we already had.  Again -- this is about history, 
politics, and not about technology.


And can implement algorithms in the graph database-agnostic way and
use all the industrial power of the best database available.
Scientists do use commercial off-the-shelf computers for HPC, why
not to use industrial software? And similar things we can say about
use of external reasoners (linear logic, Coq, Isabelle, etc.).


If you can attach coq to tinkerpop and make it work ... sure. But you 
would probably have to completely rewrite both coq and gremlin in order 
to do this.  And that is a huge amount of work.



I guess, that OpenCog graph database, matcher and miner features are
more or less completed, so this work is not required for novice who
would like to contribute to AGI with OpenCog. 



That's exactly backwards. These were created to make it easier for the 
novice to use opencog.


But the question still stands. If one starts to think about load
balancing, about scalability - can we safely assume that from the
technical point of view OpenCog surpasses the industrial graph
databases? 



No, because we have exactly zero people working on load balancing and 
scalability.


And what to do if our Atomspaces are growing and growing and there
is need to improve this in the project? 


Its been like that for over 10 years now, yet here we are...

Should be move to the low level job of systems programmers which
requires so different expertise?


OpenCog has needed systems programmers since the very beginning.  
However, systems programmers are very rare, as you point out, and they 
are fully employed.


I am just afraid whether the project is going in the right
direction. People would like to concentrate on their models and
knowledge bases not on the techniques. 



You can use opencog today, without 

Re: [opencog-dev] Contributing to Opencog

['Nil Geisweiller' via opencog]

On 10/04/2017 11:02 AM, Linas Vepstas wrote> And can implement 
algorithms in the graph database-agnostic way and

use all the industrial power of the best database available.
Scientists do use commercial off-the-shelf computers for HPC, why
not to use industrial software? And similar things we can say about
use of external reasoners (linear logic, Coq, Isabelle, etc.).


If you can attach coq to tinkerpop and make it work ... sure. But you 
would probably have to completely rewrite both coq and gremlin in order 
to do this.  And that is a huge amount of work.


I never tried Coq or Isabelle, but the provers I've tried (E and 
Vampire) were using resolution 
https://en.wikipedia.org/wiki/Resolution_(logic), which doesn't work for 
a para-consistent logic like PLN, at least not out-of-the-box. On top of 
that PLN is probabilistic (or even meta-probabilistic we could say). 
These make it difficult or at best unnatural to use traditional 
automatic theorem provers. Maybe there's an easy way, or a more general 
framework that I missed, but that was my impression when I studied the 
domain.


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/a261e2b5-7d6e-74f9-fe87-cd83304adb2a%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Linas Vepstas]

hi Alex ... lots of small inline replies below.

On Wed, Oct 4, 2017 at 2:17 AM, Alex  wrote:

> I am here since the fall of last year (around year) and if I am allowed, I
> would like to make the following thoughts that may make OpenCog project
> more attractable in the eyes of developers and users:
>
> 1) The first feature of OpenCog is its internal complexity. One can read
> two-volume AGI book and wonder about ideas about organizing mind agents and
> processing nodes in multiprocessor, distributed architectures, about load
> balancing and execution priorities, internode communication, etc. All these
> are pretty low level technicalities that require the expertise of system
> programmers, but this is quite rare expertise.
>

You can use opencog without knowing anything at all about the above
topics.  If they are boring to you, just ignore them.  If they are
interesting to you, then perhaps you could be a low-level infrastructure
developer for opencog.  We need low-level people, but its not for everyone.


>
>
> I have this discussion in other thread https://groups.google.com/
> forum/#!topic/opencog/X_eKhNErmC8 about possibility to use external
> software and external services more extensively in OpenCog project. So far
> OpenCog project is about graph database, about graph pattern matching and
> graph pattern mining, about rule engine - but all these technical services
> are separate project today. I guess that in the time of making first
> OpenCog lines, there were no graph databases, the resarch and tools of
> graph mathcing and mining was only ascent field. But today the situation is
> far more different - today graph databases and mathcing/mining projects are
> available. Maybe the development strategy should be changed - maybe one
> should more extensively use these projects and there is mismatch of
> requirements then contribute to these speciality projects back and not to
> try overdo them.
>

Opencog is far more advanced than any of these other projects.  I wish the
people who created these other projects had worked on opencog instead. Oh
well.


> E.g. I do not believe that it is economically feasibile to reimplement
> graph database. There are graph database projects, there is ThinkerPop
> (JDBC) like interface and there is Gremlin (SQL) like language.
>

The opencog query language is far more advanced than tinkerpop.  It is
unfortunate that the tinkerpop folks decided to invent something new,
instead of using what we already had.  Again -- this is about history,
politics, and not about technology.


> And can implement algorithms in the graph database-agnostic way and use
> all the industrial power of the best database available. Scientists do use
> commercial off-the-shelf computers for HPC, why not to use industrial
> software? And similar things we can say about use of external reasoners
> (linear logic, Coq, Isabelle, etc.).
>

If you can attach coq to tinkerpop and make it work ... sure. But you would
probably have to completely rewrite both coq and gremlin in order to do
this.  And that is a huge amount of work.


>
> I guess, that OpenCog graph database, matcher and miner features are more
> or less completed, so this work is not required for novice who would like
> to contribute to AGI with OpenCog.
>

That's exactly backwards. These were created to make it easier for the
novice to use opencog.


> But the question still stands. If one starts to think about load
> balancing, about scalability - can we safely assume that from the technical
> point of view OpenCog surpasses the industrial graph databases?
>

No, because we have exactly zero people working on load balancing and
scalability.


> And what to do if our Atomspaces are growing and growing and there is need
> to improve this in the project?
>

Its been like that for over 10 years now, yet here we are...

Should be move to the low level job of systems programmers which requires
> so different expertise?
>

OpenCog has needed systems programmers since the very beginning.  However,
systems programmers are very rare, as you point out, and they are fully
employed.


> I am just afraid whether the project is going in the right direction.
> People would like to concentrate on their models and knowledge bases not on
> the techniques.
>

You can use opencog today, without having to worry about systems
programming issues.  Why are you worried about them?


> 2) Second obstacle to my adoption of OpenCog was some missed
> documentation. E.g. other programming systems have BNF formalization of
> their languages and the strict and exhaustive list of the constructions and
> available patterns. OpenCog has very good list of all the node and link
> types but sometimes I would like to have strict definitions what nodes can
> be used with what links. At present I am a bit afraid that I have to do
> some experimentation.
>

You should think of opencog atomese as being like python-0.6 or perl-0.8 --
its not yet at 

Re: [opencog-dev] Contributing to Opencog

[Linas Vepstas]

Ivan, Mark,

The project that Ben is referring to is here:
https://github.com/opencog/singnet -- it will allow a number of different
AI agents to communicate with one-another and exchange information.

Now is a good time to alter the course of events; that project is getting a
lot of effort at this particular instant.

--linas

On Tue, Oct 3, 2017 at 5:34 PM, Ben Goertzel  wrote:

> Yes.  My focus at the moment, frankly, is oriented toward raising the
> funds required to make this happen...
>
> On Tue, Oct 3, 2017 at 5:23 PM, Mark Nuzz  wrote:
> > Ivan,
> >
> > This is essentially the vision I have for the project too. I wish I could
> > say that it could be done by a determined volunteer, but the logistics
> are
> > very difficult for pulling this off. It would require multiple
> experienced
> > and skilled engineers working full-time, possibly paid. That isn't going
> to
> > happen by itself.
> >
> > Maybe there is a realistic path to making it happen. Let's talk in more
> > detail later since I'm interested too, but I can't promise any
> commitment as
> > its tough these days for me to put in the hours in addition to what
> keeps my
> > bills paid...
> >
> >
> > On Oct 2, 2017 9:50 PM, "Ivan Vodišek"  wrote:
> >>
> >> > But Ivan, no one forks opencog; almost all extensions are placed back
> >> > into the core code base.
> >>
> >> I'm aware of that. If someone forks the entire project, it would have
> been
> >> called some other name. I was referring to an imaginary system where the
> >> whole project would be a set of modules that work together, connected by
> >> well known set of interfaces. Each module could be modified or forked
> out in
> >> parallel with the original. It would be up to a user, which sub-forks
> she/he
> >> would choose to use to run the project, or to base her/his contribution
> on.
> >> Probably there would be a need for combination maintainers, something
> like
> >> persons that would choose different flavors of the project, and would
> >> propose their "deejay-combo" to the public, optimized for this or that
> use.
> >> Sub-fork combinations of low quality would be avoided, while really
> useful
> >> ones would live on. Just a bit of brainstorming in a direction of
> >> decentralization. The goal is to have industry-strength project
> abilities
> >> with liberal multi-user maintaining policy. It is on my long-term to-do
> >> list, but I could share my thoughts with someone who wants to implement
> it
> >> sooner.
> >>
> >> Thank you all for your patience :)
> >>
> >>
> >> 2017-10-03 4:33 GMT+02:00 Linas Vepstas :
> >>>
> >>> Hi Anastasios,
> >>>
> >>> Yes. But first: complaining that opencog is written in C++ is like
> >>> complaining about the fact that the linux kernel on your cellphone is
> >>> written in C. Who cares? It does not affect 99.% of all cellphone
> users
> >>> because they do not write kernel device drivers.
> >>>
> >>> Think of the atomspace as being like an OS kernel.  You probably should
> >>> not be writing new C++ extensions it.  Instead, you should be writing
> apps
> >>> for it.  The apps are where the action is.
> >>>
> >>> So far, we've offered maybe half-a-dozen app APIs for it, with varying
> >>> degrees of success.
> >>>
> >>> Having an instance on the cloud would be great, where people could spin
> >>> up an instance, and log into it. I've long long wanted to do this;
> hell, I
> >>> could just throw an old PC onto my internet connection. I don't have
> time to
> >>> mess with this.
> >>>
> >>> For cloud-cog, the only thing available would be the app API's, and
> maybe
> >>> that would make the bitching about C++ stop...
> >>>
> >>> --linas
> >>>
> >>> On Mon, Oct 2, 2017 at 6:47 AM, Anastasios Tsiolakidis
> >>>  wrote:
> 
>  Well isn't OpenCog having a busy weekend :) As a lurker I have already
>  expressed my dissatisfaction at "advanced C++" which is the trend in
> the
>  project, and would probably carry over my disapproval of "idiomatic
> C#".
>  There is absolutely no reason for the coding to be more difficult to
>  comprehend that OpenCog's design itself. If anything, the code should
> make
>  plain and simple what the bloody design is trying to do! Now, my
> particular
>  wet dream would be to see people pulling together their own "free
>  resources", like the free tiers at AWS, Google Cloud etc, to create a
>  hive-mind. If somebody was brilliant enough to throw away big chunks
> of the
>  code and instead achieve (some of) the same results with a DB of
> sorts, AWS
>  lambda etc, that would be quite something. Then, for the parts that
> don't
>  fit the "cloud" box, if someone could come up with the "CloudCog",
> some
>  probabilistic graph, inference engine or whatever is missing from the
> garden
>  variety PAAS and SAAS, then we could really be heading somewhere. I
> 

Re: [opencog-dev] Contributing to Opencog

[Alex]

I am here since the fall of last year (around year) and if I am allowed, I 
would like to make the following thoughts that may make OpenCog project 
more attractable in the eyes of developers and users:

1) The first feature of OpenCog is its internal complexity. One can read 
two-volume AGI book and wonder about ideas about organizing mind agents and 
processing nodes in multiprocessor, distributed architectures, about load 
balancing and execution priorities, internode communication, etc. All these 
are pretty low level technicalities that require the expertise of system 
programmers, but this is quite rare expertise. There are far more business 
application programmers or scientific application programmers that are 
relying on the OS features and speciality software features (like MPICH) to 
write and execute their high level application code.

I have this discussion in other thread 
https://groups.google.com/forum/#!topic/opencog/X_eKhNErmC8 about 
possibility to use external software and external services more extensively 
in OpenCog project. So far OpenCog project is about graph database, about 
graph pattern matching and graph pattern mining, about rule engine - but 
all these technical services are separate project today. I guess that in 
the time of making first OpenCog lines, there were no graph databases, the 
resarch and tools of graph mathcing and mining was only ascent field. But 
today the situation is far more different - today graph databases and 
mathcing/mining projects are available. Maybe the development strategy 
should be changed - maybe one should more extensively use these projects 
and there is mismatch of requirements then contribute to these speciality 
projects back and not to try overdo them. E.g. I do not believe that it is 
economically feasibile to reimplement graph database. There are graph 
database projects, there is ThinkerPop (JDBC) like interface and there is 
Gremlin (SQL) like language. And can implement algorithms in the graph 
database-agnostic way and use all the industrial power of the best database 
available. Scientists do use commercial off-the-shelf computers for HPC, 
why not to use industrial software? And similar things we can say about use 
of external reasoners (linear logic, Coq, Isabelle, etc.).

I guess, that OpenCog graph database, matcher and miner features are more 
or less completed, so this work is not required for novice who would like 
to contribute to AGI with OpenCog. But the question still stands. If one 
starts to think about load balancing, about scalability - can we safely 
assume that from the technical point of view OpenCog surpasses the 
industrial graph databases? And what to do if our Atomspaces are growing 
and growing and there is need to improve this in the project? Should be 
move to the low level job of systems programmers which requires so 
different expertise? I am just afraid whether the project is going in the 
right direction. People would like to concentrate on their models and 
knowledge bases not on the techniques. 

2) Second obstacle to my adoption of OpenCog was some missed documentation. 
E.g. other programming systems have BNF formalization of their languages 
and the strict and exhaustive list of the constructions and available 
patterns. OpenCog has very good list of all the node and link types but 
sometimes I would like to have strict definitions what nodes can be used 
with what links. At present I am a bit afraid that I have to do some 
experimentation. If the language had more formal specification then it 
would be possible to develop and formalize this specification furher - e.g. 
go from the textual code to the hypergraph, from programs to the hypergraph 
transformations and see what we can deduce from such semantics.

3) Third and last obstacle to my adoption was remoteness of the OpenCog 
ideas and concepts. It was great to have OpenCog experience because it 
invites me to look deeper in the OO notions. I.e. OpenCog is thinking in 
more basic terms of extensional in intensional inheritance/association, 
OO/UML modelling oversimplifies things. It is good, but still - some 
canonical mapping from OpenCog notions to the more widely adopted knowledge 
modelling notions would be helpful. Even more so because I am pretty sure 
that there are people who have made such mappings for themselves. And 
similar things I can say about the probabilistic term logic that is 
underlying OpenCog - it is not the most popular thing in the market. Again, 
I am not against such approach, I just invite to present some canonical 
mapping to the more popular logics. I don't exactly remember but AGI books 
had such explanation, if I am correct. 


So - the general conclusion is: there are ideas about modularization of 
OpenCog. But it seems to me that everyone here expects that modules will be 
developed by OpenCog society. My view is different. Modularization is 
required but we should use already available software (be it 

Re: [opencog-dev] Contributing to Opencog

[Ben Goertzel]

Yes.  My focus at the moment, frankly, is oriented toward raising the
funds required to make this happen...

On Tue, Oct 3, 2017 at 5:23 PM, Mark Nuzz  wrote:
> Ivan,
>
> This is essentially the vision I have for the project too. I wish I could
> say that it could be done by a determined volunteer, but the logistics are
> very difficult for pulling this off. It would require multiple experienced
> and skilled engineers working full-time, possibly paid. That isn't going to
> happen by itself.
>
> Maybe there is a realistic path to making it happen. Let's talk in more
> detail later since I'm interested too, but I can't promise any commitment as
> its tough these days for me to put in the hours in addition to what keeps my
> bills paid...
>
>
> On Oct 2, 2017 9:50 PM, "Ivan Vodišek"  wrote:
>>
>> > But Ivan, no one forks opencog; almost all extensions are placed back
>> > into the core code base.
>>
>> I'm aware of that. If someone forks the entire project, it would have been
>> called some other name. I was referring to an imaginary system where the
>> whole project would be a set of modules that work together, connected by
>> well known set of interfaces. Each module could be modified or forked out in
>> parallel with the original. It would be up to a user, which sub-forks she/he
>> would choose to use to run the project, or to base her/his contribution on.
>> Probably there would be a need for combination maintainers, something like
>> persons that would choose different flavors of the project, and would
>> propose their "deejay-combo" to the public, optimized for this or that use.
>> Sub-fork combinations of low quality would be avoided, while really useful
>> ones would live on. Just a bit of brainstorming in a direction of
>> decentralization. The goal is to have industry-strength project abilities
>> with liberal multi-user maintaining policy. It is on my long-term to-do
>> list, but I could share my thoughts with someone who wants to implement it
>> sooner.
>>
>> Thank you all for your patience :)
>>
>>
>> 2017-10-03 4:33 GMT+02:00 Linas Vepstas :
>>>
>>> Hi Anastasios,
>>>
>>> Yes. But first: complaining that opencog is written in C++ is like
>>> complaining about the fact that the linux kernel on your cellphone is
>>> written in C. Who cares? It does not affect 99.% of all cellphone users
>>> because they do not write kernel device drivers.
>>>
>>> Think of the atomspace as being like an OS kernel.  You probably should
>>> not be writing new C++ extensions it.  Instead, you should be writing apps
>>> for it.  The apps are where the action is.
>>>
>>> So far, we've offered maybe half-a-dozen app APIs for it, with varying
>>> degrees of success.
>>>
>>> Having an instance on the cloud would be great, where people could spin
>>> up an instance, and log into it. I've long long wanted to do this; hell, I
>>> could just throw an old PC onto my internet connection. I don't have time to
>>> mess with this.
>>>
>>> For cloud-cog, the only thing available would be the app API's, and maybe
>>> that would make the bitching about C++ stop...
>>>
>>> --linas
>>>
>>> On Mon, Oct 2, 2017 at 6:47 AM, Anastasios Tsiolakidis
>>>  wrote:

 Well isn't OpenCog having a busy weekend :) As a lurker I have already
 expressed my dissatisfaction at "advanced C++" which is the trend in the
 project, and would probably carry over my disapproval of "idiomatic C#".
 There is absolutely no reason for the coding to be more difficult to
 comprehend that OpenCog's design itself. If anything, the code should make
 plain and simple what the bloody design is trying to do! Now, my particular
 wet dream would be to see people pulling together their own "free
 resources", like the free tiers at AWS, Google Cloud etc, to create a
 hive-mind. If somebody was brilliant enough to throw away big chunks of the
 code and instead achieve (some of) the same results with a DB of sorts, AWS
 lambda etc, that would be quite something. Then, for the parts that don't
 fit the "cloud" box, if someone could come up with the "CloudCog", some
 probabilistic graph, inference engine or whatever is missing from the 
 garden
 variety PAAS and SAAS, then we could really be heading somewhere. I don't
 know much about the project beyond the demos, but I do believe the project
 is being hurt by the general unavailability of a constantly running 
 instance
 that "does something", whatever that maybe, and somehow can be accessed by
 the public, eg through an API. Presumably this new hedge fund thing may be
 the closest OpenCog has come to being a 24/7 system, and Ben will probably
 tells us if he finds out a better way to do things with and without this
 codebase

 AT

 --
 You received this message because you are subscribed to the Google
 Groups "opencog" 

Re: [opencog-dev] Contributing to Opencog

[Mark Nuzz]

Ivan,

This is essentially the vision I have for the project too. I wish I could
say that it could be done by a determined volunteer, but the logistics are
very difficult for pulling this off. It would require multiple experienced
and skilled engineers working full-time, possibly paid. That isn't going to
happen by itself.

Maybe there is a realistic path to making it happen. Let's talk in more
detail later since I'm interested too, but I can't promise any commitment
as its tough these days for me to put in the hours in addition to what
keeps my bills paid...

On Oct 2, 2017 9:50 PM, "Ivan Vodišek"  wrote:

> > But Ivan, no one forks opencog; almost all extensions are placed back
> into the core code base.
>
> I'm aware of that. If someone forks the entire project, it would have been
> called some other name. I was referring to an imaginary system where the
> whole project would be a set of modules that work together, connected by
> well known set of interfaces. Each module could be modified or* forked
> out* in parallel with the original. It would be up to a user, which
> sub-forks she/he would choose to use to run the project, or to base her/his
> contribution on. Probably there would be a need for combination
> maintainers, something like persons that would choose different flavors of
> the project, and would propose their "deejay-combo" to the public,
> optimized for this or that use. Sub-fork combinations of low quality would
> be avoided, while really useful ones would live on. Just a bit of
> brainstorming in a direction of decentralization. The goal is to have
> industry-strength project abilities with liberal multi-user maintaining
> policy. It is on my long-term to-do list, but I could share my thoughts
> with someone who wants to implement it sooner.
>
> Thank you all for your patience :)
>
>
> 2017-10-03 4:33 GMT+02:00 Linas Vepstas :
>
>> Hi Anastasios,
>>
>> Yes. But first: complaining that opencog is written in C++ is like
>> complaining about the fact that the linux kernel on your cellphone is
>> written in C. Who cares? It does not affect 99.% of all cellphone users
>> because they do not write kernel device drivers.
>>
>> Think of the atomspace as being like an OS kernel.  You probably should
>> not be writing new C++ extensions it.  Instead, you should be writing apps
>> for it.  The apps are where the action is.
>>
>> So far, we've offered maybe half-a-dozen app APIs for it, with varying
>> degrees of success.
>>
>> Having an instance on the cloud would be great, where people could spin
>> up an instance, and log into it. I've long long wanted to do this; hell, I
>> could just throw an old PC onto my internet connection. I don't have time
>> to mess with this.
>>
>> For cloud-cog, the only thing available would be the app API's, and maybe
>> that would make the bitching about C++ stop...
>>
>> --linas
>>
>> On Mon, Oct 2, 2017 at 6:47 AM, Anastasios Tsiolakidis <
>> hellene...@gmail.com> wrote:
>>
>>> Well isn't OpenCog having a busy weekend :) As a lurker I have already
>>> expressed my dissatisfaction at "advanced C++" which is the trend in the
>>> project, and would probably carry over my disapproval of "idiomatic C#".
>>> There is absolutely no reason for the coding to be more difficult to
>>> comprehend that OpenCog's design itself. If anything, the code should make
>>> plain and simple what the bloody design is trying to do! Now, my particular
>>> wet dream would be to see people pulling together their own "free
>>> resources", like the free tiers at AWS, Google Cloud etc, to create a
>>> hive-mind. If somebody was brilliant enough to throw away big chunks of the
>>> code and instead achieve (some of) the same results with a DB of sorts, AWS
>>> lambda etc, that would be quite something. Then, for the parts that don't
>>> fit the "cloud" box, if someone could come up with the "CloudCog", some
>>> probabilistic graph, inference engine or whatever is missing from the
>>> garden variety PAAS and SAAS, then we could really be heading somewhere. I
>>> don't know much about the project beyond the demos, but I do believe the
>>> project is being hurt by the general unavailability of a constantly running
>>> instance that "does something", whatever that maybe, and somehow can be
>>> accessed by the public, eg through an API. Presumably this new hedge fund
>>> thing may be the closest OpenCog has come to being a 24/7 system, and Ben
>>> will probably tells us if he finds out a better way to do things with and
>>> without this codebase
>>>
>>> AT
>>>
>>> --
>>> 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 

Re: [opencog-dev] Contributing to Opencog

[Linas Vepstas]

On Mon, Oct 2, 2017 at 2:32 AM, Mark Nuzz  wrote:

> Hi,
>
>
> On Sun, Oct 1, 2017 at 9:30 AM, Linas Vepstas 
> wrote:
>
>
> > I mean, how do I tell people "this code compiles but probably doesn't
> work
> > and no one uses it" vs. "this code is the bedrock foundation that we
> > jelously protect from damage"
>
> The way I see it handled most often is to only allow
> production-quality, working code in the master branch.


Yes, but this is the opposite of what we do. I've had this argument with
Ben, and he wants anyone to contribute any thing at any time, no matter
what the quality is. Everyone gets write permissions always. He doesn't
want me or anyone to be a gatekeeper or project manager. He's very
anti-project-management.

The current split is that the atomspace is core code, and is more tightly
policed, while the opencog repo is the wild-west of random parts.


> But didn't the
> project try to enforce that with CircleCI (I think) and you had an
> issue with that?


CircleCI was great, but the integration with github was terrible. It made
checking in code very hard.  It was an instrument of torture and pain.

Anyway, that is besides the point: Although passing unit tests is
important, it is not enough to ensure high-quality code.   There's more to
it than that.

> >
>
> It might just be my anti-C++ bias talking.


I don't particularly love C++. I don't hate it either. It is what it is.

But focusing on this misses the point of opencog.  Don't write C++ code!!
Not you and mostly not anyone, except for a few core maintainers.

You should think of opencog as a domain-specific language.  Actually,
several domain-specific languages. We've created half a dozen of those,
program in those.   For example, our newest one is "ghost". Program in
ghost, that's what you should use, and not C++.

--linas

-- 
*"The problem is not that artificial intelligence will get too smart and
take over the world," computer scientist Pedro Domingos writes, "the
problem is that it's too stupid and already has." *

-- 
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/CAHrUA35hkNbRAmu_Via5dOtJD3Xn21yQW%3DZ7ubvq62XtTkOj%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Mark Nuzz]

On Oct 1, 2017 3:47 PM, "Anastasios Tsiolakidis" 
wrote:
>
> Well isn't OpenCog having a busy weekend :) As a lurker I have already
expressed my dissatisfaction at "advanced C++" which is the trend in the
project, and would probably carry over my disapproval of "idiomatic C#".
There is absolutely no reason for the coding to be more difficult to
comprehend that OpenCog's design itself. If anything, the code should make
plain and simple what the bloody design is trying to do!

But it's not a matter of what the actual code looks like! The tooling, the
compilation times, libraries, and so on, all require a higher level of
expertise on the C++ side. Even though Linus knows that understanding it is
not needed, the fact is that based on the above fact, C++ is by and large a
language for experts and to a lesser extent academics. So if you want
non-academic, non-experts (which is the vast majority of the FOSS
community) then I recommend polishing the build scripts as needed, fixing
all reported issues with the build  (if someone has to POST here because of
a build problem, then it's likely a defect). Then make sure the newbie
tutorials exist, are easy to find, updated, and that they steer people far
the hell away from the C++ code :)

-- 
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/CAMyYmr9cwgBVZ47u%2BGH6uY0-zh8TNOTnUfusF2ADGYP4W6TxzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Anastasios Tsiolakidis]

Well isn't OpenCog having a busy weekend :) As a lurker I have already 
expressed my dissatisfaction at "advanced C++" which is the trend in the 
project, and would probably carry over my disapproval of "idiomatic C#". 
There is absolutely no reason for the coding to be more difficult to 
comprehend that OpenCog's design itself. If anything, the code should make 
plain and simple what the bloody design is trying to do! Now, my particular 
wet dream would be to see people pulling together their own "free 
resources", like the free tiers at AWS, Google Cloud etc, to create a 
hive-mind. If somebody was brilliant enough to throw away big chunks of the 
code and instead achieve (some of) the same results with a DB of sorts, AWS 
lambda etc, that would be quite something. Then, for the parts that don't 
fit the "cloud" box, if someone could come up with the "CloudCog", some 
probabilistic graph, inference engine or whatever is missing from the 
garden variety PAAS and SAAS, then we could really be heading somewhere. I 
don't know much about the project beyond the demos, but I do believe the 
project is being hurt by the general unavailability of a constantly running 
instance that "does something", whatever that maybe, and somehow can be 
accessed by the public, eg through an API. Presumably this new hedge fund 
thing may be the closest OpenCog has come to being a 24/7 system, and Ben 
will probably tells us if he finds out a better way to do things with and 
without this codebase

AT

-- 
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/2668e4aa-5324-4a66-9786-c795daad157c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Ivan Vodišek]

Then you have great powers over there.

2017-10-01 21:01 GMT+02:00 Mark Nuzz :

> On Sun, Oct 1, 2017 at 11:53 AM, Ivan Vodišek 
> wrote:
> > And is there a way to extract a documentation of the project in a way
> > Javadoc works? That option would be of great help if it would be used.
>
>
> Try building with "make doxygen"
>
> --
> 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/CAMyYmr-gn6OdTnSgGa5SZyOxtkTXJL%3DXY9d-2tv4SD%2B4ibVq%2BQ%
> 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/CAB5%3Dj6VW7ks4jz_U%2BAEuor1_beZqGtFhx7S9%2BxFdExpf%3De2SAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Mark Nuzz]

On Sun, Oct 1, 2017 at 11:53 AM, Ivan Vodišek  wrote:
> And is there a way to extract a documentation of the project in a way
> Javadoc works? That option would be of great help if it would be used.


Try building with "make doxygen"

-- 
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/CAMyYmr-gn6OdTnSgGa5SZyOxtkTXJL%3DXY9d-2tv4SD%2B4ibVq%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Ivan Vodišek]

And is there a way to extract a documentation of the project in a way
Javadoc works? That option would be of great help if it would be used.

2017-10-01 20:37 GMT+02:00 Mark Nuzz :

> On Sun, Oct 1, 2017 at 11:32 AM, Ivan Vodišek 
> wrote:
> >
> > The key property of collaboration system I'm proposing is a security
> system
> > where each author can give privileges to modify or to fork out their
> work.
> > This way I hope that the system could scale well towards a bigger number
> of
> > maintainers, without need to boss around like in big corporations.
> >
> > Are there any thoughts on this subject? Is there even an interest in
> such a
> > tool?
> >
>
> There's already such a tool, it's called the Pull Request. You could
> have as part of a CI system a way to automatically assign reviewers to
> a pull request, based on the changes that are made, and where they
> were made. And some bigger tech companies do this very thing.
>
> --
> 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/CAMyYmr--p%2BDpT7ZHOwFQ9CnsTE8Xri9s3gucO1
> Qb8t0b3EY8WA%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/CAB5%3Dj6X%3DF1mn%2Bq30_hvX0%3D%2Bna10t%3DSWGnOYG9bHRCxy1nwgLHQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Mark Nuzz]

On Sun, Oct 1, 2017 at 11:32 AM, Ivan Vodišek  wrote:
>
> The key property of collaboration system I'm proposing is a security system
> where each author can give privileges to modify or to fork out their work.
> This way I hope that the system could scale well towards a bigger number of
> maintainers, without need to boss around like in big corporations.
>
> Are there any thoughts on this subject? Is there even an interest in such a
> tool?
>

There's already such a tool, it's called the Pull Request. You could
have as part of a CI system a way to automatically assign reviewers to
a pull request, based on the changes that are made, and where they
were made. And some bigger tech companies do this very thing.

-- 
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/CAMyYmr--p%2BDpT7ZHOwFQ9CnsTE8Xri9s3gucO1Qb8t0b3EY8WA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Mark Nuzz]

By the way, I lurked for 10 years before making my first real contribution.
Don't blame the project for that one!

-- 
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/CAMyYmr8CnvfrXKkwP%3DN2Znjs_n9k4BYucTszgb1fy9agu70kYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Mark Nuzz]

You bring up a good point. It is quite difficult to maintain. Not only is
it a very complex system design, but the implementation is also quite
complex, containing a lot of legacy code, unfinished features, experiments,
and whatever else. I used to thumb my nose at the fact that not enough
attention seems to be focused on simplifying the implementation. But now I
have a lot of respect for the project's ability to thrive for so long
despite the barriers to entry.

Keep in mind though that at many software companies, it can take a number
of months of full time effort before a professional engineer becomes
productive, even despite efforts to reduce this time!

And this is also a research project, with the core contributors being
focused on research. I don't think they would be able to focus on
maintainability.

My approach to solving it, if I were to decide now, would be to first get a
lot of feedback on what new and existing contributors find difficult about
the project's implementation, maintainability, and ramp up time. Would also
look at past posts meticulously, to find patterns.

Some recommendations that might be made (subject to approval and further
analysis): Would consider gradually moving parts of the C++ into idiomatic
C# (fully open source now), or even F# if functional programming
environment is desired. Any C++ developer can understand C#, and almost
anything you can do in C++ can be done in C#, but with less complex code
and easier troubleshooting. Even if half the core developers were to prefer
python (for example) I'd try to persuade everyone that C# is a better
choice due to the fact that it probably has the lowest learning curve of
all major languages, is syntactically and idiomatically similar to C++, and
has high compatibility due to the VM runtime.

Would clean up the build scripts or even rewrite them completely (the
scripts aren't bad, but they're old and probably need an overhaul). Toss
out all support for alternate OS, alternate compiler, etc. At least until
support can be re-added under a newer build system. There is (or was) a lot
of "junk DNA" code in the build script that only hinders efforts to
understand it or improve it. Ever hear of the "broken window problem"?
CMake has a high learning curve (and is it really necessary when using one
OS?) so I'd probably do away with it.

My vote is worth about zero though because I don't have the physical
stamina or mental willpower to work on this in addition to my day job (it
would not be easy work, and likely some of the hardest coding work I've
ever done, which is saying something).

On Oct 1, 2017 7:38 AM, "Amirouche Boubekki" 
wrote:

>
>
> On Mon, Sep 25, 2017 at 5:05 PM Onkar N Mahajan 
> wrote:
>
>> I am interested to contributing to Opencog. What do I need to learn, and
>> how soon can I be an active contributor ?
>>
>
> Forget about it. I've been lurking for 2 years, read dozens if not
> hundreds of wiki pages and papers and I still can't contribute to opencog.
>
> From experience, if you look for guidance on how to contribute then you
> are not good enough.
>
> My 2 cents.
>
> --
> 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/CAL7_Mo-y6hgsjDPjbuJBtqcTeCiMTty9PHbHm
> NdGQ1dMstJWCA%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/CAMyYmr9AXLz0o_MOOXP_Vab3ece7RKN0vhQ4QNfdKEe1Ehjzog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Amirouche Boubekki]

On Mon, Sep 25, 2017 at 5:05 PM Onkar N Mahajan  wrote:

> I am interested to contributing to Opencog. What do I need to learn, and
> how soon can I be an active contributor ?
>

Forget about it. I've been lurking for 2 years, read dozens if not hundreds
of wiki pages and papers and I still can't contribute to opencog.

>From experience, if you look for guidance on how to contribute then you are
not good enough.

My 2 cents.

-- 
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/CAL7_Mo-y6hgsjDPjbuJBtqcTeCiMTty9PHbHmNdGQ1dMstJWCA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Linas Vepstas]

Well, we need a crisp-logic reasoner attached to the language subsystem.
For example, the Uni-Potsdam ASP solver hooked up to the output of
relex2logic.  How easy or hard this might be depends on whether you know
ASP and anything about language, and/or have studied logic.

There are other projects too, listed in the "Ideas" wiki page.

--linas

On Mon, Sep 25, 2017 at 11:05 PM, Onkar N Mahajan 
wrote:

> I am interested to contributing to Opencog. What do I need to learn, and
> how soon can I be an active contributor ?
>
> --
> 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/c87d0f11-8750-4f9f-be5f-f28fa640328b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
*"The problem is not that artificial intelligence will get too smart and
take over the world," computer scientist Pedro Domingos writes, "the
problem is that it's too stupid and already has." *

-- 
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/CAHrUA36NN84PTPgQ-2gu-SK6vDJnEW6wVR2gmmiT__Qv0294UA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Contributing to Opencog

[Onkar N Mahajan]

I am interested to contributing to Opencog. What do I need to learn, and 
how soon can I be an active contributor ?

-- 
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/c87d0f11-8750-4f9f-be5f-f28fa640328b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to OpenCog

['Nil Geisweiller' via opencog]

Great wikipage containing what you're looking for and more

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

Nil

On 05/05/2017 08:47 PM, Pranav Deshpande wrote:

Hello and thank you for the reply. I will start reading the book as you
suggest, Could you please send me the electronic draft?
Also, based on my current Github repo, which part do you think is
appropriate for me to contribute to?

Regards,
Pranav

On Friday, May 5, 2017 at 10:07:41 PM UTC+5:30, Nil wrote:

Hi,

On 05/05/2017 05:14 PM, Pranav Deshpande wrote:
> I would like to contribute to OpenCog. What aspects of AI and ML do I
> need to know to contribute; or can I just get started? I wanted some
> guidance.

it all depends on what you'd like to do, if you desire to go to the
bottom of it I think knowing probability and logic (say predicate
logic)
is very good. Having a broad culture about AI helps too, including
theoretical stuff like Solomonoff induction. Ben and Linas would
probably tell you that category theory is helpful :-) (I know too
little
about it and I've started reading "Category Theory for the Siences").
More directly linked to the OpenCog design you may want to read

https://www.amazon.com/Engineering-General-Intelligence-Part-Cognitive/dp/9462390266/



if you'd rather not spend money on it we can provide you an electronic
draft that is essentially like the book. The wiki itself is full of
information, browse it at will.

Regarding programming languages, the core is in C++ and it supports
Scheme, Python and Haskell as binding languages.

You don't necessarily need to know all that to contribute though,
reading the wiki and giving your feedback, correcting when you can is
very helpful.

Nil

>
> Regards,
> Pranav
>
> --
> 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/8f8a1f5f-1415-4ac1-9bf6-2c45829b8bd2%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/f8c5d7e8-a68e-4db6-a859-526be6001bff%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/281a2d9f-47a0-0e18-8931-5f470b1ec869%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to OpenCog

[Pranav Deshpande]

Hello and thank you for the reply. I will start reading the book as you 
suggest, Could you please send me the electronic draft?
Also, based on my current Github repo, which part do you think is 
appropriate for me to contribute to?

Regards,
Pranav

On Friday, May 5, 2017 at 10:07:41 PM UTC+5:30, Nil wrote:
>
> Hi, 
>
> On 05/05/2017 05:14 PM, Pranav Deshpande wrote: 
> > I would like to contribute to OpenCog. What aspects of AI and ML do I 
> > need to know to contribute; or can I just get started? I wanted some 
> > guidance. 
>
> it all depends on what you'd like to do, if you desire to go to the 
> bottom of it I think knowing probability and logic (say predicate logic) 
> is very good. Having a broad culture about AI helps too, including 
> theoretical stuff like Solomonoff induction. Ben and Linas would 
> probably tell you that category theory is helpful :-) (I know too little 
> about it and I've started reading "Category Theory for the Siences"). 
> More directly linked to the OpenCog design you may want to read 
>
> https://www.amazon.com/Engineering-General-Intelligence-Part-Cognitive/dp/9462390266/
>  
> if you'd rather not spend money on it we can provide you an electronic 
> draft that is essentially like the book. The wiki itself is full of 
> information, browse it at will. 
>
> Regarding programming languages, the core is in C++ and it supports 
> Scheme, Python and Haskell as binding languages. 
>
> You don't necessarily need to know all that to contribute though, 
> reading the wiki and giving your feedback, correcting when you can is 
> very helpful. 
>
> Nil 
>
> > 
> > Regards, 
> > Pranav 
> > 
> > -- 
> > 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/8f8a1f5f-1415-4ac1-9bf6-2c45829b8bd2%40googlegroups.com
>  
> > <
> https://groups.google.com/d/msgid/opencog/8f8a1f5f-1415-4ac1-9bf6-2c45829b8bd2%40googlegroups.com?utm_medium=email_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/f8c5d7e8-a68e-4db6-a859-526be6001bff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to OpenCog

['Nil Geisweiller' via opencog]

Hi,

On 05/05/2017 05:14 PM, Pranav Deshpande wrote:

I would like to contribute to OpenCog. What aspects of AI and ML do I
need to know to contribute; or can I just get started? I wanted some
guidance.


it all depends on what you'd like to do, if you desire to go to the 
bottom of it I think knowing probability and logic (say predicate logic) 
is very good. Having a broad culture about AI helps too, including 
theoretical stuff like Solomonoff induction. Ben and Linas would 
probably tell you that category theory is helpful :-) (I know too little 
about it and I've started reading "Category Theory for the Siences"). 
More directly linked to the OpenCog design you may want to read 
https://www.amazon.com/Engineering-General-Intelligence-Part-Cognitive/dp/9462390266/ 
if you'd rather not spend money on it we can provide you an electronic 
draft that is essentially like the book. The wiki itself is full of 
information, browse it at will.


Regarding programming languages, the core is in C++ and it supports 
Scheme, Python and Haskell as binding languages.


You don't necessarily need to know all that to contribute though, 
reading the wiki and giving your feedback, correcting when you can is 
very helpful.


Nil



Regards,
Pranav

--
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/8f8a1f5f-1415-4ac1-9bf6-2c45829b8bd2%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/179e51ff-a222-702f-f2e1-cfeead33b6b6%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to OpenCog

[Linas Vepstas]

well, we have a pile of python bugs that need fixing...

-- linas

On Wed, Apr 5, 2017 at 3:44 PM, Nived Narayanan  wrote:

> Hi all,
> I'm Nived doing my junior year in IIT Madras. I am an open source
> enthusiast and  have done courses in machine learning and reinforcement
> learning. This is the link to my website  and
> github . Please help me to get started with
> Opencog.
>
> Best regards,
> Nived
>
> --
> 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/ce53d79a-2fba-47ac-aec8-c41ace689144%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/CAHrUA362rqdPo2Tpjf0_8b8H2hBkN7u6pRBbjOH%2B4w2x-poVjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Contributing to OpenCog

[Nived Narayanan]

Hi all,
I'm Nived doing my junior year in IIT Madras. I am an open source 
enthusiast and  have done courses in machine learning and reinforcement 
learning. This is the link to my website  and 
github . Please help me to get started with 
Opencog. 

Best regards,
Nived 

-- 
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/ce53d79a-2fba-47ac-aec8-c41ace689144%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Contributing to OpenCog

[Vineet Parikh]

Hi there,

I recently completed my open source project that I started in Summer 2016.  
The project involved documenting a core feature of Linux XIA, specifically 
the Longest-Prefix-Matching principal  where I helped experiment/verify all 
relevant constructs - including installing virtual machines, downloading 
code from GitHub, compiling Linux kernel with new code from XIA's 
repository, deploying the new Linux kernel, testing this new functionality 
and writing pertinent documentation (as well as a short experiment on how 
LPM works).  Although my love for writing code started a while ago, taking 
an intensive programming course at Harvard Extension Summer School (Summer 
2015) helped me a lot.

I have received awards for a research project on AI theory from Intel and 
the ACM.

I am an enthusiastic high school senior with a lot of value to offer. 

My Linkedin profile can be found here. 


I am interested in working on a pertinent initiative at OpenCog. Is there a 
project I can work on?

Thanks for your time,
Vineet Parikh
(732) 331.6409

-- 
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/1f994326-789c-4824-94c3-443d275151e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.