User talk:Sonia

From Rosetta Code
Revision as of 04:17, 22 August 2014 by Sonia (talk | contribs) (→‎Updating Go Bitmap tasks: change for the better)

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.24.85.131.247 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 image package?

For the top Bitmap task it could just be showing how to use the image, image/color, and 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.NRGBA (or image.Gray if PGM is also supported and detected). For writing PPM it would work with any image.Image. Similarly things like Bitmap/Bresenham's_line_algorithm can trivially be made to work with any draw.Image.

What do you think? I didn't want to make wide ranging changes without at least running it by you first. — Dchapes (talk) 00:53, 22 August 2014 (UTC)

Hello,
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)