Comments on: Google Treasure Hunt http://knolleary.net/2008/05/19/google-treasure-hunt/ taking my thoughts for a walk Tue, 06 Jan 2009 14:53:17 +0000 http://wordpress.org/?v=2.7 hourly 1 By: Graham White: My Notes http://knolleary.net/2008/05/19/google-treasure-hunt/comment-page-1/#comment-10974 Graham White: My Notes Tue, 03 Jun 2008 08:54:24 +0000 http://knolleary.net/?p=162#comment-10974 <strong>Google Treasure Hunt Question 3...</strong> I've been keeping up with the Google treasure hunt as a bit of fun rather than seriously going after any prizes. At least one other guy at work has been joining me, Nick O'Leary has taken up the chal...... Google Treasure Hunt Question 3…

I’ve been keeping up with the Google treasure hunt as a bit of fun rather than seriously going after any prizes. At least one other guy at work has been joining me, Nick O’Leary has taken up the chal……

]]> By: kyb http://knolleary.net/2008/05/19/google-treasure-hunt/comment-page-1/#comment-10927 kyb Mon, 19 May 2008 21:54:31 +0000 http://knolleary.net/?p=162#comment-10927 Garh! I forgot that the !! operator uses 0 indexing, so I've actually worked out the paths for 54x31 there, and 700x7001. The line should of course have read lpaths w h = (pathlist w) !! (h-1) Giving the much more reasonable 12576607627510093891680 as the answer for 54x30. Stupid functional languages make writing code terser, but they don't make you do unit tests..... Garh! I forgot that the !! operator uses 0 indexing, so I’ve actually worked out the paths for 54×31 there, and 700×7001.

The line should of course have read
lpaths w h = (pathlist w) !! (h-1)

Giving the much more reasonable
12576607627510093891680 as the answer for 54×30. Stupid functional languages make writing code terser, but they don’t make you do unit tests…..

]]> By: kyb http://knolleary.net/2008/05/19/google-treasure-hunt/comment-page-1/#comment-10926 kyb Mon, 19 May 2008 21:43:09 +0000 http://knolleary.net/?p=162#comment-10926 When you can express it like that, a functional programming language is ideal for representing the problem. In haskell, it's very similar to the maths you've written paths :: Int -> Int -> Int paths _ 1 = 1 paths 1 _ = 1 paths w h = (paths (w-1) h) + (paths w (h-1)) Sadly, this very simple clean result doesn't run particularly fast because of all the unnecessary recalculations. It's fine for reasonable sized chess boards, but for 54x30, it just takes too long. Fortunately, I can rewite it using infinite list data structures to do calculations for boards up to 700x700 pretty quickly. pathlist 1 = 1 : (pathlist 1) pathlist w = 1 : zipWith (+) (tail (pathlist (w-1))) (pathlist w) lpaths w h = (pathlist w) !! h > lpaths 54 30 34795281102777926433648 >lpaths 700 700 294959524837744306828252296100196431889118842418611448310042626887713844240301344669221418924201133834586362108669293514159261183838468398317529191441988702194010301504997962347728460441001014741345267577517951466709716033852841470615296707712692490701757399994671266386683080388904495703431988378768656808247129499221896960761043426375293304777943548918650717879698187751931573856298150842797277067333789380956594922720 The idea is that (pathlist w) is a function that returns an infinite list of all boards w x h, so the first number is w x 1, the second is the number of paths for w x 2 and so on. The zipWith simply calculates the same way I was doing by hand - it's the number above plus the number to the left going on for ever. When you can express it like that, a functional programming language is ideal for representing the problem. In haskell, it’s very similar to the maths you’ve written

paths :: Int -> Int -> Int
paths _ 1 = 1
paths 1 _ = 1
paths w h = (paths (w-1) h) + (paths w (h-1))

Sadly, this very simple clean result doesn’t run particularly fast because of all the unnecessary recalculations. It’s fine for reasonable sized chess boards, but for 54×30, it just takes too long.

Fortunately, I can rewite it using infinite list data structures to do calculations for boards up to 700×700 pretty quickly.

pathlist 1 = 1 : (pathlist 1)
pathlist w = 1 : zipWith (+) (tail (pathlist (w-1))) (pathlist w)
lpaths w h = (pathlist w) !! h

> lpaths 54 30
34795281102777926433648

>lpaths 700 700
294959524837744306828252296100196431889118842418611448310042626887713844240301344669221418924201133834586362108669293514159261183838468398317529191441988702194010301504997962347728460441001014741345267577517951466709716033852841470615296707712692490701757399994671266386683080388904495703431988378768656808247129499221896960761043426375293304777943548918650717879698187751931573856298150842797277067333789380956594922720

The idea is that (pathlist w) is a function that returns an infinite list of all boards w x h, so the first number is w x 1, the second is the number of paths for w x 2 and so on. The zipWith simply calculates the same way I was doing by hand - it’s the number above plus the number to the left going on for ever.

]]>