Ah! OK, well then some quick concluding remarks:
-- Yes, the 5-second thing sounds like a bug; to keep the conversation focused, its probably best to open a bug report against the URE, and track that. -- Using the chainer to solve 2D/3D motion planning problems is at, or just a bit past what we can currently do with the chainer. No one has attempted to solve this kind of problem before with the chainer, and there are surely bugs and optimizations that this will expose. But it is a worthy undertaking. -- By contrast, there is a system, called "answer set programming" (ASP), that can solve generic constraint-satisfaction problems in a blazingly fast way. But I don't really know how well it can handle a 200-waypoint problem. Depends on how it's encoded, I suppose... -- ASP works with crisp true/false values; this allows for strong, brutal trimming of impossible solutions, using the Davis-Putnam DPLL algo. The URE cannot trim and cut away like this, so is at a sharp disadvantage. We've argued about better ways to do URE, e.g. by applying Morse theory, but no one has done this yet. (in Morse theory, you would create a cutoff c, and then round all truth values > c to 1.0 and all truth values < c to 0.0. Start with c=0.99 and then run ASP and see if there is a solution. If no solution, then set c=0.98 and try again. The idea is that running ASP 100 times might still be faster than brute-force uncertain-inference chaining.) -- If we had 5 clones of Nil, then one of them could go through the ASP examples and port them to the chainer, and make them work well. (btw, I recommend the uni-potsdam ASP solver, if you mess with it) -- So, if you just need a motion planner that works (as opposed to messing with the theory of it) then, as a practical solution, I would recommend just grabbing something off the shelf and wiring it in, ad hoc. -- In opencog-land, we have this vague vision that the "space server" is a specialized component that understands 3D space, and has a collection of hard-coded custom algos for working with 3D space (and, at the same time, interfacing with the atomspace and natural language, e.g. using words like "near", "far", "come", "go"). At this time, it is neglected. (it compiles and passes unit tests, but doesn't really do anything "useful") Linas. On Mon, Mar 2, 2020 at 9:19 AM Alexander Gabriel <[email protected]> wrote: > > > Am Montag, 2. März 2020 14:37:12 UTC schrieb linas: >> >> >> >>> Yes, that doesn't scale to what I intend to do. >>> >> >> I'd like to know why you think that. (what you are trying to do). I'm >> interested in understanding and solving scaling problems. >> > > The robot needs to make sure it can reach the human co-worker. For that it > needs a path of waypoints which are interlinked and it needs to make sure > that for any node on that path there is nobody. > Deriving the path from one node to another is an inference problem, solved > by iteratively connecting neighours until a connection is established. > I guess I could do this using the forward chainer, but given 200 > waypoints, that would create a gigantic number of links between node pairs. > So I'd prefer doing it using the backward chainer, but since the task > involves checking virtual links which isn't supported by the chainer, it > seems I'm out of luck. > > >> >> >>> >>>> Ah, it's a completely different query, one where the backward chainer >>>> tries to find assignments of the free variables of a closed term. >>>> >>> >>> This was unclear to me, so let me clarify, (... and Nil should correct >> me where I'm wrong.) >> >> Suppose that the pattern matcher finds zero solutions to the original >> query -- there is no combination of human/picker/place1/origin/destination >> in the *current* atomspace that satisfies that pattern. In this case, the >> backward chainer then examines the set of rules that it has, to determine, >> if possible, whether there is a sequence of deductions (a sequence of rule >> applications) that provide suitable Atoms that allow your pattern to be >> satisfied. For example, the current AtomSpace might not contain any humans >> at all, but perhaps there is a way to infer that someone is human. Or a >> better example: there is no (Evaluation (Predicate "leads to") origin >> destination) but perhaps the backward chainer can find a sequence of >> multiple steps that lead from origin to destination -- it can find a path >> -- that eventually leads to a satisfaction of all of your terms. >> >> The problem with path-finding, is, of course, that it's a hard problem: >> there can be a combinatorial explosion, and thus an explosion of CPU time. >> There are algorithms that, for example, know all about 2D space, and make >> use of 2D geometry to find a good path. The backward chainer has no clue >> that it's exploring a 2D space, so it's search for a path is a bit more >> blind. Perhaps there's a way of making it clever, e.g. taking the A*-search >> rules and turning them into a PLN formula, and maybe that would work... but >> this discussion is not yet at this level. >> > > The distance (in waypoints) between the robot and the picker is usually > small, so iteratively applying a simple implication rule should produce the > path in just a couple of steps with the number depending on how the chainer > does this, fewer if it balances both terms, longer if it focusses on one. > But in the aforementioned example this is not taking place as there is no > such rule for 'leads_to' links (only for 'linked' links). So I'm at a loss > why the query takes so long. There isn't much chaining to be done as far as > I can see. > > Best, > Alex > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/opencog/21007978-a855-45b0-9c52-b0dab0c023e3%40googlegroups.com > <https://groups.google.com/d/msgid/opencog/21007978-a855-45b0-9c52-b0dab0c023e3%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA35AkUaJSthUpLH2yXSwmdAVA50mdSBSBt1S5c4NPQxvRw%40mail.gmail.com.
