Talk:Odd word problem: Difference between revisions

 

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. --[[User:Ledrug|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). --[[User:Mwn3d|Mwn3d]] 20:12, 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. --[[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)

::: 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. --[[User:Dgamey|Dgamey]] 13:27, 4 November 2011 (UTC)

::: If the task really intends "no saving in an array" that makes the Omit/J I placed on this one even more appropriate. In J, "array" is the same thing as "memory" or "storage" or "register" -- there just isn't anything else, in J. But I would still like to make sense of the task, if that is possible. (And, right now, I have to admit that the task does not make sense to me -- especially the one about how one is not supposed to reverse the string.) --[[User:Rdm|Rdm]] 17:48, 4 November 2011 (UTC)

}</lang> it looks to me exactly like it is buffering a sequence of characters for later reversal. Except, of course, it is not buffering them in an efficient fashion (just storing the characters), instead, it is buffering them as a sequence of some internal data structure that allows code to be resumed. The TCL version must be doing something similar, with coroutines? Except that's still an array, it's just an array of something else. (For that matter a byte is an array of 8 bits...). Anyways, if the point is to use an array of incomplete function executions, I can do that in J. But the architecture would be exactly the same as the architecture I would use for reversing a sequence of characters, except bulkier (both in code, to create the wrapper functions, and execute them, and in data, to store the wrapper functions). And, since it is J, which you do not understand, this would be even harder to understand than a more simpler implementation. That said: <code>RUN=: ] bind 'a'</code> creates verb (a function) <code>RUN</code> which always returns the letter <code>'a'</code>, and <code><nowiki>RUNING=: RUN f.`''</nowiki></code> takes the verb <code>RUN</code> and returns a gerund (which is a noun -- an array, that represents the same concept that the original verb represented) which in this case is the definition of <code>RUN</code> (because <code>f.</code> extracts an anonymous definition from a name). which it saves under the name <code>RUNNING</code>. Or, I could have just done <code><nowiki>] bind 'a'`''</nowiki></code> and gotten a gerund wrapper for the character 'a'. ... anyways, I can build up a list of these and then later on apply J's reverse operator <code>|.</code> and then convert the resulting sequence of gerund to a verb which returns the sequence of results from the represented verbs, and give that verb its argument. In other words:<lang j> (|.] bind 'a'`(] bind 'b')`(] bind 'c'))`:0 ''

cba</lang> ... but I am not avoiding buffering here. I am not avoiding use of arrays. I am doing exactly what was forbidden. I am just wrapping each character with some bulk and then unwrapping it later, after reversing them... do you understand my dilemma now? --[[User:Rdm|Rdm]] 12:30, 5 November 2011 (UTC)''

::::::: The Tcl version is indeed holding values on the stack (with single assignment, as it happens) but that's explicitly allowed, whereas using an explicit queue or stack data structure would be not allowed. Also note that Tcl doesn't really like char-by-char input either, but it can work. If it's too onerous with J (can it read fixed with binary records, and if it can, can it read a record of size 1?) then that would be a good reason for omitting the task. –[[User:Dkf|Donal Fellows]] 13:53, 5 November 2011 (UTC)

:::::::: J stream input is line at a time, unless, for example, you are using sockets (the socket interface uses predeclared fixed-sized buffers). And, ok, yes, a hands off approach (using the call stack) would avoid using an explicit stack. But that's really still just a buffer... And, meanwhile, if I use sockets, I have to run another program to feed the socket (and that program would itself have to store a buffered string, which defeats the point of not using buffers, as a coding constraint -- why does it have to be a coding constraint and not an interface constraint?). --[[User:Rdm|Rdm]] 17:54, 5 November 2011 (UTC)

This task instead of being a normal task (which asks us to accomplish something) is currently specifying *how* we achieve that end. Specifically, it asks us to buffer a sequence of characters implicitly and not explicitly. Personally, I think that this kind of task bends the spirit of rosettacode: operations that can be implicit in one language may need to be explicit in another.

 

 

(Specifically, in this case, I would want to implement co-routines and character-at-a-time streams, for J. But in general we are supposed to be allowing "best effort" implementations, and not requiring specific language semantics.)

 

Unless someone has a better idea? --[[User:Rdm|Rdm]] 17:50, 6 November 2011 (UTC)