Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site watnot.UUCP
Path: utzoo!watmath!watnot!dcgoricanec
From: dcgoricanec@watnot.UUCP (dcgoricanec)
Newsgroups: net.lang.prolog
Subject: Making Recursion Affordable in Prolog ?
Message-ID: <11628@watnot.UUCP>
Date: Mon, 17-Mar-86 21:35:34 EST
Article-I.D.: watnot.11628
Posted: Mon Mar 17 21:35:34 1986
Date-Received: Tue, 18-Mar-86 02:36:25 EST
References: <2935@sunybcs.UUCP>
Reply-To: dcgoricanec@watnot.UUCP ()
Organization: U of Waterloo, Ontario
Lines: 31
Keywords: Recursion and Stack Overflow
Summary: 

<chomp>
hello world .
Examine the following :                                                    

rubik_cube([],New_perm)    :- write(New_perm),!.
rubik_cube([H|T],New_perm) :-          
                              move_generator(H,New_perm,Newer_perm),
                              rubik_cube(T,Newer_perm).
                       

This predicate is invoked by a list of cube moves such as

rubik_cube([u,r2,l,r2],Resultant_perm)?

Fine. I can submit a list of 25 such moves to a program on my ibm-xt with
   512k running plvp+ but 26 moves causes a stack overflow.I would like
   225 moves in my list ...
   (Incidentally, the trace of 25 moves is truly impressive,filling the
   80 col screen for 10 minutes.)

My question to the net is : Since this program is list-driven and only
   recurses to split the list, how can I kill the thousands of 
   instantiations cluttering the stack when I move on to the next list element?
   (ie. kind of like a cut but instead of inhibiting backtracking,
        I want to inhibit recursive memory of past events)

Currently my program is 15k long and can solve u-face efficiently by using
   the tables published by Singmaster. Generalization to the whole cube group
   is trivial once I get prolog to handle a big list splitting.

Thistlewaite's algorithm will likely be the next predicate,graphics too...