*** The other meta-question is "who is managing this process?" -- it feels like progress is at a dead stand-still; no one is communicating on any communications channels visible to me. ***
This is because you are not on SingularityNET's internal Slack where a lot of the current discussion is taking place If you'd like to join this Slack -- which is private not public at this point -- let me know and we can re-send you the email for you to set up your li...@singularitynet.io email address, which you need in order to access that Slack... -- Ben On Sat, May 18, 2019 at 11:35 PM Linas Vepstas <linasveps...@gmail.com> wrote: > > Ben, > > You really don't need any fancy words for this. The design for this was done > last spring, it was done for Alexey's Potapov's team. Its called "Values" and > the RandomValue example shows how to use it. You can do continuations to > your hearts-delight under the covers. There's no technical problems to > solve, at this level. The meta-problem is a communication problem -- Alexey's > team did not use that design, they invented something brand-new, and > presented it as fait-accompli. I believe that, by now, they've > mostly-sort-of-ish returned to something close-ish to the original proposed > design (I'm not quite entirely clear on that). > > The remaining tasks are as I listed them: > -- develop a dozen of two predicates that ghost can hook into > -- Map the Potapov-team code to those predicates > -- Build "generic" versions of exactly those same predicates, that use > OctoMapValue to do their stuff > -- Pipe the Hanson Robotics ROS pipeline into OctoMap > -- Write entertaining robot dialog that shows off those predicates > > The difficult theoretical meta-issue might be "is the above a good way of > hooking sensory input to natural language?" We can debate that for the next > 100 years. But in the meanwhile, the first five points above -- I think > they're achievable; I think they're straight-forward -- ordinary software > developers can do it; there is no theoretical invention required; don't even > need to know what a continuation is. It's mostly just wire-it-up and > debug-it. In the traditional scale of Ben-Goertzel-interstingness, the above > is "boring", it is "not even AI". And that is actually a good thing: it > allows a basic working demo to be built, and if we build it and don't let it > bit-rot, then some/much of the tension with Hanson would evaporate. It's a > practical, doable sensory system, even if it is not any kind of theoretical > lightning bolt. It's a base-line. > > The other meta-question is "who is managing this process?" -- it feels like > progress is at a dead stand-still; no one is communicating on any > communications channels visible to me. > > -- Linas > > > On Sat, May 18, 2019 at 3:55 PM Ben Goertzel <b...@goertzel.org> wrote: >> >> *** >> For example if generic predicate uses value to verify whether object >> is "red", then what it expects from value is pair of doubles (mean, >> confidence). If our value returns such pair of doubles it forgets all >> computation graph which led to this result. It means that we are not >> able to propagate an error back through the calculation graph and >> improve next result. >> >> As far as I see such unification is not possible without changing >> predicate logic or introducing outer system to calculate predicates >> and keep computation graph. >> *** >> >> It seems analogous to what is done in Haskell to support backtracking >> and Prolog-type cut and so forth. There one does use an "external" >> system to manage historical records, but this external system is >> hidden behind the monadic interface, >> >> http://okmij.org/ftp/papers/LogicT.pdf >> >> http://hackage.haskell.org/package/logict >> >> This is all using continuations behind the scenes, and related to some >> discussions Linas and I had earlier about making Atomspace schema >> processing support continuations. If one is manipulating >> continuations rather than just functions, then maintaining and >> manipulating the external computation graph is "just" an efficient >> shorthand for computing what the continuations denote... >> >> -- Ben >> >> >> On Sat, May 18, 2019 at 9:00 PM Linas Vepstas <linasveps...@gmail.com> wrote: >> > >> > >> > >> > On Fri, May 17, 2019 at 10:23 AM Vitaly Bogdanov <vsb...@gmail.com> wrote: >> >> >> >> Hi Linas, >> >> >> >>> The intended design is that there is a well-known Value that is attached >> >>> to red-cube. That Value is knows how to obtain the correct 3D location >> >>> from the SpaceServer (or some other server, e.g. your server). That >> >>> Value ONLY fetches the location when it is asked for it, and ONLY THEN. >> >>> This is the code that Misgana wrote. Twice. You should NEVER directly >> >>> shove 3D positions into the atomspace!! >> >> >> >> >> >> Am I right that implementation of this design is still not merged? >> > >> > >> > It was merged half-a-year-ago, a year-ago. >> > >> >> In current atomspace/opencog code I can find OctoMapValue only which >> >> inherits FloatValue (and keeps vector of doubles in it) + has update() >> >> method which updates the value using OctoMapNode. So value should be >> >> updated before using it. >> > >> > >> > Yes, but I think you misunderstand how it works. It is updated only when >> > the value is asked for. If no one asks for the value, it is never updated. >> > This design allows the current value to be managed externally, in some >> > other component, and it is then brought into the atomspace "on demand", >> > only when some user of the atomspace tries to look at the value. Think >> > of it as a "smart value" -- when the user asks the value "what number are >> > you holding?", the value isn't holding anything; instead, it goes to the >> > external server, gets the latest, and returns that. >> > >> > In this case, OctoMapValue never changes, until you ask for it's current >> > value; then it goes to the space-server, gets the current value, and >> > returns that. >> > >> > The examples directory contains a much simpler example: "RandomValue" -- >> > which uses `random()` as the "external system". You're supposed to >> > cut-n-paste that code, replace `random()` by your server, and that's it -- >> > done. That's all that OctoMapValue is - just a small, simple wrapper. >> > >> > Also - right now, OctoMapValue only holds a 3D position, I think. We need >> > an API for size, width, height, orientation. Maybe not all of that, right >> > away, but at least a basic-size API. So that natural language expressions >> > like "See that small thing on the table? Point your finger at it" work. >> > >> > Having these other attributes does not change the overall design. The >> > Values don't update until they are accessed. >> > >> >> >> >>> >> >>> That way, we can have a common, uniform API for all visual-processing >> >>> and 3D spatial reasoning systems. (for example, some 3D spatial >> >>> reasoning might be done on imaginary, pretend objects. The sizes, >> >>> colors, locations of those objects will not come from your vision >> >>> server; they will come in through some other subsystem. However, the >> >>> API will be the same. >> >>> >> >>> I should be able to tell the robot "Imagine that there is a six-foot red >> >>> cube directly in front of Joel. Would Joel still be visible?" and get >> >>> the right answer to that. When the robot imagines this, it would not use >> >>> the space-server, or your server, or the ROS-SLAM code for that >> >>> imagination. However, since the access style/access API is effectively >> >>> the same, it can still perform that spatial reasoning and get correct >> >>> answers. >> >> >> >> >> >> Yes, I think I see your point. We could wrap NN by value and return its >> >> results on demand to be analyzed by generic predicates. Such approach >> >> allows getting results from visual features on demand. But back >> >> propagation seems to not work with this approach. >> > >> > >> > Yes, not everything can work with generic predicates. But it will work >> > with two important cases: traditional robotics sensory subsystems, and >> > with imagined (virtual?) worlds e.g. from a blue-print, engineering >> > drawing, math-textbook figure or similar abstract system that provides >> > spatial info, without being "visual" in the usual sense. >> >> >> >> >> >> For example if generic predicate uses value to verify whether object is >> >> "red", then what it expects from value is pair of doubles (mean, >> >> confidence). If our value returns such pair of doubles it forgets all >> >> computation graph which led to this result. It means that we are not able >> >> to propagate an error back through the calculation graph and improve next >> >> result. >> > >> > >> > ? I don't understand. What do you need to propagate back? >> > >> >> >> >> As far as I see such unification is not possible without changing >> >> predicate logic or introducing outer system to calculate predicates and >> >> keep computation graph. >> > >> > >> > Yes, it's fine to *also* have externally-calculated predicates, and that >> > is what you have, more-or-less. Having generic predicates that work with >> > the space server would also be nice to have (and then, to have the space >> > server hooked up to ROS, which it isn't, right now) >> > >> > Oh, and finally, of course, to hook up the predicates (generic, or >> > external) to language (ghost). For this last step, we need the ghost >> > maintainers -- Amen, Man Hin, others, to look at think about and comment >> > about what predicates they could actually use and support easily and >> > quickly. It's easy to make a list of prepositional and comparative >> > phrases -- there are about 100 of them (above, below, behind, next-to, >> > bigger-then, taller, .. etc) and we should start with some reasonable >> > subset of these, hook them into the chatbot, and get things like >> > question-answering going. As far as I know, no one has begun any of this >> > work yet, right? >> > >> > -- Linas >> > >> > >> > -- >> > 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 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/CAHrUA34Jt4H16rGeqyfdwF2kHRX8nSme0zk7im8tuR%2BBpbMnsQ%40mail.gmail.com. >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> Ben Goertzel, PhD >> http://goertzel.org >> >> "Listen: This world is the lunatic's sphere, / Don't always agree >> it's real. / Even with my feet upon it / And the postman knowing my >> door / My address is somewhere else." -- Hafiz >> >> -- >> 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/CACYTDBf5by0X3rpiPu1zy0O-GOhm07uLOOH07Lnp6F%3DXw31t%3DQ%40mail.gmail.com. >> For more options, visit https://groups.google.com/d/optout. > > > > -- > 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 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/CAHrUA35Z3bZgf619uXxTn52%2B7SvqA2e8Xpp9CRrNyfzG6VuFZQ%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- Ben Goertzel, PhD http://goertzel.org "Listen: This world is the lunatic's sphere, / Don't always agree it's real. / Even with my feet upon it / And the postman knowing my door / My address is somewhere else." -- Hafiz -- 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/CACYTDBcGjhmRp2mLZMJhRUfXAg%3DSan9k4xB8aysL2%3DZGqnDK%3Dw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
