Changes between Initial Version and Version 2 of Ticket #22


Ignore:
Timestamp:
Jun 10, 2011, 2:37:57 AM (13 years ago)
Author:
Ben Lippmeier
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #22

    • Property Component changed from algorithms to io

  • Ticket #22 – Description

    initial v2  
    11Representing bitmaps as a 3D array isn't ideal because there's no way to perform a map over all the pixels.
    22
    3 With this representation
     3With this representation:
    44   {{{Array DIM3 Word8}}}
    55
    … …  
    88   {{{map1 :: (Array DIM1 a -> Array DIM1 a) -> Array DIM3 a -> Array DIM3 a }}}
    99
    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.
     10However, 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.
    1111
    12 If instead we had represented bitmaps as
    13 
    14    {{{Array DIM2 (Word8, Word8, Word8}}}
     12If instead we represented Bitmaps as:
     13   {{{Array DIM2 (Word8, Word8, Word8)}}}
    1514
    1615Then we could use the original map function and there'd be no problem.
     16
     17Note 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.