Talk:Bitmap

It seems quite a few of the examples don't fulfill the task. The task asks for 3 procedures, Create, Get, and Set, but only two or three of the examples have them.

Also, I'm kind of unclear on the "get the color" procedure. For example, C++ returns a boolean? I thought the point was to return the pixel's color? --Mbishop 08:02, 20 February 2009 (UTC)

The boolean return value indicates success. The C++ GetPixel routine returns the color by modifying three variables the caller passes into it. The alternative would be to return a special data type, or a packed integer. Many C++ environments have the special datatype, such as Win32's RGBTRIPLE, RGBQUAD and COLORREF, but it's not strictly C++, and they're not really necessary. And returning a packed integer would require the caller to do their own processing. Using pointers or references as arguments is a common idiom in C++. However, I can add another C++ example that provides those three types as arguments to SetPixel and return values for GetPixel, and throws exceptions on failure instead of returning false. --Short Circuit 09:00, 20 February 2009 (UTC)

What is unclear to me is, can we use the existing bitmap image services of the language, or should we implement it from scratch using e.g. arrays? In RapidQ, I used QCanvas object. It has built-in methods for filling image, for drawing pixel and for reading pixel color, so there is no need to define any procedures. Many BASIC versions write directly to display hardware (e.g. in DOS or when using OpenGL or DirectX). Can this be used or should we have an off-screen image storage? --PauliKL 16:31, 20 February 2009 (UTC)

I would say it is OK to use device contexts, hardware buffers etc. So long you can implement the task from this category. However it could become quite tricky when it comes to digital filtration and other image processing techniques, because drawing contexts are usually oriented only to rendering. --Dmitry-kazakov 20:24, 20 February 2009 (UTC)

I would argue that it's appropriate to use any and every OS-specific support libraries, as long as it's not to the exclusion of other approaches. I don't think "exclusion of external libraries" is idiomatic to any language that supports them.

As for issues surrounding drawing contexts...I only have experience with graphics programming with GDI on Win32, but DCs there can be attached to memory buffers for offscreen rendering; It was likely essential for double-buffering on early graphics hardware with limited onboard memory. I expect most languages support similar mechanisms one way or another.--Short Circuit 04:38, 21 February 2009 (UTC)

I believe it's ok, until you can manipulate the buffers (basically, peeking and poking pixels some way, i.e. if you can do a "get pixel" and a "put pixel"), so that you can implement filters or whatever else, using the same buffer or another one as output. I was thinking about Perl and ImageMagick or Perl and Imglib... I believe also the main aim is to provide a framework for algorithms that manipulates data that can be thought as images, and so shown. --ShinTakezou 14:51, 21 February 2009 (UTC)

Interface vs Implementation

I noticed that Mbishop separated Modula-3's interface from its implementation last night. I think that's actually a very good idea, and should be done for any language where it's considered best practice. --Short Circuit 17:22, 23 February 2009 (UTC)

About Fortran I gave up; separating interface and implementation would mean to make the whole stuff a lot longer; and it would make sense if one wants to give the compiled code (while not undisclosing source) and make in the same time people to use the library. --ShinTakezou 23:53, 27 March 2009 (UTC)

Amount of comments

This is in particular related to J section. I completely agree that everybody has his own style of documenting the code, and J particularly favors brevity. However, in my opinion, for someone new in J extra comments could be quite helpful, and the purpose of this site is to show how to solve simple tasks.

So, I'd appreciate opinions about what is, in practice, a good level of commenting here for such a language.

A good comment could succinctly convey the purpose of the verb, and even help catch errors in the implementation, which may go unnoticed even with some examples of use. Without phrases like "For the basic bitmap structure, this way to store data is likely the most convenient and natural for manipulating with J." one could wonder why this particular data structure was chosen for the task in hand. Avmich 17:57, 29 August 2009 (UTC)

I totally agree that standalone code should describe the purpose and interface of the verbs/functions defined. However on this site (and for this page) the task description at the top of the page lays out the spec for each of the verbs given, the choice of name for each of those verbs makes it clear which is which rendering the repetition of that spec superfluous and in my opinion it actually detracts from the impact of the entry. None of the other languages repeat that description for each of their functions or document their interfaces, in fact many have no comments at all! I think that the commented example usage section shows more succinctly and clearly the interface for the verbs than a description would.

Regarding the comment re choice of structure - in my opinion the idea of the task (and site in general) is to show how "best" to complete a task using various languages. The default assumption therefore, is that the approach shown for a language is the most convenient and natural method. If it is not, then a comment would certainly be appropriate, or perhaps the less natural approach should be replaced with a more natural approach for the language.

Regarding the allocImage and fillImage verbs, I'm not sure the current definition for fillImage is really "filling" an existing image, instead it creates a new image with the same shaped structure as an existing one. I think the main issue here is that allocating an uninitialized image isn't really "natural" in J. Instead it would probably be more common to combine the two steps as one. Maybe it would be better to make that comment and replace the current definitions of allocImage and fillImage with the following which takes the desired size as the right argument, with an optional left argument specifying the colour with black as the default? --Tikkanz 00:38, 30 August 2009 (UTC)

<lang j>createImage=: 0&$: : ($~ 3 ,~ ]) myimg=: createImage 7 5 NB. create a 7 by 5 bitmap (black) myimg=: 255 255 255 createImage 7 5 NB. create a 7 by 5 white bitmap</lang>

The site seeks to aid two groups of users. One group consists of people who want to learn a language; To that end, the site seeks to aid learning that language by comparing how a familiar or desired task is accomplished in that language with how something is done in a language the visitor is already familiar with. The other group are the developers of languages and other tools. Several times in the history of the site, languages have been shown to have elegant solutions (or at least to be capable of solving) to problems where no such solution was thought to exist. At other times, language developers have found unexpected quirks, inconveniences or inabilities that they were then able to document and resolve in their develoment process. Additionally, what may be the greatest aid Rosetta Code offers to language developers, advocates and enthusiasts is the exposure that their language gets along side other languages that are perhaps more better known.

The purpose of an individual task is whatever the creator of the task had in mind; Anyone is free to create a task and show how it may be accomplished in two or three languages of their choice. Anyone who provides a solution for the task is free do code and document that solution however they wish, so long as the solution fits the task, and so long as they're aware of and acknowledge normal editing concerns (as linked to at the bottom of every editing form.)

Having an explanation of the spec as it applies to the language provides context and therefore improves that solution's readability and accessability by providing context, which is always a good thing. The task description doesn't require the documenting of the solution's code with respect to the defined spec, and there's no sitewide policy demanding it, so that documentation isn't required. That doesn't mean it's unwise. --Short Circuit 05:01, 30 August 2009 (UTC)