Anonymous user
Talk:Odd word problem: Difference between revisions
→Explanations
Line 9:
:: 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. --[[User:Ledrug|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 not 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 on how I implement anything that's not a part of the interface.) Anyways, as things stand right now, it seems like any interesting educational elements would buried in the noise. --[[User:Rdm|Rdm]] 05:06, 4 November 2011 (UTC)
:: Operations are restricted precisely because it's not about text processing. You can <code>ungetc</code> a <code>getchar</code>, but you can't necessary unget a generic <code>get_some_input</code>. I never said anything about memory; output with buffering is your interpretation (data saved in a callstack frame or closure isn't normally considered "buffering"). The only actual constraint is "no saving in an array", which could tick J people off, but the intention here is to suppress, in your words, output with buffering, and favor ways of reordering of code flow constructs. Of course any useful calculation can be refactored, Turing showed that with his tape. The question here is, can you refactor some task in certain ways. --[[User:Ledrug|Ledrug]] 13:03, 4 November 2011 (UTC)
== Other References ==
| |||