[racket] Request feedback on a boggle solver

[Jingjing Duan]

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?

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?

Thanks,
Jingjing

[Carl Eastlund]

On Sat, Sep 21, 2013 at 12:09 PM, Jingjing Duan <duanji...@gmail.com> 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

[Jay McCarthy]

I agree with Carl. You may also enjoy reading a post about my Boggle
solver when you're done with yours:

http://jeapostrophe.github.io/2012-05-14-boggle-post.html

> ____________________
> Racket Users list:
> http://lists.racket-lang.org/users
>



--
Jay McCarthy <j...@cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
____________________
Racket Users list:
http://lists.racket-lang.org/users

[Carl Eastlund]

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 <duanji...@gmail.com> 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

[Jingjing Duan]

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

[Carl Eastlund]

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

[Jingjing Duan]

Hi Carl,

Thank you very much for your kind feedback. I agree with you that having a single data structure will make the solution simpler. Let me ponder over that and see what I can come up with. 

Thanks,
Jingjing