There's an array of values from 1 to n. It isn't sorted. We have to sort it, but there are only to ways to move: third element to beginning or last element to beginning. How to do that ?
>>12
That's the special case where the third element is the last element. So you'd be moving the same--IHBT
Name:
Anonymous2010-10-24 9:37
>>13
Yeah ? So add one more:
2 1 3 4
First three elements aren't sorted, so we try to do that:
3 2 1 4
1 3 2 4
2 1 3 4
And we're in home one more time.
>>14
Alright then, switch the conditions around. It took me 5 whole seconds to think of this. I'm quite surprised it didn't stand up to such intense scrutiny.
Name:
Anonymous2010-10-24 11:16
>>14 2 1 3 4: 4 2 1 3 (last-->1) 3 4 2 1 (3-->1) 2 4 3 1 (3-->1) 1 2 4 3 (last-->1) 4 1 2 3 (3-->1) 3 4 1 2 (last-->1) 2 3 4 1 (last-->1) 1 2 3 4 (last-->1)[/m]
The real question is if you can build an intuitive algorithm out of these two rules. I doubt the problem can be made to compute in polynomial time.
Name:
Anonymous2010-10-24 11:43
To me it almost seems like a version of the Tower of Hanoi problem, but that could just be me.
Name:
Anonymous2010-10-24 14:41
>>16
Reading over my own post, I mislabeled a step, accidentally a swap, and messed myself up. Redo; alternate:
2 1 3 4:
4 2 1 3 (last-->1)
3 4 2 1 (last-->1)
2 3 4 1 (3-->1)
1 2 3 4 (last-->1) (done)
>>18
So what's the algorithm? Or are you just solving that one case?
What about if (third < first) {
swap (third)
} else if (last < first) {
swap (last)
} else swap (min(third, last))
>>22
What? There's no connection.
It's pretty easy for the solvable cases.
Name:
Anonymous2010-10-24 19:15
Here's a brute force solution. Generate every possible sequence of moves and filter out the move sequences that don't sort the list. Lists of even length are sortable, but some odd lists aren't sortable.
>>27
A brute force solution would have to run to infinity - any combination of moves could be the right one.
Unless you used memoization that is, and checked to see if every possible move got you to the list of previous values. Otherwise, yeah, to brute force it would take infinity.
Simplify the operations a bit; last → first is just rotation; use that to seek, and you have just one operation: move any element two positions forward.
For even sized arrays this lets you move any element anywhere, for odd-sized arrays you have to first rotate the element to the correct modulo-2 position, and you'll end up with a sorted or almost sorted array.
A more interesting question is how to prove the unsolvable cases can't be solved. I found an invariant using the Lehmer code — probably, but it's kind of a pain to make a formal proof.
Name:
Anonymous2010-11-04 11:01
>>46
What do you mean by 'correct modulo-2 position' ?
>>53
This is the fourth of five. The three before it are laughable and doable by either tree search or even simple Haskell list comprehension and mapping/Prolog hacks, if the provided memory is sufficient. The third one is a joke; I'm assuming I'm too tired and missing something.
>>55,57
Remember folks, if you dislike his post or his blog, it's because you're "insecure" or "uneducated." Heaven forbid he could actually be a douche.
>>60
I'll take a knowledgeable, interesting ``douche'' over someone whose only contribution to /prog/ consists of whining in every fucking thread because Xarn once called him a name.
>>54
Bear in mind that these are for kids from 16 to 19 years old, and this is only first of three rounds. Yeah, they are easy, but I would really like to see, how do you solve them using search trees in reasonable time complexity.