Talk:Odd word problem

Explanations

Obviously, this task is not about text processing. Rather, it's about conditional code execution order. The even words are straightforward, while reversing odd words are easy with, say, recursion, with the catch that the word end marker (punctuation) needs to be processed after the recursion has returned. If peeking ahead is allowed, then this difficulty is removed and the whole thing becomes quite moot. --Ledrug 20:06, 3 November 2011 (UTC)

So this is a modified version of the problem that has been linked to? The solutions there seem to use buffers and peeking a lot. The site also says that the words will be a maximum of 20 characters long. Unless I'm missing changes in the spec later in the discussion, maybe there should be no link at all to that site (just to avoid confusion). --Mwn3d 20:12, 3 November 2011 (UTC)

I only linked there for the problem description, not their solutions. C2.com isn't exactly known for its example code qualities. I couldn't find a good ref to the problem anywhere else, and Dijkstra's original is in a 200+ page pdf that requires subscription to download. If you think this task description is clear enough, feel free to remove the link. --Ledrug 20:46, 3 November 2011 (UTC)

I guess I need to further clarify: this is not about text processing. Reversing English words and reading/writing a-z is about as unineresting as it can get, just pretend they are some token irreversible action that's potentially very complicated and cannot be simply queued as data, and you need to perform them in certain order depending on the input. In a strict sense, the current python and go code aren't correct, either (passing saved data by return). --Ledrug 22:21, 3 November 2011 (UTC)

I'm not seeing the problem with the previous Python code. Why not allow returning a character from the recursive function? How is returning a boolean any different that returning a character? —Sonia 23:34, 3 November 2011 (UTC)

The operations required by the task are only symbolic. "Reading a char" could represent arbitrarily complex data input, while "writing a char" could be be arbitrarily complex manipulation on such data. The boolean return only indicates if input is exhausted, while swapping variables or returning a value for deferred processing may mean detaching that data from the state under which it was obtained, and may be questionable. Using a closure or continuation to capture both data and state is maybe more to the spirit, but then since there's no way to precisely state what "complex" means here, I'd say the Go solution is acceptible. --Ledrug 00:09, 4 November 2011 (UTC)

If it's not about text processing, why the constraints on how the text is processed? It's hard to believe that there's any useful calculation that cannot be refactored. Also, a constraint on ordering does makes sense as a constraint on memory use. In essence, here, you seem to have three unrelated constraints: character at a time processing without buffering (specified explicitly). Character at a time processing with buffering (required for the reversal needed by the even/odd algorithm). And the even/odd algorithm itself. (Personally, if this is supposed to represent something useful, I would much rather be tackling the useful problem without any constraints how I implement anything that's not a part of the interface.) Anyways, as things stand right now, it seemslike any interesting educational elements would buried in the noise. --Rdm 05:06, 4 November 2011 (UTC)

Other References

• Dr. Dobbs The problem definition given here is slighty different. Punctuation is one or more blanks or a period. --Dgamey 22:17, 3 November 2011 (UTC)

Yes I changed that, because with blanks you can't tell if the delimiters have been incorrectly swapped. --Ledrug 22:21, 3 November 2011 (UTC)

Just thinking aloud here as I have been down the path of a programming challenge before and there will be lots of discussion about the usefulness of the task or why this or that restriction is in place, how it's artificial, etc. --Dgamey 10:41, 4 November 2011 (UTC)

If you modify the original challenge, you risk breaking it. I'm not sure if that happened here or not. But when it's something that a Knuth or a Dijkstra published there is some historical value to it. If it's a modified challenge, then the task description should at least be clear on that point. --Dgamey 10:41, 4 November 2011 (UTC)

Not being easily able to find a solution or statement of the problem creates problems. It makes it harder to have a clear discussion about the intent. Or for that matter to compare. I've been disappointed by the small number of available references online for this and the general low quality of them. BTW did I mention I hate paywalls. --Dgamey 10:41, 4 November 2011 (UTC)

The code examples on c2 are not helpful. They code about breaking the rules right off the start. Very disorganized. --Dgamey 10:41, 4 November 2011 (UTC)

Some of what I've found (sorry forgot the reference) refers to a 20 character limitation per word and I've seen snippets that suggest that this is used inside the readword as a buffer to reverse the word. This would fly in face of the no buffer rule (2). But again it really is hampered by not having a visible source for the original problem and an example of the solution that Dijkstra's class/group came up with. --Dgamey 10:41, 4 November 2011 (UTC)

• There is a Dijkstra archive at Utexas that was linked from c2. Some of the material is searchable but for some reason isn't jumping out in google searches. This led to EWD302 and the Odd Word Problem. The problem was a working example in front of a class with commentary and less a fully structured solution than a teaching excercise. --Dgamey 10:59, 4 November 2011 (UTC)