Alexander Burger wrote:
> Hi Cle,
>
>
>> Nice idea! Now I reformulated my Pilog rules for usage with database
>> like this:
>>
>> (be graph:walk (@Begin @Way)
>> (@E db 'id '+DB:Edge (-> @Begin))
>> (@To get (-> @E) 'tgt)
>> (graph:walk @To (@Begin) @Way)
>> )
>>
>> (be graph:walk (@Node @Way @Way))
>>
>> (be graph:walk (@FromNode @AuxWay @Way)
>> (@Edges collect 'src '+DB:Edge (-> @FromNode))
>> (lst @Edge @Edges)
>> (@Id get (-> @Edge) 'id)
>> (@ToNode get (-> @Edge) 'tgt)
>> (graph:walk @ToNode (@Id . @AuxWay) @Way)
>> )
>>
>
> Hehe, nice. Our mails crossed-over, without paying attention to a point
> or signal ;-)
Yeah, but also without any accident ;-)))
> The solutions look pretty similar.
That should be so! As they say in China: 英雄所见略同 (Heros have the
same mind/opinion) ;-)
> As you see, the explicit 'get' can be substituted by a more concise
> 'val' predicate.
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
now, if I can use '+Number' for the id's the 'equal' check could vanish,
I assume. :-)
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?
> I also notice that the '@From' in my walk/2 is not used and thus
> unnecessary. So I would propose (especially if you use a numeric 'id'):
>
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' ... :-(
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.
But if I do this, I will need another facts, to mark, which node ('src'
or 'tgt') is a start or end point of a tracknet. At the moment those are
named like "End#12" or such ...
(...)
> I would not worry about that. It is just the other way round: If the
> interpreter finds an _undefined_function_ with a colon in the name, then
> it searches for a library. This doesn't inhibit us, though, to define
> such functions ourselves. And here we are not dealing with functions
> anyway.
>
A good to know! So I can go forth with that procedure :-)
>> With those changes the traversion becomes a bit faster; it needed 87
>> seconds for 1000 pathes, where Pilog facts would take 3 seconds ;-)
>>
>
> This large difference is rather strange. I would expect _some_ slowdown,
> as the DB involves I/O operations while Pilog only runs in memory, but
> not so much.
>
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 ...
So I am really eager to understand, why this is not the case, even with
my Lisp database access in Pilog? Otherwise I feel I did something wrong
perhaps ...
> The question is what happens if you have millions of edges. Then the
> linear lookup in Pilog versus the index accesses in the DB might show
> effect.
>
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
Ciao,
cle.
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
