Fwd: Plotting Library

[Dominic Steinitz]

CCing to diagrams-discuss as this seems of general interest

Begin forwarded message:

From: Dominic Steinitz <dom...@steinitz.org>

Subject: Plotting Library

Date: 12 March 2013 13:35:55 GMT

To: dag...@gmail.com

Cc: Brent Yorgey <byo...@seas.upenn.edu>

Myself and several of my friends would find it useful to have a plotting
library that we can use from ghci to quickly/easily visualize data.
Especially if that data is part of a simulation we are toying with.
Therefore, this proposal is for: A gnuplot-, matlab- or plotinum-like
plotting API (that uses diagrams as the backend?). The things to emphasize:
* Easy to install: No gtk2hs requirement. Preferably just pure haskell
code and similar for any dependencies. Must be cross platform.
* Frontend: graphs should be easy to construct; customizability is not as
important
* Backend: options for generating static images are nice, but for the use
case we have in mind also being able to render in a window from ghci is
very valuable. (this could imply something as purely rendering to
JuicyPixels and I could write the rendering code)

Hi Jason,

I am very keen also to have a plotting library. This has been discussed on diagrams-discuss and I started putting together a GSoC proposal for it: http://www.haskell.org/haskellwiki/Diagrams/GSoC#Make_Plotting_As_Easy_As_Doing_It_in_R (BTW I am a mathematician / statistician but not the one mentioned in the proposal :-)).

I usually create an ad hoc plot in diagrams which fits what I want at the time. It would be much nicer if a plotting library were available.

Dominic.

[Jan Bracker]

Hi Everybody,

I am interested in participating in the GSoC and the plotting library
sounds like a good project for me. I am currently involved in Sunroof
(a Monadic Javascript Compiler: https://github.com/ku-fpg/sunroof). I
think using a Sunroof backend for Diagrams might be a great
possibility to render your plots in the Browser on the fly and at the
same time produce static versions of the plot when needed.

Jan

2013/3/12 Dominic Steinitz <dom...@steinitz.org>:

> --
> You received this message because you are subscribed to the Google Groups
> "diagrams-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to diagrams-discu...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Brent Yorgey]

On Tue, Mar 12, 2013 at 09:35:37AM -0500, Jan Bracker wrote:
> Hi Everybody,
>
> I am interested in participating in the GSoC and the plotting library
> sounds like a good project for me. I am currently involved in Sunroof
> (a Monadic Javascript Compiler: https://github.com/ku-fpg/sunroof). I
> think using a Sunroof backend for Diagrams might be a great
> possibility to render your plots in the Browser on the fly and at the
> same time produce static versions of the plot when needed.

I think this sounds like a great idea. A couple thoughts:

* There are a few different directions you could take this. One
would be to directly create a plotting library as
described. Another would be to create a slightly more
general-purpose data visualization library, and then build some
specific types of plots on top of that. For inspiration see
e.g. the (now defunct) Hieroglyph library:

http://hackage.haskell.org/package/Hieroglyph

The idea is that it would be easy for users to create their own
new sorts of visualizations; they would not be stuck just choosing
from whatever types of plots the plotting library provides.

* Carter Schonwald was talking about working on a plotting library
too -- maybe he will write to the list soon and explain what he is
working on. Depending on how your goals align you might be able
to work with him/contribute to his project; on the other hand
having competing libraries in a certain space often ends up being
a win for everyone.

-Brent

[Carter Schonwald]

 Hey All,

First of all I agree with Brent's point about how any such plotting lib should  actually be a toolkit for declarative data vis. ggplot, for good or for ill, (well both, its great *and * terrible) is the current best point in that space, and I absolutely think that building a lib that does at least as well as the strong points in ggplot2 and substantially better than the weak points in ggplot2 should be feasible.

As Brent knows, I've been spending a lot of the past year generally trying to sort out building bits and pieces of a general data analysis tool chain. This actually started with wanting a ggplot2-like in haskell using diagrams, but i've spent most of the past year working on other bits and pieces (still am). Most of that tool chain is likely going to be proprietary for at least the next year, but it looks like I can pretty comfortably make the core data vis parts BSD3 style open source. (in fact, )

I'm now finally at the point where i *have* to get the plotting story worked out. I should have small usable starting codebase to codename "diaplotical" in ~ 2-4 weeks.  

Theres a few fungineering subtleties that come up in terms of doing this well:

• It should be FAST. Theres a lot of great ideas from techniques in computational geometry / GIS / etc that come in handy here. Eg: the complexity of an algorithm should depend more on the size of the output data than the size of the input data, thats a biggy
• Observation: I will always be looking at the figure / plot on paper or some sort of screen, and a plot where i have to zoom in IS the WRONG plot! These have finite resolution, i should use this to bound the level of detail / complexity of the rendering result. (eg doing an SVG scatter plot of a billion points is WRONG, no one wants a 1gb scatter plot, and that plot is still useless if you made it in a more space efficient png or something). Doing a density plot with a polygon per "pixel" of the density rendering would be 10s of megabytes instead, still large, but less insane, even if that might still be slow.
• observation: a good plotting / data vis  DSL should viewed as "compiling" its input into a diagrams value, because of all the summarization / aggregation that needs to be going on, plus the choosing 

Theres a bit more going on than just those bits, but those are some of the *obvious* pieces.  some point in the next 2-4 weeks i'll hopefully be doing a pre-hackage alpha release publically. 

thats a short version,

it'll be a bit easier elaborate further once i have a demo version out the door. I'm also a bit buried with consulting engineering + maybe getting some businesses to sponsor some of my development time this spring on this lib. 

point being: hopefully i can share some interesting glimmers of a nice data vis lib thats starting to be useful in a few weeks :)

-Carter