10564  Paths through the Hourglass
Moderator: Board moderators

 Guru
 Posts: 647
 Joined: Wed Jun 26, 2002 10:12 pm
 Location: Hong Kong and New York City
 Contact:
10564  Paths through the Hourglass
Can someone post some critical input? I tried tons and tons of cases by hand and it works..
Last edited by Larry on Tue Oct 14, 2003 9:09 pm, edited 1 time in total.
Not very critical, but anyway:
Answer:
Perhaps slightly more interesting: for an hourglass with n = 20, s = 39, consisting only of ones, the answer is
Code: Select all
6 60
3 5 1 7 0 9
2 6 9 7 4
0 5 3 9
3 7 6
6 8
5
1 7
4 1 5
2 6 4 5
4 2 1 7 4
3 1 6 8 8 5
Code: Select all
34
1 RRRLRRRRRR
Code: Select all
274877906944
0 RRRRRRRRRRRRRRRRRRRLLLLLLLLLLLLLLLLLLL
Hi Larry,
my algorithm is also using recursion and hashing. I calculate the sums of the paths in the lower part of the Hourglass and store them using STL's map. As a key I use the sum along the path and with it I associate the number of paths with that sum and the first path I found (since I also enumerate the paths in lexicorder).
In the second part of the algorithm I enumerate the paths in the upper part of the Hourglass and try to complement the sum along the path with a sum from the map.
My program outputs correct results for all input I tested but the OJ says TLE. Help me to speed up the program. I think that this is the idea of the solution.
my algorithm is also using recursion and hashing. I calculate the sums of the paths in the lower part of the Hourglass and store them using STL's map. As a key I use the sum along the path and with it I associate the number of paths with that sum and the first path I found (since I also enumerate the paths in lexicorder).
In the second part of the algorithm I enumerate the paths in the upper part of the Hourglass and try to complement the sum along the path with a sum from the map.
My program outputs correct results for all input I tested but the OJ says TLE. Help me to speed up the program. I think that this is the idea of the solution.
I don't know for what reason I decided to use a map. I could index a vector or even an array instead. Now everything is OK (I also found some bugs in my program).
However I didn't know that the map is organized as a balanced search tree. I thought that a hash table is used. So my intention was to use the map exactly as a hash table. So is it true that actually there is no container in STL which I could use as a hash table? Of course SGI provides the hashmap class with their implementation of STL but it is not included in the standard. So the OJ denies it.
However I didn't know that the map is organized as a balanced search tree. I thought that a hash table is used. So my intention was to use the map exactly as a hash table. So is it true that actually there is no container in STL which I could use as a hash table? Of course SGI provides the hashmap class with their implementation of STL but it is not included in the standard. So the OJ denies it.
I've used the hashmap class in several of my solutions (though the last time was a while ago). Have you really tried this, or do you assume it just because it's not part of the standard? Because in that case, there must have been some change of compiler and/or flags.
But to answer your question: no, in STL by the book, there is currently no container which is guaranteed to work like a hash table (in terms of complexity).
But to answer your question: no, in STL by the book, there is currently no container which is guaranteed to work like a hash table (in terms of complexity).
How to?
Can anyone explain me how to solve this one?
I'm thinking on it a lot and I yet could not find a way to solve it... May be you can give me some tips on how to solve this one...
Thanks,
JP.
I'm thinking on it a lot and I yet could not find a way to solve it... May be you can give me some tips on how to solve this one...
Thanks,
JP.