stack overflow & random number problems revisited

[Vance G Marshall <askvance@spruce.flint.umich.edu>]

Hello again,
  As was pointed out to me, in my last post I left out some details about 
the stack overflow portion of my problems. I should have included a 
little more background on the nature of my program.
  The program is attempting to simulate the cognitive process of subjects 
during a particular psychological experiment. The subject is given a 
three number sequence (2 4 6) & is told that this sequence is an instance 
of some target hypothesis. Their task is to correctly guess that 
hypothesis. Subjects are told that in order to acertain the target 
hypothesis, they should propose their own hypothesis (H) which explains 
the given three number sequence. Furthurmore, they should test their 
hypothesis by generating three number sequences which are instances of 
their H. The only feedback the subjects are given is to inform them 
whether or not their number sequences are instances of the target H.
  Now, suppose that the target H is "increasing numbers". A subject might 
look at the sequence (2 4 6), propose a H of "all even numbers" & 
generate a test sequence of (8 10 12). The feedback would be T since (8 
10 12) is an instance of "increasing numbers". This type of test sequence 
is known as a positive test since it is an instance of the subject's H. 
The result then becomes T T, since (8 10 12) is an instance of both the 
subject's H & the target H. Had they generated (2 2 2) or (8 6 4), the 
result would have been T F, since these sequences are instances of the 
subject's H but are not instances of the target H. In this latter case (T 
F), the subject should generate a new H & propose new tests.
  There are also negative tests, where the number sequence generated is 
not an instance of the subject's H; i.e. - (3 5 7) for "all even 
numbers". Of course, the feedback is T, but the result is F T since (3 5 
7) is not an instance of the subjects H, but is an instance of the 
target. Again, they should generate a new H. At the point where the 
subject's confidence in their H is high, based on T feedback, they will 
then propose that particular H as being the target. They are again told 
either T, their H is the target or F, it is not.
  I'm sorry that this has gotten so long, however I believe you now have 
the necessary background. For anyone who missed my first post, I'm 
running under DOS on a pentium 90 with 32mb. I'm using a (loop for i from 
1 to (end-value) while (< x y) do ... where end-value is 21 & x 
represents the subjects confidence level in their H, while y is 0.9. Both 
y & end-value are experimenter manipulated. x varies based upon feedback 
from the experimenter (T or F). The ... represents calls to the various 
functions which generate H's & their relevant experimental number 
triplets. Some of these functions generate number sequences which are random 
evens, random odds, any 3 numbers, evens increasing by 2, or any 3 
increasing numbers with a constant difference, as well as all relevant 
permutations of these. There are functions to generate positive & 
negative tests and one which determines if the subject's H is equal to 
the target. A few of the functions are recursive & some call others. 
Everything works fine (at least in regards to the stack overflow problem) 
until end-value is > 21. At that point, I get a stack overflow & the 
program terminates.
  It seems to me that perhaps the stack is not being properly popped when 
a function finishes, or is the "stack" in "stack overflow" not the 
processor stack, but a stack that the interpreter is keeping? If that's 
the case, could it be a similar problem - that it's not being properly 
popped? Any help will be appreciated.
  The random number problem occurs after 4 runs of the program. The first 
run might produce (8 4 2) & (10 20 30), with different sequences on the 
2nd & 3rd runs. However, the 4th run will again produce (8 4 2) & (10 20 
30). I've tried to reset *random-state* before each run, but that seems 
to exacerbate the stack overflow problem! Any suggestions?
  Thanks. Again, I'm sorry this got to be so long.

   Vance Marshall
   askvance@spruce.flint.umich.edu