A Quicker Way Than Brute Force to solve a problem

This is a discussion on A Quicker Way Than Brute Force to solve a problem within the C Programming forums, part of the General Programming Boards category; I just want a few ideas of ways to sort through some info besides brute force.
I am trying to ...

Say you have a list containing the cases. You compare the sticks that are below( the second in each pair ) with every single above ones ( the first in pair ). If you find one above that isn't equal with any of the belows, you take that pair off the list. If you find no value, then it's Impossible. If the list becomes empty, it's Valid.

I think what I just described is the brute force algo, but why would it take 45 min???

Say you have a list containing the cases. You compare the sticks that are below( the second in each pair ) with every single above ones ( the first in pair ). If you find one above that isn't equal with any of the belows, you take that pair off the list. If you find no value, then it's Impossible. If the list becomes empty, it's Valid.

I think what I just described is the brute force algo, but why would it take 45 min???

Your code appears to be O(sticks * lines) in big-Oh notation and I'm guessing that those are high numbers. Any minor tweaks probably wont bring down the execution time that much. I expect that they've got the time limit set such that no O(sticks * lines) implementation can complete in under the time limit.

There are some similarities with how this code operates with that of how a naieve prime sieve works. My thoughts on improving the speed would be to apply the same kind of optimisation that The Sieve of Eratosthenes applies to prime sieving, to this problem.

There are some similarities with how this code operates with that of how a naieve prime sieve works. My thoughts on improving the speed would be to apply the same kind of optimisation that The Sieve of Eratosthenes applies to prime sieving, to this problem.

Wow. that makes a lot of sense, and what i have been trying to reach. I have been looking through prime sieving and it has given me possible ideas to try or add to what I have been trying. As soon as I can figure out how all the variables are related, i'll be in business, which is a bigger hassle than i think it will be haha.

A totally separate approach is to eliminate the need for looping over every line of the input to check each stick. Instead, when you read the file in sort the over/under relationship into buckets which reduces the search time. What I did for a quick test is have an array called is_above. Each entry in is_above[x] is a list of sticks which are on top of stick x. Se for each input line <upper, lower>, you'd do add_to_list(is_above[lower], upper). You make each entry of is_above a linked list or an array depending on how you want to do it - but I'd recommend a linked list to start since you'll be doing lots of random deletes from it later.

This way, instead of searching over a million lines to see what's possibly above a given stick, you can just check to see if is_above[x] is empty or not. This replaces a search of a million lines with a single test.

Then you just run through is_above[x], looking for entries which are empty and removing them. Removing is simple - add it to the results list and remove all references to stick x in any of the is_above[x] lists. You can do this brute force (i.e. iterate over every entry of each list in each is_above[0..sticks-1]), or you can be smarter and create a second list as well. This one keeps track of all the sticks which are below the current entry. When you remove a given stick x, iterate over this second list (call it is_below[x]) - the full content of this list will be the complete set of is_above[] entries which hold the stick you're removing. You'll then remove x from the lists at each of those locations in is_above[] - that last bit is still a linear search but will still shrink the run time quite a bit.

An interesting problem to solve in a 5 second run time limit. A million sticks seems a bit bold!

I thought the array algorithm could work (and be substantially faster than the OP posted), but for a million sticks, in < 5 seconds??

I'm not real confident about that.

Seems like you need a linked list, where the sticks can be inserted and deleted, anywhere in the list, as they are either read in from the data, or the sticks are removed by the program.

Then I took some straws and tossed them into a pile on the kitchen table. LOTS of those straws wound up resting on top of more than one straw. I'm not sure if that would make the way I was thinking about the linked list, into the linked list from hell, or not. Just seemed ugly, at that point.

Then a little voice inside said "This could be a problem for Dancing Links", but I don't know enough about it yet. It's a coloring problem algorithm, but with a bit of adaption, it's VERY fast solving Sudoku, and other problems - and it uses linked lists like crazy!

If I were doing a program for this today, I'd use an array, but optimize the way it's used, so it would be fast, but I'm doubtful it could solve the puzzle with a million sticks, in less than 5 seconds.