Talk:Bitmap: Difference between revisions

added two header sections to put the TOC in the proper place.
m (signed it)
(added two header sections to put the TOC in the proper place.)
 
(7 intermediate revisions by 5 users not shown)
Line 1:
==some examples don't fulfill the task==
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.
 
==unclear on "get the color"==
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? --[[User:Mbishop|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 [http://msdn.microsoft.com/en-us/library/dd162939(VS.85).aspx RGBTRIPLE], [http://msdn.microsoft.com/en-us/library/dd162938(VS.85).aspx RGBQUAD] and [http://msdn.microsoft.com/en-us/library/dd183449(VS.85).aspx 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. --[[User:Short Circuit|Short Circuit]] 09:00, 20 February 2009 (UTC)
Line 57 ⟶ 59:
 
That said, here's a breakdown on how the J implementation works:
 
Note that <tt>allocImage</tt> and <tt>fillImage</tt> have been subsequently replaced by more complicated (but more useful) verbs on the main page. However the descriptions below are still of interest and to some degree relevant to the current verbs <tt>makeRGB</tt> and <tt>fillRGB</tt>.
 
<lang J>allocImage=: $&(,:0 0 0)</lang>
 
Here 0 0 0 represents one black pixel, and (,:0 0 0) is a one element list containing athat pixel. Meanwhile <lang J>dimensions $ items</lang> creates an array with the specified dimensions from the list of items on the right. Meanwhile, & curries an operation. For example:
 
+&2 (10 100 1000)
Line 67 ⟶ 71:
<lang J>fillImage=: $~ $</lang>
 
TwoWhen exactly two verbs (functions) are placed side by side, in isolation, J aretreats special,them syntacticallyspecially. The one on the left has its normal dyadic (2 argument, or combining form - arguments appear on each side) meaning, the one on the right has its normal monadic (one argument - which appears on the right) meaning.
 
105 (+* -!) 13
930
5 * ! 3
30
5 * 6
30
!3 NB. 3 factorial
6
 
Also, the ~ modifier creates a new function based on the original (but with its arguments swapped, left and right.
Line 145 ⟶ 155:
 
[[User:Rdm|Rdm]] 00:03, 1 September 2009 (UTC)
 
== Deprecation ==
 
I'd like to see this deprecated and replaced with something better. Better in what way? I'm not sure. I just know I created this task ages ago, and I don't particularly care for its not-so-good representation of bitmap processing. --[[User:Short Circuit|Michael Mol]] 14:09, 4 October 2010 (UTC)
 
== Making the task description less strict ==
 
I'd like to slightly rephrase this part of the task description:
 
<div style="background:#eee; margin-left:2em; font-style: italic">
If possible provide a function to allocate an uninitialised image,
given its width and height, and provide 3 additional functions:
* one to fill an image with a plain RGB color,
* one to set a given pixel with a color,
* one to get the color of a pixel.
</div>
 
...to this:
 
<div style="background:#eee; margin-left:2em; font-style: italic">
If possible, show how to:
* allocate an uninitialised image, given its width and height
* fill an image with a plain RGB color
* set a pixel to a given color
* get the color of a pixel
</div>
 
The difference is to '''not''' explicitly demand one "function" per feature. I propose this because:
* In some languages (e.g. Perl 6), it does not make sense to have separate getter and setter functions for accessing the same property (i.e. get/set a pixel)
* Constructors and methods (which is what most languages use to implement this), are not technically considered "functions" in some language traditions.
* Functional languages may be able to provide more elegant solutions if not restricted to this object-oriented paradigm.
 
So let's not needlessly restrict the task to a particular language's (or set of languages') way of doing things, and relax the description like proposed above. Since it won't invalidate any existing solutions (and thus won't be very disruptive), I don't think it's too late to make such a change.
 
Objections?<br>
--[[User:Smls|Smls]] ([[User talk:Smls|talk]]) 11:00, 19 July 2015 (UTC)