I see you've made a few small edits recently. For small stuff, please use the "This is a minor edit" checkbox. --glennj 12:49, 4 December 2011 (UTC)
Good call on removing that "gratuitous dig on recursion" in the Factorial task. What a foolish thing to say, especially given that tail recursive solutions are possible with the accumulator-passing trick.22.214.171.124 06:50, 6 January 2012 (UTC)
- Thank you. The same claim is in in the Fibonacci task, and I agonized over whether to remove that as well. I don't like the wording, and of course efficient recursive solutions exist there as well, but it is true that simple doubly recursive solutions rapidly bog down. —Sonia 16:54, 6 January 2012 (UTC)
- I think I might have added both of those notes long ago. I hadn't had any experience with tail recursive optimization and was just basing it on my limited knowledge. Maybe it would be better if it specified that doubly recursive solutions slow down quickly? For what it's worth, Recursion seems to handle it better. Any improvements to language-neutrality in any of those pages would be nice. --Mwn3d 17:46, 6 January 2012 (UTC)
Updating Go Bitmap tasks
It appears that you did the Go code for the various Bitmap tasks.
Would you have any objection if I changed them all to use the API of the standard
For the top Bitmap task it could just be showing how to use the
image/draw packages (which I already added). Optionally, if it was deemed instructive for comparison with other languages, it could also include a stripped down version of the definitions of the types needed/used from the Go source (which would be very similar to what you have there, just using the
image API) or just a link to the Go source.
For most of the other tasks it would just be translating it to fit with the standard packages.
E.g. for reading PPM it'd call
image.RegisterFormat, use the standard
Decode function signatures and return an
image.Gray if PGM is also supported and detected).
For writing PPM it would work with any
Similarly things like Bitmap/Bresenham's_line_algorithm can trivially be made to work with any
- Yes, that's me. No, that's fine with me to change any of that stuff. Using the standard library image packages as much as possible sounds good. It looks like a number of languages just demonstrate their image libraries rather than reimplement them and there's no consensus on the talk page. I think it's best if Go shows a standard library solution.
- By the way the work you've been doing here on RC is great. Many of the existing Go solutions predate Go 1 and look by a fresh pair of eyes would be good for any of them. —Sonia (talk) 04:17, 22 August 2014 (UTC)
- Great, thanks for the speedy reply. Since many of the Bitmap tasks are inter-related I'll probably wait until I have most/all of them ready to go before making further changes to avoid leaving inter-task inconsistencies for too long. I'll look at doing something with the top task that does more than just demonstrate the API as well.
- As for the other Go stuff I've been doing here, feel free to comment or criticize any changes/additions I've made. In general I've been taking the Wikipedia view of "be bold" but that can easily lead to doing too much or making something worse and I don't want to annoy anyone. One thing I tried on a few of my first edit/additions but have since stopped doing (after asking about it on IRC) is including Go playground links. I thought it would be great for someone browsing a task and curious about something in a Go example to be able to trivially run/edit it. However since there is no easy way to keep the playground link synced with the example code (or better, automatically make a playground link) it's probably not a good idea. I've been meaning to add a paragraph on the Playground to the Go page but haven't gotten a round to it yet. — Dchapes (talk) 12:16, 22 August 2014 (UTC)