Anonymous user
Talk:Odd word problem: Difference between revisions
→Explanations: more about intent
(→Explanations: more about intent) |
|||
Line 10:
: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)
::: This is exactly the kind of discussions we hit with [[Longest_string_challenge|The Longest String Challenge]] and took several rounds of discussion to get settled down. And the J folks will naturally ask how do you interpret the intent of this in a language that depends on arrays. You're also going to see discussions around solutions that use something that bends the restrictions and if they should be considered a cheat. Probably both where people try to get around the restrictions and where they will be wondering if they crossed a line by mistake. Hence there is an element of challenge in it. In any event you're likely going to have to spend more time explaining intent and such in the task description. Please understand, I'm not trying to be critical - it's just that I've been through all of this before. It took up way more of everyone's time than I expected.
== Other References ==
| |||