Computer Science Canada 2004 CCC S5 solution with memoization troubles |
Author: | zylum [ Thu Aug 12, 2004 1:59 am ] | ||||
Post subject: | 2004 CCC S5 solution with memoization troubles | ||||
i was bored so i tried solving the S5 using memoization since the grid can be 100 by 100 and plane old recursion will take too long to solve the problem. so i first programmed my recursive solution but when i try to implement a memoization table it fails.... without memoization:
with memoization:
in the case that im using the answer should be 8 any help implementing would be great |
Author: | wtd [ Thu Aug 12, 2004 7:20 pm ] |
Post subject: | |
Thank you for proving that obfuscated Java can be written. Cleaning it up so I can figure out just what the heck it actually does. |
Author: | bugzpodder [ Thu Aug 12, 2004 9:17 pm ] |
Post subject: | |
at the contest i wanted to use memoization but i used DP in the end, but i dont remember the reason. there may be some faulty logic (although i couldnt think of any now) although in theory most if not all DP problem can be done using memoization and vice versa. in your program why did you initialize memo AFTER you call best path? also, since memo stores the best amount, then you shouldnt keep amount as a variable right? |
Author: | zylum [ Thu Aug 12, 2004 11:44 pm ] |
Post subject: | |
wtd > the code looks bad in the forum view, try copying it to you editor. also if you still dont follow, i updated the "with memo" version to include commenting. bugz > oops, i didnt notice that i initialized the memo table after calling the function. it doesnt matter though since an integer is still greater than an integer variable which is not initialized. |
Author: | wtd [ Fri Aug 13, 2004 12:33 am ] | ||||
Post subject: | |||||
The primary thing you need to do is factor out a lot of the code into methods. Like checking to see if x and y are within the proper bounds. Being able to say:
Rather than:
Would make your code far more readable. |
Author: | bugzpodder [ Fri Aug 13, 2004 5:34 am ] |
Post subject: | |
zylum, i assume that you have fixed the initialization error but it still doesnt work (im not sure how java initializes so if you say it doesnt matter...) and what about the second point i've mentioned... i was wrong to say that you need to take out the amount variable, but i dont think you've updated it correctly. look into that |
Author: | wtd [ Mon Aug 16, 2004 12:28 am ] |
Post subject: | |
You mentioned the recursive solution being impractical for large datasets... Can you implement in any language, or does the contest limit submissions to Java? I ask because there are languages which do far more optimization for recursion. I'd reimplement in O'Caml for the heck of it, if you could provide a detailed explanation of exactly what the problem is. Even the CCC example doesn't provide much of an explanation of what's actually required. |
Author: | bugzpodder [ Mon Aug 16, 2004 7:11 am ] |
Post subject: | |
you can use whatever for stage 1... for stage 2 you must use C/C++/Pascal, and maybe java depending on the year |
Author: | wtd [ Wed Aug 18, 2004 2:20 pm ] | ||
Post subject: | |||
Ah. It's a shame you have to use one of those languages. Using a functional language you could get an incredible speed-up. Consider this particular problem, for example. A functional language could essentially give you the "memoization" for free, without writing additional code. Crazy you say? Not really. The reason Java, C++, etc. can't give you this is the presence of side-effects. A function called with the same arguments in these languages can't be guaranteed to have the same result. In many functional languages, this can be assumed. If I have a map called my_map which takes a row number and a column number...
Will always return the same thing, assuming my_map stays the same. As a result, the compiler can cache the result of that expression. Any future occurrences of that expression will simply be replaced by a constant value. As with the memoization example you wrote, the best path for any given start point will only be calculated once, even if we use a recursive solution. |
Author: | wtd [ Wed Aug 18, 2004 9:39 pm ] | ||
Post subject: | |||
And after all this talking about how great a solution in O'Caml would be, I should probably offer one. Yeah, it looks better with syntax highlighting, especially since O'Caml has a... robust... syntax. Highlighting is available for many editors, including popular ones like vim and Textpad on Windows. All it needs is some logic to let it read in the map from a file.
|
Author: | wtd [ Wed Aug 18, 2004 10:28 pm ] | ||||
Post subject: | |||||
Attached is a solution I wrote that allows input files. I've added a .txt extension to the source file to make it possible to post here, since ".ml" seems to be blocked. Using the same simple test:
It gave the expected answer of 8. Using a more complex example:
It gave me 19. I don't have a working reference implementation to compare this to, so I'll ask if someone can test it. First thing I notice, though, is that both implementations seem to take virtually identical amounts of time, even though the level of recursion in the second example is far greater, even with all of the asterisks limiting potential paths. |
Author: | wtd [ Wed Aug 18, 2004 10:49 pm ] | ||
Post subject: | |||
And for fun I just sicced it on a file 990 lines long and 592 characters wide, randomly generated by this little Ruby program:
It had to think about this one, but computed the answer (whether correct or not, I don't know, though it should be) in a minute or two (I haven't been able to properly benchmark). How long would a file of that size take your Java example? (I'm not gloating. I'm genuinely curious if standard Java is robust enough for this kind of recursion.) |
Author: | bugzpodder [ Wed Aug 18, 2004 11:03 pm ] |
Post subject: | |
attach the file you used here and i'll happily compile my solution using java and give you the execution time using my PIII 660mHZ snail armed with XP |
Author: | wtd [ Wed Aug 18, 2004 11:11 pm ] |
Post subject: | |
See attachment. Oh, and I ran this example with O'Caml 3.07+2 on an AMD Athlon XP 1800+ with 256MB of RAM, 80GB HD, and Windows 2000 Professional. I'll give your time some leeway, considering the difference in computing power. |
Author: | wtd [ Thu Aug 19, 2004 2:44 am ] |
Post subject: | |
You know, I'm pretty sure there's an error in my algorithm. Working to correct it. Edit: the correct version is included, along with Sys.time, which outputs the time the process has been running in seconds as a float. I'm on a very slow machine, so I'll test this against that huge file tomorrow. Might also whip up a C version for comparison's sake. |
Author: | wtd [ Thu Aug 19, 2004 5:51 am ] |
Post subject: | |
I hate to look like a fool, but I was wrong in this case. O'Caml doesn't provide automatic memoization of functions. In this case the only real benefit is the opportunity to apply the O'Caml optimizing compiler (which creates wickedly fast code), and the ability to work in a really nice language. |
Author: | zylum [ Tue Aug 24, 2004 9:45 pm ] |
Post subject: | |
i think your solution is wrong because the second test case you posted should return more than 19... remember the guy has to go from (0,0) to (width,0) and can move up/down/right and cannot go to places he's already been. |
Author: | wtd [ Tue Aug 24, 2004 9:55 pm ] |
Post subject: | |
zylum wrote: i think your solution is wrong because the second test case you posted should return more than 19... remember the guy has to go from (0,0) to (width,0) and can move up/down/right and cannot go to places he's already been.
Yeah. I fixed that. I was being a moron when I wrote that. |