Changes between Initial Version and Version 2 of Ticket #22
 Timestamp:
 Jun 10, 2011, 2:37:57 AM (6 years ago)
Legend:
 Unmodified
 Added
 Removed
 Modified

Ticket #22
 Property Component changed from algorithms to io

Ticket #22 – Description
initial v2 1 1 Representing bitmaps as a 3D array isn't ideal because there's no way to perform a map over all the pixels. 2 2 3 With this representation 3 With this representation: 4 4 {{{Array DIM3 Word8}}} 5 5 … … 8 8 {{{map1 :: (Array DIM1 a > Array DIM1 a) > Array DIM3 a > Array DIM3 a }}} 9 9 10 However, that doesn't work because we can't guarantee that the worker function always returns an array of the same length as the original. Because of this we can't guarantee that the result is rectangular .10 However, that doesn't work because we can't guarantee that the worker function always returns an array of the same length as the original. Because of this we can't guarantee that the result is rectangular, and Repa can only deal with rectangular arrays. 11 11 12 If instead we had represented bitmaps as 13 14 {{{Array DIM2 (Word8, Word8, Word8}}} 12 If instead we represented Bitmaps as: 13 {{{Array DIM2 (Word8, Word8, Word8)}}} 15 14 16 15 Then we could use the original map function and there'd be no problem. 16 17 Note that using triples is just as efficient as using a DIM3 array. Repa uses unboxed `Data.Vector`s to store the manifest array elements, and this library will unpack a vector of triples into three separate vectors holding each of the elements. There are no intermediate tuple constructors or pointers in the underlying representation.