Alexander Burger wrote:
>
> Hi Cle,
Hi Alex,
(...)
>>> If 'new' is called this way, it will not create database objects
>>> but
>>
>> ... :-O But ... but ... but ... URGHS! :-( I had looked especially
>> into the "x.db" file and found my keys "1", "11" and "111" there.
>> So I thought
>
> Right. I never tried it this way, but the reason is that though
> there were memory-only objects created, the relation-handling
> side-effects of '+Ref' etc. were executed, so that the indexes were
> in the file but not the objects.
ahhh ... now I understand, what I've seen :-)
(...)
> The way I would use is the already-discussed 'collect'
(...)
> If you really prefer Pilog also for direct accesses, then you can
> still call it the direct way:
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)
)
This is an excerp from my actual code. You will find, that I use a
<module>: prefix in my clauses to modularize the Pilog clauses and
facts. A slight misuse I know, as those prefix should be used for
function in shared libraries ... :-}
With those changes the traversion becomes a bit faster; it needed 87
seconds for 1000 pathes, where Pilog facts would take 3 seconds ;-)
Any other hint? :-))))
> I'll study your project now ... Looks interesting :-)
Thank you for your interest :-)
> Cheers, - Alex
Ciao,
cle.
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
