[Chart] Heat map/image support

[Tim Docker]

Hi Ben,

It's good to here that you are finding the Chart library useful.

>  My first thought (option A) was the following,
> 
>        data HeatMap z x y = HeatMap { heat_map_values_ :: [(x,y,z)]
>                                     , heat_map_cell_size_ :: (x,y)
>                                     }
> 
> Unfortunately, it seems that this isn't going to work so well as I can't
> ensure that types x and y have a Num instance (for addition)

Why is this? The toPlot type class might be problematic, but you can
just write a non-polymorphic function:

    data HeatMap z x y = HeatMap { heat_map_values_ :: [(x,y,z)]
                                 , heat_map_cell_size_ :: (x,y)
                                 }

    heatMapToPlot:: (Num x, Num y) => HeadMap x y z -> Plot x y


Another possible representation might be:

    data HeatMap z x y = HeatMap { heat_map_x_values_ :: [x]
                                 , heat_map_y_values_ :: [y]
                                 , heat_map_z_values_ :: [AlphaColour Double]]
                                 }


> The last option (option C) would be to use the approach taken by
> matplotlib, viewing a heatmap as an image. This has the disadvantage of
> requiring the user to ensure the image properly positioned and scaled on
> the axes (although this could be wrapped) but avoids the costly task of
> drawing each rectangular cell individually (which takes 12s on my
> machine for a 500x500 cell map).

That sounds disappointingly slow. Which version of cairo are you using? I seem
to remember on haskell-cafe a post indicating that there were some recent significant
speed improvements.

> That being said, I think image support
> would be useful (perhaps from a Repa array?), even if it is decided that
> this is not the proper way to handle heat-maps.

Yes. I think image support could be useful. However, I'm pretty unfamiliar with
the available haskell array libraries. For chart I'd want something sufficiently
fast, but also with a stable API.

> Lastly, after the interface issues have been decided and the code
> settled a bit, I'd happy to submit the code for merge into
> Chart-proper.

I'm happy to accept patches for Chart - there's been many from various people
over the years. My acceptance criteria are:

     - the code is clean and fits with the existing style (I'm not too fussy
        here)
     - there's a test case
     - we don't introduce substantial additional dependencies

Thanks,

Tim