Talk:Bitmap: Difference between revisions
An explanation for the J implementation
(→Amount of comments: You're on the case so I'm happy) |
(An explanation for the J implementation) |
||
Line 49:
::::: Having had a loop at those examples, it's clear that excessive terseness is an issue with J code (since it can lead to things that are a challenge to comprehend) and that you're already on the case. Which is very good. In the specific case of comments, they're good anyway, since even a novice can quickly learn to remove them. It'd be greater if we had some syntax highlighting too; even the basic kind helps ever so much. —[[User:Dkf|Donal Fellows]] 08:00, 31 August 2009 (UTC)
== The J implementation ==
First, its probably worth noting that the person writing the specification for "Basic bitmap storage" probably thought that the operations defined here would be useful. But that's not really the case for J's implementation. Useful J image manipulation primitives would best be thought of as operations on layers, not operations on pixels.
That said, here's a breakdown on how the J implementation works:
<lang J>allocImage=: $&(,:0 0 0)</lang>
Here 0 0 0 represents one pixel, and (,:0 0 0) is a one element list containing a 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)
12 102 1002
<lang J>fillImage=: $~ $</lang>
Two verbs (functions) side by side, in J are special, syntactically. The one on the left has its normal dyadic meaning, the one on the right has its normal monadic meaning.
10 (+ -) 1
9
Also, the ~ modifier creates a new function based on the original (but with its arguments swapped, left and right.
1 -~ 10
9
Finally, the monadic meaning of $ is the dimensions of the array. So, $ finds the dimensions of our bitmap and $~ creates a new array with those dimensions. The items of the list on the left are color values, and they are repeated as necessary to build the new array.
<lang J>setPixels=: (1&{::@[)`(<"1@(0&{::@[))`]}</lang>
This one is bit noisy -- unfortunately, J sentences which amend arrays usually have lots of words in them. Basically, x f`g`h} y is an operation which modifies elements of an array, creating a new array with those elements. The new elements of the array are specified by (x f y), the indices of the array are specified by (x g y), the array itself is specified by (x h y).
Here, 1&{::@[ is the contents of the second box in the left hand argument. [ is the left identity function.
1 [ 2
1
And J arrays are indexed starting from 0. And {:: is a primitive which indexes an array and extracts the contents of a box. (A box is, in essence, a reference to an array.)
Perhaps it's also worth noting that ; is used to manually construct lists of boxes.
(2 4 ; 255 255 255)
+---+-----------+
|2 4|255 255 255|
+---+-----------+
(2 4 ; 255 255 255) (1&{::@[) _
255 255 255
Similarly, 0&{::@[ is the contents of the first box in the left hand argument. These are meant to be pixel coordinates, and <"1 puts each each list of coordinates in its own box.
(2 4 ; 255 255 255) (<"1@(0&{::@[)) _
+---+
|2 4|
+---+
The problem statement does not require support for lists of coordinates, but it would be rather silly for a J implementation to not support such lists.
Finally, ] is the right identity.
(2 4 ; 255 255 255) ] _
_
Thus:
(0 1 ; 255 255 255) setPixels allocImage 2 4
0 0 0
255 255 255
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
<lang J>getPixels=: <"1@[ { ]</lang>
The only new operation here is { which indices elements from an array.
0 1 getPixels (0 1 ; 255 255 255) setPixels allocImage 2 4
255 255 255
1 1 getPixels (0 1 ; 255 255 255) setPixels allocImage 2 4
0 0 0
| |||