Jingjing, The new code you've written only follows the HtDP design recipe superficially.
First of all, none of your contracts actually tell me what the valid inputs and outputs of each function are. For instance, the contract for build-position-to-neighbor is: (listof lists) -> (hashof position to neighbors) But this suggests to me that I could call it like this: (build-position-to-neighbor (list (list "the" 'first "list") (list "list" 'number 2) (list (list (list))))) After all, that argument is a list of lists. Nevertheless, that doesn't seem like what build-position-to-neighbor should actually accept. Your contracts need to be based on explicit data definitions. Descriptive phrases like "list of lists" or "hash of position to neighbors" are not precise enough. Second, I think if you write data definitions for this program, you'll find something surprising: there are at least two different data definitions for a boggle board hidden in your functions. For a program that's all about processing a boggle board, you in fact manipulate many different kinds of lists and hash tables. It would be simpler, and more in the style of HtDP, to write a single data definition for a boggle board, and use that data definition for every function that operates on a boggle board. Finally, your test cases are not particularly exhaustive. When testing a function, you should start with the smallest possible example. Write at least one base case test, at least one test for a single step beyond the base case, and at least one test larger than that. That way, when a test goes wrong, you don't just know that the function is broken, you have some idea how and why it is broken. Carl Eastlund On Tue, Sep 24, 2013 at 11:18 AM, Jingjing Duan <[email protected]>wrote: > Hi Carl, > > I've cleaned up the code a bit and added tests to all the functions. Do > you mind taking another look? Don't hesitate to give comments even if they > are trivial. The more the better. I'm a total scheme/racket beginner. > Thanks. > > https://github.com/jduan/boggle_scheme/blob/master/boggle.rkt > > In the mean time, I'm going to take a look at Jay McCarthy's solution. I > didn't want to look at his code before because I didn't want his code to > affect my refactoring. > > > Thanks, > Jingjing > > > On Sat, Sep 21, 2013 at 9:14 PM, Carl Eastlund <[email protected]> wrote: > >> Looking forward to to your followup! >> >> Carl Eastlund >> >> P.S. copying to the mailing list so everyone's in the loop. >> >> On Sat, Sep 21, 2013 at 8:25 PM, Jingjing Duan <[email protected]>wrote: >> >>> Hi Carl, >>> >>> Thanks for your great feedback. Let me try to rewrite the code, this >>> time by following the recipes from HTDP. Will send out another email once >>> I'm ready! >>> >>> Thanks, >>> Jingjing >>> >>> >>> On Sat, Sep 21, 2013 at 10:25 AM, Carl Eastlund <[email protected]> wrote: >>> >>>> On Sat, Sep 21, 2013 at 12:09 PM, Jingjing Duan <[email protected] >>>> > wrote: >>>> >>>>> Hi, >>>>> >>>>> I've been reading HTDP and I'm about half way through. To apply what >>>>> I've learned in the book to a bigger exercise, I decided to write a boggle >>>>> solver. >>>>> >>>>> You can find the code here: >>>>> https://github.com/jduan/boggle_scheme/blob/master/boggle.rkt >>>>> >>>>> Any feedback is greatly appreciated. I'm specifically looking for >>>>> feedback on: >>>>> >>>>> 1. Did I break the problem into right components? >>>>> 2. How can I make the code more idiomatic? >>>>> >>>> >>>> If you're halfway through HtDP, you should know the value of data >>>> definitions, contracts, and test cases. I don't see any of those in your >>>> program. That makes it very hard to tell what's going on in the code, and >>>> whether it's doing the right thing. Adding them after the fact should >>>> improve your code's readability. Adding them earlier -- during the design >>>> process of the code itself -- helps break things down into components in a >>>> natural way. >>>> >>>> >>>>> 3. Why is code so slow? It can take minutes to solve a 4 by 4 board. >>>>> The same board can be solved by a ruby program I wrote in much less time, >>>>> like a few seconds. I know recursive functions are a big reason but is >>>>> there anything? >>>>> >>>> >>>> "Recursive functions" have nothing to do with the kind of slowdown >>>> you're seeing. Your program is simply doing too much work. Start adding >>>> simple test cases for your functions and you may start to get a clearer >>>> idea of where a lot of the work is being done. The process of adding test >>>> cases may also suggest simpler ways to structure your program, both in >>>> terms of making it more idiomatic and in terms of doing less work. >>>> >>>> You might get a lot out of restarting this boggle exercise from the top >>>> down, starting with the function find-all-words and going through the >>>> design recipe step by step. You may be surprised how different the result >>>> is from what you've written, and how much more natural the solution you get >>>> is. In my own experience, it is also a much quicker process than taking >>>> something written as a whole without the design steps, and trying to add >>>> them in after the fact. >>>> >>>> However you proceed, please feel free to share your results and any >>>> other questions you have with the list. We love hearing about stuff like >>>> this! >>>> >>>> Thanks, >>>>> Jingjing >>>>> >>>> >>>> No problem. Glad to see you're interested in HtDP and Racket! Good >>>> luck! >>>> >>>> --Carl >>>> >>> >>> >> >
____________________ Racket Users list: http://lists.racket-lang.org/users
