RE: [Haskell] 2-D Plots, graphical representation of massive data
I would like to ask the original poster, who asked first about the Matlab<->Haskell links what are her/his *concrete* problems...
I have a list of timestamps representing how long it takes a process to finish under different conditions. I also have a summary of the stages that process goes through. It is way too many numbers to make sense of them without some kind of graphical representation. I get all these information out of Haskell simulator. Therefore I would like to be able to do two things in Haskell: 1) analyze the data (mean, std dev etc) - that's the easy part and I more or less know how to do it in Haskell 2) display result of the analysis (pie charts, histograms, plots) Yulia
Zabiyaka, Yuliya wrote:
I have a list of timestamps representing how long it takes a process to finish under different conditions. I also have a summary of the stages that process goes through. It is way too many numbers to make sense of them without some kind of graphical representation. I get all these information out of Haskell simulator. Therefore I would like to be able to do two things in Haskell:
2) display result of the analysis (pie charts, histograms, plots)
If you don't need to interact with the display, the simplest solution is to generate graphics files. Personally, I would use PostScript, as I'm reasonably familiar with it and the Ghostscript interpreter is freely available. -- Glynn Clements <glynn.clements@virgin.net>
Glynn Clements proposes to:
Zabiyaka, Yuliya who wants ...
2) display result of the analysis (pie charts, histograms, plots)
If you don't need to interact with the display, the simplest solution is to generate graphics files. Personally, I would use PostScript, as I'm reasonably familiar with it and the Ghostscript interpreter is freely available.
Well, more than often proposing another *language* to process raw data might be an overkill. I wouldn't dare to suggest that somebody learns PostScript just for that. At least it was what I understood from Yuliya request for a Matlab 'plugin'... She needs rather a high-level processor with all the visualisation goodies, than another language. But who am I to answer on behalf of other people?... I think that the original idea - to generate raw textual data and read them by Matlab is the simplest one. Almost nothing to do from the Haskell side, just to output a file, in free format. From the Matlab side - use fscanf or textread. And then invoke your pies, exploded or not, or hist, or rose or whatever. I did it several times, since I like to teach computer graphics and image synthesis using functional languages, but the final nice image is hard to make with Haskell (though, in Clean a bit easier, sorry for advertizing the competitor...) Of course, there is always the wish to have the One which Rules Them All. For example use directly some graphic packages available for Haskell, e.g., wx. But this is an extremely heavy enterprise... Even Daan Leijen did not provide many good examples. Jerzy Karczmarczuk
On Sat, Aug 28, 2004 at 02:01:40AM +0200, karczma probably wrote:
Glynn Clements proposes to:
Zabiyaka, Yuliya who wants ...
2) display result of the analysis (pie charts, histograms, plots)
If you don't need to interact with the display, the simplest solution is to generate graphics files. Personally, I would use PostScript, as I'm reasonably familiar with it and the Ghostscript interpreter is freely available.
Well, more than often proposing another *language* to process raw data might be an overkill. I wouldn't dare to suggest that somebody learns PostScript just for that.
Postscript is not that horrible.
I think that the original idea - to generate raw textual data and read them by Matlab is the simplest one. Almost nothing to do from the Haskell side, just to output a file, in free format.
<horrible `postscript for newbies' starts> Postscript output for simple (w/o axes, numbers and such) graphs is also simple. Suppose that you have the stages numbered and the times calculated. In a raw text, you would print, say, (without the "> ")
0 10 1 20 2 11 3 23
where the first number is x and the second y. In a Postscript file, you would write
0 100 moveto 100 200 lineto 200 110 lineto 300 230 lineto stroke showpage
(I just multiplied the numbers by 100 and 10 to suit the A4 paper size a little better). This would get you a zigzag in the lower-left corner. It helps to read `0 100 moveto' like `moveto 0 100' if you want to understand something. Another option is to do this:
0 100 moveto 10 200 lineto stroke 10 200 moveto 20 110 lineto stroke 20 110 moveto 30 230 lineto stroke showpage
(stroke is called for every segment of the zigzag). The size of the `screen' is about 500x700, with an origin of (0,0) in the lower-left corner (cartesian coordinates, y is up). Actually, this is not quite valid Postscript (no EOF, etc) but Ghostscript will grok it. <horrible `postscript for newbies' ends> The benefit (at least for me) of this is, that when you have a large plot, each point of which is calculated for a reasonable time, you can pipe the output of your program to Ghostscript ("prog | gs") and see it displayed `in real time', just as output. This really helps if you are tuning something and don't want to wait for the whole plot to display and only want the first few results. YMMV. Certainly, full-featured pie charts require a bit more understanding of Postscript, so if you want them fast, it would be easier to go with Matlab or whatever. HTH, -- DoubleF Keep Cool, but Don't Freeze - Hellman's Mayonnaise
karczma wrote:
Glynn Clements proposes to:
Zabiyaka, Yuliya who wants ...
2) display result of the analysis (pie charts, histograms, plots)
If you don't need to interact with the display, the simplest solution is to generate graphics files. Personally, I would use PostScript, as I'm reasonably familiar with it and the Ghostscript interpreter is freely available.
Well, more than often proposing another *language* to process raw data might be an overkill.
I wasn't proposing *processing* the data in PostScript.
I wouldn't dare to suggest that somebody learns PostScript just for that.
Nor would I.
At least it was what I understood from Yuliya request for a Matlab 'plugin'... She needs rather a high-level processor with all the visualisation goodies, than another language.
To go back to the post to which I was replying, giving a little more context:
I get all these information out of Haskell simulator. Therefore I would like to be able to do two things in Haskell: 1) analyze the data (mean, std dev etc) - that's the easy part and I more or less know how to do it in Haskell 2) display result of the analysis (pie charts, histograms, plots)
From this, I assumed that the intent was to actually do the statistical processing in Haskell, and that the only outstanding question was "how do I draw stuff?".
Well, there are lots of ways in which you could draw stuff from Haskell. One is to use an in-process graphics library (e.g. GLUT/OpenGL, wxHaskell, GTK+HS). However, if your Haskell environment doesn't already include these, it could be highly non-trivial to actually get to the point where you can use them. Another is to use the core I/O functions (e.g. writeFile) to generate files for an external program. Either approach requires that you learn (or already know) the details of a graphics library or file format. If you don't already know one, I don't feel that PostScript would necessarily be any more involved than e.g. OpenGL or GDK. You don't really have to understand the *language* as such; there's no reason why you can't treat it as simply data, i.e. just write lots of 'show x ++ " " ++ show y ++ " lineto\n"'. -- Glynn Clements <glynn.clements@virgin.net>
These awful graphic problems are immortal... Glynn Clements comments my suggestion about using PostScript as the output interface
Well, more than often proposing another *language* to process raw data might be an overkill.
I wasn't proposing *processing* the data in PostScript.
Well, if you think about writing a PostScript program, containing - instead of raw data, say 10, 25, 65, the commands 0 10 moveto 1 10 lineto 2 25 lineto, etc., with stroking, filling, curveto's, scaling - as proposes Sergey Zaharchenko, then you *do* write a data processing program in Postscript. Where the output goes, it is another story. Sergey gives some simple-minded examples, quite OK. But I challenge him or you to tell *to a newbie* how to perform the automatic scaling of the plot axes. And how to make an EPS document embeddable in another one with all those bounding boxes (which depend on the chosen scale, etc.) How to make legends. And histogram fills with patterns. No, don't tell me this is something self-evident. I know Postscript.
Well, there are lots of ways in which you could draw stuff from Haskell.
One is to use an in-process graphics library (e.g. GLUT/OpenGL, wxHaskell, GTK+HS). However, if your Haskell environment doesn't already include these, it could be highly non-trivial to actually get to the point where you can use them.
Another is to use the core I/O functions (e.g. writeFile) to generate files for an external program.
Either approach requires that you learn (or already know) the details of a graphics library or file format. If you don't already know one, I don't feel that PostScript would necessarily be any more involved than e.g. OpenGL or GDK. You don't really have to understand the *language* as such; there's no reason why you can't treat it as simply data, i.e. just write lots of 'show x ++ " " ++ show y ++ " lineto\n"'.
You don't need any special file format to prepare data for Matlab. Use free format, fscanf it into a matrix, and then call hist or whatever. The advantage is that all scaling, smoothing, annotating, filling etc. is there, at your disposal. Just imagine the amount of extra text which would have to be output by a Haskell program... The alternative, if there is no Matlab by hand, is Scilab, Gnuplot, etc. Also here, output data only, and let the formatting to be done by the specialized package. It would be a very good idea to prepare a comprehensive library of high-level Postscript codes, permitting to a Haskell programmer to output a well-tuned, colourful plot, with axes, etc. fast. A step in that direction has been made quite a time ago, the diploma thesis of Joachim Korittky: "Functional MetaPost"; see, e.g. the pages of Ralf Hinze, some doc by Marco Kuhlmann, and some work of Feri Wagner and (doc) Meik Hellmund. If you manage to find that stuff, the 'revival' of the system was rather chaotic... It is still not *very* high level, and for the moment it seems less appropriate for serious plots than piping raw data to Matlab or similar. But to draw diagrams or simplistic curves, why not? Jerzy Karczmarczuk
A bit off topic, but a haskell charting/graphic library designer would be wise to check out the highly successful python equivelant, pychart. It seems as though a library equivelant in features to pychart is exactly what the original poster is looking for. David
Glynn Clements <glynn.clements@virgin.net> writes:
2) display result of the analysis (pie charts, histograms, plots)
If you don't need to interact with the display, the simplest solution is to generate graphics files. Personally, I would use PostScript
I would output to Gnuplot...
as I'm reasonably familiar with it and the Ghostscript interpreter is freely available.
...for basically the same reasons. It's also on a higher level than PS, you can output data on a presentation-independent format, and it's easy to change the type of plot or other presentation details later. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
Ketil Malde wrote:
2) display result of the analysis (pie charts, histograms, plots)
If you don't need to interact with the display, the simplest solution is to generate graphics files. Personally, I would use PostScript
I would output to Gnuplot...
as I'm reasonably familiar with it and the Ghostscript interpreter is freely available.
...for basically the same reasons. It's also on a higher level than PS, you can output data on a presentation-independent format, and it's easy to change the type of plot or other presentation details later.
Right. But, for the same reason, it's also less flexible. My reply was aimed at a slightly more general question, i.e. how to draw stuff generally, rather than statistical visualisation in particular. It wasn't entirely clear (at least, from the second post) how much of the process was meant to be done in Haskell. Going back to the first post, it seems likely that Yuliya may be willing to hand the task off at an earlier stage. If that is the case, using something like Gnuplot or Matlab would probably be more suitable. -- Glynn Clements <glynn.clements@virgin.net>
participants (7)
-
David Sankel -
Glynn Clements -
Jerzy Karczmarczuk -
karczma
-
Ketil Malde -
Sergey Zaharchenko -
Zabiyaka, Yuliya