Re: Iteratively calling Prolog from C

[Daniele Peri]

Daniel Dudley wrote:

> Bartek Wilczynski wrote:
>
>
> > Quoting Daniel Dudley <address@hidden>:
> >
> > <cut>
> >
> >
> > > ?- factorial(18795, F).
> >
> > <cut> 
> >
> >
> > > Big enough for you?
> > >
> > > Daniel
> >
> > I'm afraid You don't understand the problem with tail recursion
> > optimization, and I think that other discussion participants
> > find it to obvious to explain to You, so I'll try. 
> Generally, I would not recommend Prologers to create huge
> lists via pure recursion -- in any Prolog implementation.
>
> Which brings me back to my original post in this thread.
> Ok, if you're feeling particularly mad (just today or even
> long-term), then consult this (for_nd.pl) in gprolog:
>
> % for_nd(Start,Stop,N) is true if N is the current value
> % of the iteration ranging from Start to Stop. For each
> % iteration, N is increased by one.
>
> for_nd(N,_,N).
> for_nd(Start,Stop,NumOut):-
>   Start < Stop,
>   Start1 is Start + 1,
>   for_nd(Start1,Stop,NumOut).
>
> and run this query:
>
> ?- findall(N,for_nd(1,100000,N),L).
>
> Bartek can add three 0's to the 100000 in the query if he
> so wants.

Again, I think you have not tried with gprolog. With a default GLOBALSZ 
of 8 Mb it consumes all the stack with a Stop=1000000 either putting a 
variable or the _ as the last findall argument. This may have different 
explanations, but I suspect the temporary argument being never freed. 
This is supported by:

findall([N,N,N,N,N,N,N,N,N], for_nd(1, 100000, N), _).

doing the same job of consuming the stack. In this case Stop was scaled 
down of a factor of 10 and the item size was multiplied by 9. Add the 
little overhead of generating a list each iteration and you get the same 
memory consumption.
This does not surprise me. As I told you before, this happens also with 
your factorial_nd and would happen with any other large, not empty 
(probably) loop.

> Note that for_nd/3 is a non-deterministic predicate on the
> same lines as factorial_nd/5.
>
> I'll spare the mailing list the output!
>
>
> > And please, stop giving examples using different prolog
> > implementation, when discussion is about specific problems
> > in gprolog implementation (or not-implementation ;).
>
>
> I apologize, the meaning was merely to show erroneous
> behaviour in gprolog (in comparison to other Prologs).
> Clearly I assumed too much when I thought this would be
> obvious to readers.

Why don't we all take it easy? We are discussing about some gprolog's 
flaws and the way to solve them, possibly. Why this turns into a flame 
war is unexplicable.

Daniele