[MO-java-dev] CVS: no-stone-unturned/doc/xdocs random.xml,1.6,1.7

[Nat P. <np...@us...>]

Update of /cvsroot/mockobjects/no-stone-unturned/doc/xdocs
In directory usw-pr-cvs1:/tmp/cvs-serv26779

Modified Files:
	random.xml 
Log Message:
Extended introductory paragraph.


Index: random.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/random.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- random.xml	14 Aug 2002 13:54:58 -0000	1.6
+++ random.xml	7 Nov 2002 13:25:48 -0000	1.7
@@ -10,20 +10,25 @@
 <title>Introduction</title>
 
 <para>
-Pseudo-random behaviour is used in many applications.
-For example, in video games pseudo-randomness is used to portray 
+Many applications exhibit random or pseudo-random behaviour.
+For example, in video games use pseudo-randomness to portray 
 natural behaviours that are too complex to simulate accurately, 
 or to add variety to behaviours that are too predictable when 
-simulated algorithmically.
+calculated algorithmically.   Cryptographic algorithms
+use random number generators extensively, as do optimisation
+algorithms such as genetic programming and simulated annealing.
+But how can one test behaviour that is, by its very nature,
+unpredictable?
 </para>
 
 <para>
-Testing random behaviour is not complex.  You will not need to use
-statistical analysis, unless you are actually writing a new random
-number generator.  Instead, as in many test driven designs, you
-will end up separating the objects that direct activity from
-those that effect activity so that you can mock one to test
-the other.  In the case of random behaviour, the object directing
+In this chapter, I hope to show that testing random behaviour is not
+complex.  You will not need to use statistical analysis, unless 
+you are actually writing a new random number generator.  
+Instead, as in many test driven designs, you will end up 
+separating the objects that direct activity from those that effect 
+activity so that you can mock one to test the other.  
+In the case of random behaviour, the object directing
 the activity is a random number generator. You can use a mock 
 generator to feed deterministic values into the objects under test.
 So far, soo good, but it turns out that testing random behaviour