Talk:Odd word problem: Difference between revisions
Content added Content deleted
m (→Explanations: wrong place) |
No edit summary |
||
| Line 26: | Line 26: | ||
:::::: ''Oh, and the mandated use of (in this case character-at-a-time) streams (which J does not implement natively, since they are useless within the language itself) would add significantly more bulk and require platform dependent code (J does not natively support unbuffered character-at-a-time streams, but it does support dynamically linking to shared libraries...) so any educational value from the illustration of data wrapping/unwrapping would be lost in the noise... --[[User:Rdm|Rdm]] 12:49, 5 November 2011 (UTC)'' |
:::::: ''Oh, and the mandated use of (in this case character-at-a-time) streams (which J does not implement natively, since they are useless within the language itself) would add significantly more bulk and require platform dependent code (J does not natively support unbuffered character-at-a-time streams, but it does support dynamically linking to shared libraries...) so any educational value from the illustration of data wrapping/unwrapping would be lost in the noise... --[[User:Rdm|Rdm]] 12:49, 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) |
::::::: 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) |
|||
::::: I really do not know what you mean by "making order of execution flexible" -- it seems to me that you are doing exactly the opposite? Moreover, you earlier stated that you are explicitly trying to make the problem difficult -- but that strikes me as the essence of bad design? Anyways, I am not seeing the point or the gist, here. --[[User:Rdm|Rdm]] 22:03, 4 November 2011 (UTC) |
::::: I really do not know what you mean by "making order of execution flexible" -- it seems to me that you are doing exactly the opposite? Moreover, you earlier stated that you are explicitly trying to make the problem difficult -- but that strikes me as the essence of bad design? Anyways, I am not seeing the point or the gist, here. --[[User:Rdm|Rdm]] 22:03, 4 November 2011 (UTC) |
||
:::::: I understand your frustration. I don't know enough APL or J to even begin but I do know that there is a different way of looking at things. We saw it with the Longest String Puzzle/Challenge as well. I still think the task is under (or incorrectly specified) with respect to intent. I now thing that puzzles/challenges of this type are really properly categorized as 'curiosities'. So if I were to paraphrase, the basic problem is clear but the restrictions muddy the waters (also familiar). The 'read' method is given as unbuffered and destructive hence the no peeking, putting back, etc. The curiosity/challenge is in finding a way to reverse through program control alone without intermediate buffers. This works for most languages but I confess that I very quickly hit a wall when I try and think about this in APL or J. --[[User:Dgamey|Dgamey]] 02:41, 5 November 2011 (UTC) |
:::::: I understand your frustration. I don't know enough APL or J to even begin but I do know that there is a different way of looking at things. We saw it with the Longest String Puzzle/Challenge as well. I still think the task is under (or incorrectly specified) with respect to intent. I now thing that puzzles/challenges of this type are really properly categorized as 'curiosities'. So if I were to paraphrase, the basic problem is clear but the restrictions muddy the waters (also familiar). The 'read' method is given as unbuffered and destructive hence the no peeking, putting back, etc. The curiosity/challenge is in finding a way to reverse through program control alone without intermediate buffers. This works for most languages but I confess that I very quickly hit a wall when I try and think about this in APL or J. --[[User:Dgamey|Dgamey]] 02:41, 5 November 2011 (UTC) |
||