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.
