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 <[email protected]> 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 <[email protected]> > wrote: > > > > > > > > On Fri, May 17, 2019 at 10:23 AM Vitaly Bogdanov <[email protected]> > 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 [email protected]. > > To post to this group, send email to [email protected]. > > Visit this group at https://groups.google.com/group/opencog. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/opencog/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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/opencog. > To view this discussion on the web visit > https://groups.google.com/d/msgid/opencog/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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA35Z3bZgf619uXxTn52%2B7SvqA2e8Xpp9CRrNyfzG6VuFZQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
