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
