This is very intriguing, thanks! The following post is contrarian, but it is not meant to reduce the coolness of the work - just pointing out my use case:
My workflow is to have data processed by either Python or C++ code and then do the exploratory analysis completely in Python - it’s the use case Python was born for. I can’t imagine exploratory analysis without an interactive environment like IPython and a dynamic language like Python.
When I sort of finalize plots that I want others to make on a regular basis, if there is an expensive post-processing step, I consider moving that to C++, but in all cases the actual plots themselves come from post-processed data structures, with Python plotting code - at most - slicing views of the processed data.
So, to conclude, tl;dr, I’m not sure I would use this library because it sits outside the sweet spots of both C++ and Python.
I know what you mean, plotting huge amounts of data in C++ has never been easy or fun.
This project is a long way from making python/matplotlib/numpy developers turn around and adopt this library along with the dark side of C++, but I am betting this technology in the future will help to decrease the gap between C++ and Python for exploratory analysis.
Thanks for your input, kghose.
Plotting libraries are beasts—the APIs necessarily juggle between getting structured (or parameterised) data plotted and full-out drawing. Where users purport to need the first, but inevitably ask for the second. And that’s not even to mention the backend, which is where most of the weight comes from: PDF, PNG, JPG, etc. So a plotting library is usually a shim atop a drawing library, which is a shim atop various output format libraries (libpng, etc.). Each inheriting the common denominator of the layer below.
In the non-chroot world, I’ve used a lot of gnuplot and grap and plotutils; but when buliding dynamic graphs into a chrooted C system (not sure about C++), I ended up rolling my own, kplot, after being overwhelmed by plplot. I’d heard of Qt Charts but discounted it due (1) to being C++ and (2) the requirement of Qt, which was too much for my own small needs.
At the end of the day, I’m convinced that the most important thing about a plotting library is which default colours are used. Oh—and fonts. (On the topic of beasts…)
Absolutely! Adding Qt to a small project is overkill just to have a few charts.
On the other hand, if you are doing prototypes for the desktop and need simple and easy chart capabilities on your program, or if you are developing GUIs with Qt already and need some plotting done really quick, then madplotlib can really be a game changer.
kplot seems a lot of fun, I will certainly take a closer look, thanks!
This is very intriguing, thanks! The following post is contrarian, but it is not meant to reduce the coolness of the work - just pointing out my use case:
My workflow is to have data processed by either Python or C++ code and then do the exploratory analysis completely in Python - it’s the use case Python was born for. I can’t imagine exploratory analysis without an interactive environment like IPython and a dynamic language like Python.
When I sort of finalize plots that I want others to make on a regular basis, if there is an expensive post-processing step, I consider moving that to C++, but in all cases the actual plots themselves come from post-processed data structures, with Python plotting code - at most - slicing views of the processed data.
So, to conclude, tl;dr, I’m not sure I would use this library because it sits outside the sweet spots of both C++ and Python.
I know what you mean, plotting huge amounts of data in C++ has never been easy or fun. This project is a long way from making python/matplotlib/numpy developers turn around and adopt this library along with the dark side of C++, but I am betting this technology in the future will help to decrease the gap between C++ and Python for exploratory analysis. Thanks for your input, kghose.
Plotting libraries are beasts—the APIs necessarily juggle between getting structured (or parameterised) data plotted and full-out drawing. Where users purport to need the first, but inevitably ask for the second. And that’s not even to mention the backend, which is where most of the weight comes from: PDF, PNG, JPG, etc. So a plotting library is usually a shim atop a drawing library, which is a shim atop various output format libraries (libpng, etc.). Each inheriting the common denominator of the layer below.
In the non-chroot world, I’ve used a lot of gnuplot and grap and plotutils; but when buliding dynamic graphs into a chrooted C system (not sure about C++), I ended up rolling my own, kplot, after being overwhelmed by plplot. I’d heard of Qt Charts but discounted it due (1) to being C++ and (2) the requirement of Qt, which was too much for my own small needs.
At the end of the day, I’m convinced that the most important thing about a plotting library is which default colours are used. Oh—and fonts. (On the topic of beasts…)
Absolutely! Adding Qt to a small project is overkill just to have a few charts. On the other hand, if you are doing prototypes for the desktop and need simple and easy chart capabilities on your program, or if you are developing GUIs with Qt already and need some plotting done really quick, then madplotlib can really be a game changer. kplot seems a lot of fun, I will certainly take a closer look, thanks!