Correct! Good planning. -- Matthias
On Aug 15, 2011, at 4:05 PM, Racket Noob wrote: > But, if I choose your second approach (function that picks and returns one of > the feasible configurations), than such function cannot be used in next > exercise 32.3.3 in which I have to construct function solitaire for solving a > puzzle. > > From: [email protected] > To: [email protected] > Subject: RE: [racket] HtDP Exercise 32.3.2 > Date: Mon, 15 Aug 2011 22:04:13 +0200 > > But, if I choose your second approach (function that picks and returns one of > the feasible configurations), than such function cannot be used in next > exercise 32.3.3 in which I have to construct function solitaire for solving a > puzzle. > > Subject: Re: [racket] HtDP Exercise 32.3.2 > From: [email protected] > Date: Mon, 15 Aug 2011 15:21:08 -0400 > CC: [email protected] > To: [email protected] > > > On Aug 15, 2011, at 3:10 PM, Racket Noob wrote: > > I don't understand this exercise: > > Exercise 32.3.2. Develop a function that, given a board and the board > position of a peg, determines whether or not the peg can jump. We call such a > peg enabled. > Develop a function that, given a board and the board position of an enabled > peg, creates a board that represents the next configuration. > > But, it may be the case that an enabled peg can jump to more than one of free > places. Thus, we can have more then one new configurations, no? > > Good catch. Now design a function that returns a list of next configurations > for an 'enabled' peg. Alternatively, design a function that picks one of the > feasible successor configurations. > _________________________________________________ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/users
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
