Re: [racket-dev] New plot library [Was: (to Jay) Re: What I'm working on]
Hi Neil, I've been using the new plot library for visualizing some benchmark results in three dimensions (# threads, amount of work, throughput). It's very easy to use, and the interactive 3d plots are great. I also plan to use the PDF export for my next paper. Thanks for making this available! My only request: a version of surface3d that takes as input a list of discrete points. I find the surface visualization more useful than a scatter plot, but I've had to code my own interpolation to make it work. I'm guessing surface3d is already doing its own interpolation (and of course sampling) so coding my own seems redundant. Thanks again, Aaron Turon On Fri, Aug 5, 2011 at 6:40 PM, Neil Toronto neil.toro...@gmail.com wrote: Redirecting this from Kevin back to the group, because I think at least plot2d is good enough for anyone to play with now. I've put all of it here: https://github.com/ntoronto/plt-stuff/tree/master/plot The main module files are meant to be plot2d.rkt and plot3d.rkt. Both contain tests right now. In particular, Kevin, the tests in plot2d.rkt show how to generate simple 2D plots and save them to files. (In fact, I've just added plot2d-file, which writes a plot to a file or output stream using any bitmap or vector format that Racket supports. I haven't tested it much, but it appears to work.) This code is very young and fairly untested; standard warnings apply. (May pillage your families and murder your crops, etc.) The interface WILL change, so don't count on it. Neil T On 08/03/2011 09:41 AM, Kevin Tew wrote: Have a github link yet? I have a simple line graph I need to generate and would like to give your 2d plot a try. Kevin On 08/02/2011 11:33 AM, Neil Toronto wrote: Re-routing this email exchange to [racket-dev] for comments. Long story short: Jay roped me into replacing the current `plot' module by wrapping a plot library I was working on for my own use. (FWIW, I'm happy to finally contribute something!) Intended features: 1. Doesn't depend on an FFI to libplplot 2. Can automatically place plot area on functions and points 3. Uses parameters for keyword argument default values 4. Uses only dc% primitives / Is very pretty 5. Is more flexible (when using the new plot2d and plot3d modules) Linux screenshots: http://students.cs.byu.edu/~ntoronto/plot2d.png http://students.cs.byu.edu/~ntoronto/plot3d.png The first shows off the almost-finished plot2d. It's as fast as the original `plot', and `shade' is twice as fast. Props to Matthew and Linux's foreign drawing libs for making it look so nice. The second shows off 3d-plot-area%, which wraps a dc% with 3d drawing primitives. The new plot3d will be 1.5x-2x slower, but the new features (e.g. compositing 3d plots, contours) should be worth it. I'll push code to github soon, and ask for volunteers to verify that it looks good on Mac and Windows. Specific questions -- Matthew: It should look good on Mac and Windows if their drawing libs do subpixel-accurate, high-quality antialiasing. Do they? Doug and other heavy `plot' users: What can I add to plot2d and plot3d to make your life easier? Noel: Do you happen to have a kernel density estimator implementation that uses FFT or is otherwise more efficient than O(n^2)? Currently, (plot2d (density samples)) works, but is slow on large samples. Anyone: Are there any original `plot' features that should *not* be emulated in the new `plot' wrapper module? Anyone: Is it easy/possible to manipulate snip%s with, say, a click-and-drag? How about placing edit boxes on them? If it's not hard, I would like to make the 3d plots manipulatable after rendering. Neil T On 07/30/2011 02:01 PM, Jay McCarthy wrote: Yup, so that old programs will keep working. Will you support the line fitting? Jay On Sat, Jul 30, 2011 at 1:56 PM, Neil Torontoneil.toro...@gmail.com wrote: Sure can! Does compatible source library mean a bunch of wrappers for the functions plot currently exports? Neil On 07/30/2011 05:49 AM, Jay McCarthy wrote: Awesome. We've been wanting to throw it out for a long time. Can you make a compatible source library too... so we can replace it in the core? Jay On Fri, Jul 29, 2011 at 10:35 PM, Neil Torontoneil.toro...@gmail.com wrote: I've attached a screenshot of what I'm working on. It's a replacement for Racket's plot module. The plot module has these drawbacks: 1. It's not smart enough to automatically size plots to the things - renderers - you're plotting. A renderer is only a function that accepts an image snip, so the plotter can't compute a rectangle that contains it. 2. It depends on an external library, plplot. 3. It draws ugly curves because plplot can't draw lines with subpixel-accurate endpoints. Also, plplot messes up antialiasing when the curves are made of too many lines. Whatever Racket uses doesn't have this problem, at least on Linux.
Re: [racket-dev] New plot library [Was: (to Jay) Re: What I'm working on]
On 08/27/2011 11:26 AM, Aaron Turon wrote: Hi Neil, I've been using the new plot library for visualizing some benchmark results in three dimensions (# threads, amount of work, throughput). It's very easy to use, and the interactive 3d plots are great. I also plan to use the PDF export for my next paper. Thanks for making this available! You're welcome! My evil master plan is to beat R and come close to Mathematica, to remove one more reason for statisticians and other applied mathematicians to use something other than Racket. I'm going after the statisticians first, though. My only request: a version of surface3d that takes as input a list of discrete points. I find the surface visualization more useful than a scatter plot, but I've had to code my own interpolation to make it work. I'm guessing surface3d is already doing its own interpolation (and of course sampling) so coding my own seems redundant. I'll put something like that on my to-do list. As it is, 'surface3d' only appears to interpolate bilinearly because it uses sampled x,y,z coordinates as quad vertexes. But I don't think it would be hard to make it do bilinear interpolation for non-grid x,y coordinates, to come up with z values for grid x,y coordinates. (Oh, hang on. The contour line endpoints are interpolated - it's part of the marching squares algorithm - so there's that.) FWIW, the latest update I pushed added contracts to all the 2D plot functions and parameters, and some incomplete documentation for them. (Run build.sh in the scribblings directory. Check out the quick start.) It also minimizes the margins on 3D plots, does better depth sorting, and handles NaNs and Infs, which you'll probably appreciate. I think the only major change it would impose on you is replacing 'mix' and 'mix3d' with 'list'. Neil T _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New plot library [Was: (to Jay) Re: What I'm working on]
Redirecting this from Kevin back to the group, because I think at least plot2d is good enough for anyone to play with now. I've put all of it here: https://github.com/ntoronto/plt-stuff/tree/master/plot The main module files are meant to be plot2d.rkt and plot3d.rkt. Both contain tests right now. In particular, Kevin, the tests in plot2d.rkt show how to generate simple 2D plots and save them to files. (In fact, I've just added plot2d-file, which writes a plot to a file or output stream using any bitmap or vector format that Racket supports. I haven't tested it much, but it appears to work.) This code is very young and fairly untested; standard warnings apply. (May pillage your families and murder your crops, etc.) The interface WILL change, so don't count on it. Neil T On 08/03/2011 09:41 AM, Kevin Tew wrote: Have a github link yet? I have a simple line graph I need to generate and would like to give your 2d plot a try. Kevin On 08/02/2011 11:33 AM, Neil Toronto wrote: Re-routing this email exchange to [racket-dev] for comments. Long story short: Jay roped me into replacing the current `plot' module by wrapping a plot library I was working on for my own use. (FWIW, I'm happy to finally contribute something!) Intended features: 1. Doesn't depend on an FFI to libplplot 2. Can automatically place plot area on functions and points 3. Uses parameters for keyword argument default values 4. Uses only dc% primitives / Is very pretty 5. Is more flexible (when using the new plot2d and plot3d modules) Linux screenshots: http://students.cs.byu.edu/~ntoronto/plot2d.png http://students.cs.byu.edu/~ntoronto/plot3d.png The first shows off the almost-finished plot2d. It's as fast as the original `plot', and `shade' is twice as fast. Props to Matthew and Linux's foreign drawing libs for making it look so nice. The second shows off 3d-plot-area%, which wraps a dc% with 3d drawing primitives. The new plot3d will be 1.5x-2x slower, but the new features (e.g. compositing 3d plots, contours) should be worth it. I'll push code to github soon, and ask for volunteers to verify that it looks good on Mac and Windows. Specific questions -- Matthew: It should look good on Mac and Windows if their drawing libs do subpixel-accurate, high-quality antialiasing. Do they? Doug and other heavy `plot' users: What can I add to plot2d and plot3d to make your life easier? Noel: Do you happen to have a kernel density estimator implementation that uses FFT or is otherwise more efficient than O(n^2)? Currently, (plot2d (density samples)) works, but is slow on large samples. Anyone: Are there any original `plot' features that should *not* be emulated in the new `plot' wrapper module? Anyone: Is it easy/possible to manipulate snip%s with, say, a click-and-drag? How about placing edit boxes on them? If it's not hard, I would like to make the 3d plots manipulatable after rendering. Neil T On 07/30/2011 02:01 PM, Jay McCarthy wrote: Yup, so that old programs will keep working. Will you support the line fitting? Jay On Sat, Jul 30, 2011 at 1:56 PM, Neil Torontoneil.toro...@gmail.com wrote: Sure can! Does compatible source library mean a bunch of wrappers for the functions plot currently exports? Neil On 07/30/2011 05:49 AM, Jay McCarthy wrote: Awesome. We've been wanting to throw it out for a long time. Can you make a compatible source library too... so we can replace it in the core? Jay On Fri, Jul 29, 2011 at 10:35 PM, Neil Torontoneil.toro...@gmail.com wrote: I've attached a screenshot of what I'm working on. It's a replacement for Racket's plot module. The plot module has these drawbacks: 1. It's not smart enough to automatically size plots to the things - renderers - you're plotting. A renderer is only a function that accepts an image snip, so the plotter can't compute a rectangle that contains it. 2. It depends on an external library, plplot. 3. It draws ugly curves because plplot can't draw lines with subpixel-accurate endpoints. Also, plplot messes up antialiasing when the curves are made of too many lines. Whatever Racket uses doesn't have this problem, at least on Linux. 4. It doesn't use parameters for things for which parameters make sense, like the size of the plots. I could probably alter the plot module for any one or two of these and submit patches. For all four, writing a replacement makes more sense. FWIW, this is related to my research. I've been using R to generate plots, but it's getting annoying to serialize samples in Racket and then unserialize them in R. Also, Bayesians make a LOT of plots. It's *really* nice to display them using image snips. That's very, very cool. This project feels vacation-y and relaxing. I figure it's because it doesn't require any more math than linear algebra. :D Neil _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New plot library [Was: (to Jay) Re: What I'm working on]
This is great -- a better plotting library will make some of work a lot easier. Noel: Do you happen to have a kernel density estimator implementation that uses FFT or is otherwise more efficient than O(n^2)? Currently, (plot2d (density samples)) works, but is slow on large samples. Nope, sorry. --- Regarding Guilllaume's point, I have an unfinished library along these lines: https://github.com/noelwelsh/bonfire The basic idea is to compose images out of circles, lines, etc. much like the new drawing library in HTDP/2e. However I'm allowing constraints between elements -- e.g. this line must be 110% of the width of this graphical element. I super don't have time to work on this so if someone wants to implement this idea that would be great. Regarding Eli's rebuttal -- *of course* it's badly designed -- it's R!!! The idea, however, is valid. N. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New plot library [Was: (to Jay) Re: What I'm working on]
Will it be backward compatible with plot? -- Matthias On Aug 2, 2011, at 1:33 PM, Neil Toronto wrote: Re-routing this email exchange to [racket-dev] for comments. Long story short: Jay roped me into replacing the current `plot' module by wrapping a plot library I was working on for my own use. (FWIW, I'm happy to finally contribute something!) Intended features: 1. Doesn't depend on an FFI to libplplot 2. Can automatically place plot area on functions and points 3. Uses parameters for keyword argument default values 4. Uses only dc% primitives / Is very pretty 5. Is more flexible (when using the new plot2d and plot3d modules) Linux screenshots: http://students.cs.byu.edu/~ntoronto/plot2d.png http://students.cs.byu.edu/~ntoronto/plot3d.png The first shows off the almost-finished plot2d. It's as fast as the original `plot', and `shade' is twice as fast. Props to Matthew and Linux's foreign drawing libs for making it look so nice. The second shows off 3d-plot-area%, which wraps a dc% with 3d drawing primitives. The new plot3d will be 1.5x-2x slower, but the new features (e.g. compositing 3d plots, contours) should be worth it. I'll push code to github soon, and ask for volunteers to verify that it looks good on Mac and Windows. Specific questions -- Matthew: It should look good on Mac and Windows if their drawing libs do subpixel-accurate, high-quality antialiasing. Do they? Doug and other heavy `plot' users: What can I add to plot2d and plot3d to make your life easier? Noel: Do you happen to have a kernel density estimator implementation that uses FFT or is otherwise more efficient than O(n^2)? Currently, (plot2d (density samples)) works, but is slow on large samples. Anyone: Are there any original `plot' features that should *not* be emulated in the new `plot' wrapper module? Anyone: Is it easy/possible to manipulate snip%s with, say, a click-and-drag? How about placing edit boxes on them? If it's not hard, I would like to make the 3d plots manipulatable after rendering. Neil T On 07/30/2011 02:01 PM, Jay McCarthy wrote: Yup, so that old programs will keep working. Will you support the line fitting? Jay On Sat, Jul 30, 2011 at 1:56 PM, Neil Torontoneil.toro...@gmail.com wrote: Sure can! Does compatible source library mean a bunch of wrappers for the functions plot currently exports? Neil On 07/30/2011 05:49 AM, Jay McCarthy wrote: Awesome. We've been wanting to throw it out for a long time. Can you make a compatible source library too... so we can replace it in the core? Jay On Fri, Jul 29, 2011 at 10:35 PM, Neil Torontoneil.toro...@gmail.com wrote: I've attached a screenshot of what I'm working on. It's a replacement for Racket's plot module. The plot module has these drawbacks: 1. It's not smart enough to automatically size plots to the things - renderers - you're plotting. A renderer is only a function that accepts an image snip, so the plotter can't compute a rectangle that contains it. 2. It depends on an external library, plplot. 3. It draws ugly curves because plplot can't draw lines with subpixel-accurate endpoints. Also, plplot messes up antialiasing when the curves are made of too many lines. Whatever Racket uses doesn't have this problem, at least on Linux. 4. It doesn't use parameters for things for which parameters make sense, like the size of the plots. I could probably alter the plot module for any one or two of these and submit patches. For all four, writing a replacement makes more sense. FWIW, this is related to my research. I've been using R to generate plots, but it's getting annoying to serialize samples in Racket and then unserialize them in R. Also, Bayesians make a LOT of plots. It's *really* nice to display them using image snips. That's very, very cool. This project feels vacation-y and relaxing. I figure it's because it doesn't require any more math than linear algebra. :D Neil _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New plot library [Was: (to Jay) Re: What I'm working on]
I'll write a backward-compatible wrapper for plot, so yes. Mostly. I'll try to emulate it as closely as possible, but any code that depends on the specific pixels or snip% class `plot' generates will probably break. I want plot2d and plot3d to be a little saner than plot. For example, currently, plot2d automatically shows the entirety of a parabolic curve; in contrast, plot only shows it in the area [-5,5] x [-5,5] unless you override it. Neil T On 08/02/2011 11:38 AM, Matthias Felleisen wrote: Will it be backward compatible with plot? -- Matthias On Aug 2, 2011, at 1:33 PM, Neil Toronto wrote: Re-routing this email exchange to [racket-dev] for comments. Long story short: Jay roped me into replacing the current `plot' module by wrapping a plot library I was working on for my own use. (FWIW, I'm happy to finally contribute something!) Intended features: 1. Doesn't depend on an FFI to libplplot 2. Can automatically place plot area on functions and points 3. Uses parameters for keyword argument default values 4. Uses only dc% primitives / Is very pretty 5. Is more flexible (when using the new plot2d and plot3d modules) Linux screenshots: http://students.cs.byu.edu/~ntoronto/plot2d.png http://students.cs.byu.edu/~ntoronto/plot3d.png The first shows off the almost-finished plot2d. It's as fast as the original `plot', and `shade' is twice as fast. Props to Matthew and Linux's foreign drawing libs for making it look so nice. The second shows off 3d-plot-area%, which wraps a dc% with 3d drawing primitives. The new plot3d will be 1.5x-2x slower, but the new features (e.g. compositing 3d plots, contours) should be worth it. I'll push code to github soon, and ask for volunteers to verify that it looks good on Mac and Windows. Specific questions -- Matthew: It should look good on Mac and Windows if their drawing libs do subpixel-accurate, high-quality antialiasing. Do they? Doug and other heavy `plot' users: What can I add to plot2d and plot3d to make your life easier? Noel: Do you happen to have a kernel density estimator implementation that uses FFT or is otherwise more efficient than O(n^2)? Currently, (plot2d (density samples)) works, but is slow on large samples. Anyone: Are there any original `plot' features that should *not* be emulated in the new `plot' wrapper module? Anyone: Is it easy/possible to manipulate snip%s with, say, a click-and-drag? How about placing edit boxes on them? If it's not hard, I would like to make the 3d plots manipulatable after rendering. Neil T On 07/30/2011 02:01 PM, Jay McCarthy wrote: Yup, so that old programs will keep working. Will you support the line fitting? Jay On Sat, Jul 30, 2011 at 1:56 PM, Neil Torontoneil.toro...@gmail.com wrote: Sure can! Does compatible source library mean a bunch of wrappers for the functions plot currently exports? Neil On 07/30/2011 05:49 AM, Jay McCarthy wrote: Awesome. We've been wanting to throw it out for a long time. Can you make a compatible source library too... so we can replace it in the core? Jay On Fri, Jul 29, 2011 at 10:35 PM, Neil Torontoneil.toro...@gmail.com wrote: I've attached a screenshot of what I'm working on. It's a replacement for Racket's plot module. The plot module has these drawbacks: 1. It's not smart enough to automatically size plots to the things - renderers - you're plotting. A renderer is only a function that accepts an image snip, so the plotter can't compute a rectangle that contains it. 2. It depends on an external library, plplot. 3. It draws ugly curves because plplot can't draw lines with subpixel-accurate endpoints. Also, plplot messes up antialiasing when the curves are made of too many lines. Whatever Racket uses doesn't have this problem, at least on Linux. 4. It doesn't use parameters for things for which parameters make sense, like the size of the plots. I could probably alter the plot module for any one or two of these and submit patches. For all four, writing a replacement makes more sense. FWIW, this is related to my research. I've been using R to generate plots, but it's getting annoying to serialize samples in Racket and then unserialize them in R. Also, Bayesians make a LOT of plots. It's *really* nice to display them using image snips. That's very, very cool. This project feels vacation-y and relaxing. I figure it's because it doesn't require any more math than linear algebra. :D Neil _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New plot library [Was: (to Jay) Re: What I'm working on]
An hour ago, Neil Toronto wrote: I'll write a backward-compatible wrapper for plot, so yes. Mostly. I'll try to emulate it as closely as possible, but any code that depends on the specific pixels or snip% class `plot' generates will probably break. I want plot2d and plot3d to be a little saner than plot. For example, currently, plot2d automatically shows the entirety of a parabolic curve; in contrast, plot only shows it in the area [-5,5] x [-5,5] unless you override it. This replacement would be great -- it's pretty bad now that it goes out to a(n outdated) C library with inferior graphic capabilities, draws the graph into a temporary file which is then loaded back in Racket. If you have something that is close enough it should be fine. Doug Wiliams is probably the heaviest user of plot, so making his code run is probably a good estimate for close enough. There are also some tests in tests/plot that you can look into (they're being compared directly to the png files in there, so they'd obviously break, but should look similar). Two more notes: * IIRC, the only code that was considered as worth keeping is the curve fitting (and some other things around error estimations?) -- it sounds like you have that part done better anyway. * When you look at the current interface, bear in mind that it started with classes, but that was mostly an abuse to get something like keyword arguments. Having just the plain keyworded interface should be fine now too, IMO. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New plot library [Was: (to Jay) Re: What I'm working on]
At Tue, 2 Aug 2011 16:20:43 -0400, Eli Barzilay wrote: This replacement would be great -- it's pretty bad now that it goes out to a(n outdated) C library with inferior graphic capabilities, draws the graph into a temporary file which is then loaded back in Racket. No, the current plot draws via dc% to a bitmap. I threw out the old back end and installed callbacks that use `racket/draw' as of v5.1. The pixels changed a lot with that switch, of course, so I don't think anyone cares about changes at that level. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New plot library [Was: (to Jay) Re: What I'm working on]
About a minute ago, Matthew Flatt wrote: At Tue, 2 Aug 2011 16:20:43 -0400, Eli Barzilay wrote: This replacement would be great -- it's pretty bad now that it goes out to a(n outdated) C library with inferior graphic capabilities, draws the graph into a temporary file which is then loaded back in Racket. No, the current plot draws via dc% to a bitmap. I threw out the old back end and installed callbacks that use `racket/draw' as of v5.1. Ah, so that probably makes things even easier for Neil. The pixels changed a lot with that switch, of course, so I don't think anyone cares about changes at that level. Yeah. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New plot library [Was: (to Jay) Re: What I'm working on]
On 08/02/2011 01:28 PM, Eli Barzilay wrote: About a minute ago, Matthew Flatt wrote: At Tue, 2 Aug 2011 16:20:43 -0400, Eli Barzilay wrote: This replacement would be great -- it's pretty bad now that it goes out to a(n outdated) C library with inferior graphic capabilities, draws the graph into a temporary file which is then loaded back in Racket. No, the current plot draws via dc% to a bitmap. I threw out the old back end and installed callbacks that use `racket/draw' as of v5.1. Ah, so that probably makes things even easier for Neil. I wish it did! But the current stuff still uses libplplot via FFI. Matthew's overhaul makes libplplot render to a dc% instead of saving to a file. The rendering pipeline looks like plot - FFI interface - libplplot frontend - dc backend - dc Also, computing *what* to send to the dc is written in C. That's why the plots are still 1998-ugly, and why it's easier to code plot - dc from scratch. The pixels changed a lot with that switch, of course, so I don't think anyone cares about changes at that level. That's good to know. Thanks! Neil T _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New plot library [Was: (to Jay) Re: What I'm working on]
5 hours ago, Neil Toronto wrote: On 08/02/2011 01:28 PM, Eli Barzilay wrote: Ah, so that probably makes things even easier for Neil. I wish it did! But the current stuff still uses libplplot via FFI. Matthew's overhaul makes libplplot render to a dc% instead of saving to a file. The rendering pipeline looks like plot - FFI interface - libplplot frontend - dc backend - dc Also, computing *what* to send to the dc is written in C. Well, easier in the sense that you're left with implementing just the what part. That's why the plots are still 1998-ugly, and why it's easier to code plot - dc from scratch. [I smell themes...] -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New plot library [Was: (to Jay) Re: What I'm working on]
Doug and other heavy `plot' users: What can I add to plot2d and plot3d to make your life easier? Do you know about ggplot? It's a plotting library based on a grammar of graphic elements, rather than a bucket of pre-set charts, which is what most plotting libraries offer. The design principles behind ggplot are very Scheme-like: a small base of powerful orthogonal features with as few restriction on composition as possible. http://had.co.nz/ggplot2/resources/2007-past-present-future.pdf It would be great to have something like it in ggplot. I do a lot of charting, but I hardly ever use the plot module since the charts I do are more 'information design'-style charts that can't be made with pre-set charts. If DrRacket had a plotting library like ggplot, I would be able to stop building everything by hand from pict's. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New plot library [Was: (to Jay) Re: What I'm working on]
15 minutes ago, Guillaume Marceau wrote: [...] http://had.co.nz/ggplot2/resources/2007-past-present-future.pdf [...] colour - paste( ifelse(, cond_string, , ', brush, ', ', background, '), sep= ) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
