User talk:Rdm

From Rosetta Code

Please fill out your user page with the help of the mylang templates (e.g., below) so that the wiki software can link you in to everything else nicely. Thanks! —Donal Fellows 19:59, 3 September 2009 (UTC)

{{mylangbegin}}
{{mylang|J|Wrote it}}
{{mylangend}}
Ok, done.. though I am not sure what guidelines I should use to judge how familiar I am with a language, so I likely could be more accurate if I knew how to judge myself. Rdm 03:50, 4 September 2009 (UTC)
Best advice when judge yourself - not to overjudge with your capabilities. And... better to put own nose to languages you know well, leave D alone, OK? ex-pert.... User:Vincent
This user is banned. See his talk page for the reasons. Rdm, I'm sorry for the abuse you and others have had to put up with from him. --Michael Mol 13:48, 6 May 2011 (UTC)
It is indeed quite likely that the D implementation of the multi-split algorithm I posted could have been replaced with a more efficient and/or more concise and/or more elegant implementation. I am sad that it's no longer possible to have that discussion with Vincent, though I understand that it's also possible that it may never have been possible to have that conversation with him. Anyways, it's really too bad, and I hope you never have to do anything like this again. But, I understand, and I hope it's not too hard on you, either. And, I am thankful that you are here for something like this when we need it. --Rdm 14:29, 6 May 2011 (UTC)
The terms for coming back are stated in his ban; he can come back if/when he's willing to have a discussion with me, and he can convince me he'll be able to have discussions like the one you wanted. (Convincing me of that kind of thing isn't hard; I have a pretty hard bias toward believing people are good. But if he convinces me and then proves otherwise, it's back to being banned.) --Michael Mol 15:08, 6 May 2011 (UTC)
It's entirely self-subjective, whatever descriptives you think best defines your familiarity. See my page for comparison. (Though I don't think anyone else uses my particular approach.) --Michael Mol 15:47, 4 September 2009 (UTC)
Ok, that works for me, thank you (there are so many dimensions to consider here, it's almost ridiculous). And I like the simplicity of Active vs. Rusty. Rdm 16:04, 4 September 2009 (UTC)

Ex-expert

Ex-ex-pert. Double negative. You're a pert. ;-) -- Eriksiers 22:26, 6 October 2009 (UTC)

The world needs more perts? Rdm 16:34, 16 October 2009 (UTC)
When doesn't the world need more perts? -- Eriksiers 16:02, 19 October 2009 (UTC)

Filling out Rosetta Code:Add a Task

Could I get you, Dkf and Paddy3118 to give Rosetta Code:Add a Task a thorough treatment of examination, debate and filling? Of the cross section of current users, I think you three are probably the most likely to be familiar with the general pattern and concerns of creating tasks. I added a bunch of my own thoughts in HTML comments in-line, and left a note in the talk page. --Michael Mol 17:15, 21 September 2010 (UTC)

I had read it, and superficially it seemed good, though I was planning on giving myself a few days to digest it. But the best test would be to try and create some new tasks based on its recommendations -- if these new tasks need work, which was not covered by the task description, we could go from there. Anyways, maybe I will try and add a task based on it -- having never done so before, I think I might make a decent test subject. --Rdm 17:26, 21 September 2010 (UTC)

Rule 90

I decided to move our discussion about Rule 90 here so Comps doesn't keep getting emails.

On "end states": the task doesn't have anything to do with checking for end states, so any work that you do there is extra credit and doesn't really apply. On other similar tasks: tasks in the sorting category usually do fundamentally different operations. Also, lots of those algorithms are the subject of discussion in academics for early programmers. There is more of a demand for separate tasks for each of those algorithms (though there really isn't much demand at all for the silly ones, but those came after the fact). You may be right about prime decomposition and counting in factors. In any case, the next generation in the Rule 90/104 processes can be implemented as such (at least in the languages I program in; J seems to be different in ways I don't expect to understand):

For each character in this generation
  Count the number of neighbors
  If the number of neighbors = x and this character is y, then
    the character in this position in the next generation is z
  ...more ifs for whatever rules there are...
return the next generation

Basically a few numbers change for x, y, and z for all the rules. The setup of this generation and counting the neighbors doesn't really need to change. Counting the neighbors doesn't need to change at all (unless you want to add more characters, but then it's not really a Rule x game). Forest fire also does a similar operation to Conway's Game of Life , but it has extra stuff added in like random numbers and extra types of cells. Wireworld expands on that still by adding another type of cell. The change between Rule 90 and Rule 104 amounts to using a different lookup table. --Mwn3d 17:31, 19 April 2011 (UTC)

I had actually said pretty much I had to say on this topic. And, I added a "Rule n" approach for J, on the One-dimensional cellular automata page, for just-in-case. --Rdm 18:15, 19 April 2011 (UTC)

202

Saw your 202x202. Made me chuckle, I admit defeat - my study is warm enough so I'll not compute a larger one :-)
--Paddy3118 15:25, 30 May 2011 (UTC)

J writeups

Your J writeups are appreciated. I don't always read them, and I don't even know J. Still, I see them as useful and valuable. In fact, for some time, I've been thinking that the more appropriate place for them might be right next to the code they describe. --Michael Mol 20:44, 5 July 2011 (UTC)

Thank you -- I am glad that I have something of an audience even if it's small. That said, I am not always certain of the quality of my comments (especially when the code drifts and my explanation was based on an older revision -- but also I sometimes write from an overly narrow point of view, where I do not treat important issues and instead go into excessive detail on narrow technical issues -- but these are fixable problems). That said, I think my comments tend to a bit too bulky to be part of the main page (which is why I have been dumping them on the talk page). But perhaps we/I should be linking them from the main page? --Rdm 21:03, 5 July 2011 (UTC)
The talk page is OK, but it might get crowded if other language communities start to imitate. You could also put them on a separate page and link to it from the example. Something like "Task/J/Explanation" or "Task/J/In-depth_explanation" might work. "Writeup" might feel too academic for some language communities (but it's less academic than "essay" which I see in the J community a lot), so a more general term might be best. Also it'd be nice to pick a standard name now in case we want to add this to a template or edit form as an optional input. --Mwn3d 21:09, 5 July 2011 (UTC)
I sort of like Task/J/Explanation, now I just need some round tuits. --Rdm 21:30, 5 July 2011 (UTC)
I too welcome the writeups. Their are pro's and con's to putting them in the talk page - currently, I am more likely to read them as I tend to also follow talk pages to find issues with tasks. Keeping such explanations there might also promote inter-language discussions of the kind "I essentially copied this apart from that, where my language has this ...". --Paddy3118 06:17, 6 July 2011 (UTC)
Ok! And, since I currently am low on the tuits, I am going to approach Short Circuit's suggestion this way: after other languages start including writeups (explanations of intermediate code goals, rationales for choices of data representation, explanations of atypical language features, whatever else), and the talk pages start getting crowded, I will happily help move J writeups to Task/J/Explanation pages and leave behind links. Until then, I'll be waiting on other people, and occasionally adding links from the task page to the existing writeups. Does this sound good? --Rdm 13:14, 6 July 2011 (UTC)
I'll note that the Perl 6 examples tend to have descriptions on the task page with their examples. Not sure I really like a lack of in-page presence (such as simply being on the page, or being transcluded from another page, or being retrieved and displayed via a little JavaScript magic), but I'm sure something will be ultimately worked out. As long as it's around, somewhere, and links are better than nothing. :) --Michael Mol 15:44, 6 July 2011 (UTC)
Sure, and J will also have descriptions on the page itself. The talk page writeups have typically been for either (a) detailed descriptions of issues which I hope would be obvious to someone that can read J and that has a copy handy for testing against, and/or sometimes (b) algorithmic concepts which are not at all J specific (issues which are almost worthy of inclusion in the task description). Mostly, though, I use the talk page for added-depth coverage of issues which require a lot of words and which are nothing like the treatment of the task by other languages. And, ok, quite possibly sometimes of the writeup text could be migrated to the task page -- if you see examples of that, I think you should feel free to copy the text over yourself or (if your comfort level is not that high) to call out the issue on the talk page. But my overall feeling is that a lot of those writeups are outside the scope of the task page. --Rdm 16:07, 6 July 2011 (UTC)

Non-continuous subsequences

Your first C example in Non-continuous subsequences is fine, while the second one using GMP is quite, well, nuts. I'd be tempted replace it with something more general (not limited by bits in int) without the nuttiness, although the value of generating all subsequences of a sequence longer than 32 is questionable. --Ledrug 05:57, 25 July 2011 (UTC)

I think someone else wrote the GMP example. --Rdm 10:41, 25 July 2011 (UTC)