Talk:Bitmap: Difference between revisions

added two header sections to put the TOC in the proper place.
(→‎The J implementation: add note re changes on main page)
(added two header sections to put the TOC in the proper place.)
 
(4 intermediate revisions by 4 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 69 ⟶ 71:
<lang J>fillImage=: $~ $</lang>
 
When exactly two verbs (functions) are placed side by side, in isolation, J treats them specially. 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.
 
5 (* !) 3
Line 153 ⟶ 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)