This series of questions by this Anonymous Monk has the uncanny sound of someone who hasn't applied much discipline in deriving a proper method. It's delved into the realm of 'voodoo programming' where special cases are added on top of previous hacks to ensure that page 3 gets the right 20 elements. No offense or anything, but when you're going in circles, it helps to reconsider the technique.

Whenever I get flummoxed with problems involving iteration or geometry, I whip out the graph paper and stay away from the keyboard until I'm certain of the correct approach. Keyboards force you to think in terms of the symbols, which is not always the most effective way to think.

Draw a diagram of the database's records. Draw little lines or brackets showing the region you want for a given query. If real-world parameters like '20 elements' is too cumbersome to draw in the diagram, use smaller parameters like 4 or 5. (This trick will also help you properly parameterize your solution in code later.)

Once you're sure you've identified all the parameters, simulate the query on another sheet with a fresh diagram of the database. Be the computer. Be ruthlessly naive and follow only the steps you've properly and fully explained. If you can't empathize with your student, you can't teach the student.

Then you're ready to type in the pseudocode in English. Write your pseudocode as a series of comments. In plain English. With little text versions of your diagrams if that helps. In just plain English without variable names at all. Explain what you want done before you make the computer do it. Did I mention you should write in plain English? Strategy in comments.

Finally, translate the pseudocode into real code underneath each sentence. Explain in computer language exactly how they should accomplish the goal. Use the parameters you've identified, and use the steps that will work. Tactics in code.

The proper code will have an obvious reason for each statement and variable, and you won't need special cases or hacks or adjustments for any weird artifacts that aren't a crucial part of your problem definition. Someone else has a .sig which reads something like "I know I'm on the right track when I'm deleting code in order to provide more functionality."

--
[ e d @ h a l l e y . c c ]