The reference does seem to fit here, as a general plotting language seems to be awfully complicated. By the way, I totally forgot to mention, that I want to turn GLPlot more into a meta package, offering different plotting interfaces, since I'm generalizing more and more of the render code and a lot of people prefer different interfaces to the same functionality. So it might become a lightweight package, which actually doesn't contain render code and only defines interfaces. If someone has any API that he wants to implement, GLPlot might become the go to package. If this happens, I should rename it though ;)
Am Donnerstag, 22. Januar 2015 16:42:37 UTC+1 schrieb David van Leeuwen: > > Hello, > > I've just read up on most recent conversations mentioning plotting, after > I went through a similar install-and-try-out cycle for the various plotting > packages. > > I am busy with a package named ROC <https://github.com/davidavdav/ROC> > (Receiver > Operating Characteristic). It is mostly about decision cost functions and > efficiently computing ROC statistics, but there is also some support for > making various plots related to the ROC. > > I do not want to decide for a potential user of this package which > plotting package she should use. So it would be nice if there would be an > abstract plotting API (I suppose this does not exist yet). > > Supposing that it is possible to make an API that includes some common > plotting primitives, and that makes a runtime selection based on > `isdefined(plottingpackagename)`, how would you > - overload a function, typically `plot()`, when at module-include time it > is not yet known which plotting package the user wants > - specify the dependence of this package to any one of the available > plotting packages. > > Thoughts? > > Thanks, > > ---david >
