Hi Cle,

> To rephrase the chinese sentence once more: your solution was exactly
> the same as I came up with my first attempt. But due to the fact, I use
> '+String' for all fields, the Pilog 'db' clause did find the wrong
> solutions. To handle that, I did introduce a 'equal' check then. But

Right. BTW, the 'equal' check, from a procedural point of view, is not
so wrong. Because if instead 'db' would search for the exact solution
itself, it would have to do the same processing, i.e. try subsequent
tree entries, and throw away the first hits which are not "equal". This
is due to the nature of tree searches that the smallest hits are found
first.


> now, if I can use '+Number' for the id's the 'equal' check could vanish,
> I assume. :-)

Unfortunately, as occurs to me now, this would only help for the access
to 'id'. Later we have also 'src' and there we probably will need
strings anyway.


> But I would guess -- if I understood your and Henriks explanation
> correctly -- that my solution should be faster, as I use the Lisp access
> functions, shouldn't it?

Yes, it avoids some overhead, but I think this is minimal. The overhead
is some Pilog layer, but as we saw the Pilog interpreter is not the
bottleneck.


> I would think, *only* if I use numeric 'id', 'src' and 'tgt'. Otherwise
> the 'db' clause of Pilog would find a connection 'pt11' in e.g. the
> 'src' field although it was requested only to search for a connection
> from 'src' = 'pt1' ... :-(

Yep.


> But I will have a look, if I can use numeric ids for all properties of
> an edge. I would guess that unification in my Pilog solution should also
> be faster, if those arguments were numeric instead of strings. :-) And
> perhaps the DB behaves better then.

The more I think about it, the more I believe that a plain in-memory
solution is better. The I/O overhead and index tree traversals might
still be heavy in comparison the the rather sequential traversal of
Pilog rules in memory.

If you really had millions of edges, I would consider replacing the two
'db' instances with something handmade out of an in-memory index with
the 'idx' function.


> That was, what made me crazy too ... I had thought, that direct access
> via an index should be faster than sequential search of 360 edges again
> and again and again ...

Yes, but

- An index is also not really a direct access, but involves searching
  btree nodes. In-memory, linear lookup for a few dozens or hundreds of
  items is usually faster.

- I'm not even sure if Pilog does much searching here, of if it just
  iterates the lists of clauses?


> If it really need millions of edges to show effect, I can safely reside
> on my Pilog facts, as my tracknet will never be so large. The 360 edges
> are a not so small tracknet already :-D

Yeah, so let's better stay with plain Pilog. Then the "database" is just
the set of rules read into memory once, and then processing can start
without further I/O.

A database really makes only sense when

- there are more data than fit into memory

- only a small subset needs to be loaded into memory for a certain
  operation

- the data are loaded/modified/written in arbitrary ways, and need to be
  persistent

- multiple users operate on the data and need to be synchronized

Did I forget something?

So a constant, small set of rules can simply be read at program start.

Cheers,
- Alex
-- 
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to