On Fri, Feb 7, 2020 at 1:02 AM paarulakan(பாருலகன்) < selva.develo...@gmail.com> wrote:
> Hi Linas, > > Thank you. Can you point me to documentation for 'how the backward-forward > things' > The general theory would be explained in textbooks that explain chaining, reasoning, deduction. I assume there's some wikipedia article but I never looked. For how the opencog-ure codebase actually works ... I assume there is a README or whatever in the repo, or wiki pages, but only Nil Geisweiller would know for sure. > most of the communication is happening through atomspace. right? > It depends... in game programming, something like the atomspace would be called "the blackboard" -- you write stuff into it, come back later, its still there. But the atomspace is also like a database, because you can search it. But there's also Atomese which is a kind-of programming language, since you can write programs in it .. or rather, you can write programs to the blackboard, and then later execute them .. or analyze them .. or transform them. (Atomese is very low level. It's kind-of assembly like, so a bit hard for humans, its also slow.) By contrast, when people say "communication" they usually mean "channel" and channels have no memory (channels have no blackboards). Funny thing is, you can use "Values" to implement channels. So atoms specify the plumbing, and values are what flow through those channels. > > To add more context, I come from deep learning background so I know > python, but I want to work on symbolic natural language processing. > Yeah. I want to go in the opposite direction. Or rather unify the two approaches. I have ideas but have not gotten very far yet. I am learning lisp for the same reason. > Switch to scheme now. Its almost exactly the same ... but you will find it slightly cleaner. I have been working with python for 4 years now > There's a really great book, called SICP (structure and interpretation of computer programs). It teaches scheme from the ground up. Coming from Python (or C/C++) it might seem weird and hard and screwy but somewhere in the middle of chapter 2 you will realize that everything you know about programming is wrong... or rather, is a very special case of something far more generic. but it seems unnatural for symbolic NLP. > .. or symbolic anything. Which is how we arrived at opencog/atomese. It took a while to understand the issues ... and not done yet... Is there a way to pickup some task and apply opencog framework for that? > more concretely sentiment analysis and question answering. > I don't know how to give an easy answer, so let me give a complex one. So, maybe 10 years ago, opencog had a question-answering system. It worked, in a small domain. It worked by parsing natural-language sentences, for example "A thermometer is an instrument" or "A violin is a musical instrument" and converting them to abstract graphs e.g. isA(thermometer, instrument) or isA(violin, mod(instrument, music)) and storing the abstract graphs in the atomspace. Questions, such as "What is an instrument?" were converted to isA(???, instrument) and a pattern-match was run to find everything that ??? would be. "fill in the blanks". There are several obvious problems with this, as anyone who tries this finds out. You have to write special cases for all the different question types. One finds oneself curating an ever-more complex ruleset to handle all of these cases. And like any complex ruleset ... its buggy. Its fragile. questions can be misunderstood. Wrong, insane answers can be supplied. No commonsense... (despite this, people have created huge triple-stores and whatnot. I think that's a fundamentally wrong approach). It was my hope to hand-write enough rules to get a general sense of what that rule-set is like, and then create systems that can learn and adjust the rules. Then I got side tracked solving other issues along the way. .. Such as creating a code base capable of such things. I still think I "know how" to do this, but it remains experimental and a bit out of reach. I did learn various important lessons along the way, but cannot quickly summarize. What's I'm describing is not a "task" but a decade-long research program. If you want a short programming task, there are issue-lists of bugs to fix. Most of these require you to know system internals, though. Here's one task, but maybe its rather complex... so, one project, https://github.com/opencog/learn wants to induce grammar via unsupervised training on text. (and then later, from grammar, shallow and deep semantics, i.e. "do question answering right") We've been using English, but it became clear that the correct thing is really to create random grammars, then generate random sentences, and then see if the learning system can learn those random grammars. .. and use that as a scoring system, to track quality of learning. So the task is ... create random grammars, and write the code to create a collection of random sentences. Sounds easy, but its surprisingly hard. I mean, its not a few days or a week, its a good bit longer. How much I can't say. Care to try that? Warning: it might be really very difficult, and so without a principled approach, you'll get nowhere. It will likely force you to understand certain basic concepts about grammars and computation and combinatorial explosion that you probably haven't ever had to think about before ... -- Linas > On Friday, February 7, 2020 at 3:34:51 AM UTC+5:30, linas wrote: >> >> Hi Paarulakan .. >> >> Why scheme instead of lisp? Well, scheme is a modern-lisp, having >> cleaned up assorted messes and inconsistencies and ugly-bits. Kind of >> like asking "why C instead of fortran?" >> >> Why guile-scheme instead of some other scheme? Guile offered vastly >> superior integration into C/C++ than any other scheme out there. I don't >> know if that's still true or not. Certainly, all schemes/lisps have >> "foreign function interfaces" -- FFI's but I don't believe that's enough -- >> we're not just invoking foreign functions, there's a whole bunch of >> backward-foreward movement between the code in each language. >> >> -- Linas >> >> On Thu, Feb 6, 2020 at 4:20 AM paarulakan(பாருலகன்) <selva.d...@gmail.com> >> wrote: >> >>> Why did opencog choose scheme as its lisp not common lisp. I recently >>> started learning lisp family of languages, still a newbie. but other than >>> the thing that scheme is lighweight, are they any other reason for using >>> scheme? >>> >>> -- >>> 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 ope...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/opencog/7d99a84e-a980-4bb1-950f-8185362b5f76%40googlegroups.com >>> <https://groups.google.com/d/msgid/opencog/7d99a84e-a980-4bb1-950f-8185362b5f76%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> cassette tapes - analog TV - film cameras - you >> > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/opencog/c2c68511-309d-4a4a-a4a5-ac5834d3c15b%40googlegroups.com > <https://groups.google.com/d/msgid/opencog/c2c68511-309d-4a4a-a4a5-ac5834d3c15b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- cassette tapes - analog TV - film cameras - you -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA37A60KCcfwgVg3ShtQMORsi-PQcjMWDkS-v%2BmpOQ0TsxA%40mail.gmail.com.
