Ruby Matplotlib

[Eduardo Silva Araújo]

Hello!

This is a sort of continuation of this thread. I'm a Physics student, willing to join you on this GSoC. I miss a

good plotting utility in Ruby, and I want to take part on the task of 'Ruby Matplotlib'.

From the discussed approaches, I like the ruby/python bridge and the matplotlib rewrite to be language-independent.

 - For the bridge, we could use something like rubypython. This way, we don't need to directly handle the cross platform GUI

parts.

 - Making matplotlib itself language independent is beneficial to other languages as well, and is a cleaner solution for this

task. The problem with this is that it's highly dependent on the python ecosystem, and there might be reasons for

the matplotlib maintainers to refuse this option, like optimization for python usage. Forking matplotlib might work

in this case.

 - Another option would be going the path of matplotlib-haskell, which generates and executes the python code

independently. That's a strange approach, but it can work as well.

I prefer making matplotlib a library, as it seems more reasonable to me, and it extends its benefits to other languages.

Any advice/comment/suggestion is welcome!

[Kenta Murata]

Hi Eduardo,

I made matplotlib.rb. It uses pycall.rb for bridging between Ruby and Python.

I think pycall.rb and matplotlib.rb is not completed, but it's ready to use in production.

For example, optcarrot uses matplotlib.rb to visualize its benchmarking results:

https://github.com/mame/optcarrot/blob/master/tools/plot.rb

I recommend you to aim to make visualization systems that are independent from Python.

I know writing wrapper library like matplotlib.rb on bridging system like pycall.rb is not challenging work.

Now Ruby doesn't have production-ready visualization system, IMO.

You can aim to establish such system with your mentors, or you can improve existing libraries such as daru-views.

Regards,
Kenta Murata

--
You received this message because you are subscribed to the Google Groups "SciRuby Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sciruby-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Prasun Anand]

Hi,

You can read this thread
https://groups.google.com/forum/#!topic/sciruby-dev/xEevW-7VUjw.

Adding to it, can you come up with a C API that creates a line chart
using AGG(http://www.antigrain.com/).
AGG is a renderer for Matplotlib.

You can checkout https://github.com/prasunanand/ninjaplot
Here, I tried to render a line using AGG. You may follow this style to
come up with a line graph. AGG tutotial
can help you with it.

John, What do you think ?

Regards,
Prasun

[John Woods]

I don't think option 3 will work. We've tried bridges like this before with other plotting libraries and it ends up being really, really hard to track down errors. You lose a lot of fine control, too.

I'm also concerned at the bottlenecks involved in using rubypython.

We previously had a student who talked to the matplotlib devs about rewriting and they didn't seem particularly keen on it. I think it would have to be more of a complete rewrite than a fork, honestly.

I realize that there's a lot of work involved in this project. This is why SciRuby is prepared to pay a student for ongoing work, after GSOC, for a working Ruby matplotlib.

I think there might be two projects here:

• Matplotlib plotting syntax expressed in Ruby.
  
• Backends: PDF/PS, PNG (agg), GUI, etc.

Can we focus on making it work with just one or two backends, preferably the GUI among those, and leave room for extension to other backends later? It might also be possible to have Python-matplotlib as one of the backends via rubypthon.

Or perhaps it'd be simpler to use ImageMagick as our primary rendering library? That would probably support a lot of different types, wouldn't it?

AGG seems to be useful only for PNGs and rasters, no?

John

--

[Prasun Anand]

I think using tkinter for GUI can be a good start.

The student can decide what would be a better option for rendering,
AGG or ImageMagick.

Regards,
Prasun

[Eduardo Silva Araújo]

> I think there might be two projects here:

• Matplotlib plotting syntax expressed in Ruby.
  
• Backends: PDF/PS, PNG (agg), GUI, etc.

I like that division. I think sticking with matplotlib usual syntax for now is better; as we'll be able to add backends, maybe we can offer other syntaxes for plotting later,

like a DSL or something more ggplot-esque.

For GUI, I think cairo would be a nice choice, as it support vector graphics, is cross-platform, and ruby bindings exist and seem to be actively maintained.

> I think using tkinter for GUI can be a good start.

Isn't tkinter a python specific library as well?

> AGG seems to be useful only for PNGs and rasters, no?

Yes, it seems to be focused on high quality raster graphics. I'll read more about it; AGG looks like a nice library.

ImageMagick seems to be a viable option as well.

[John Woods]

Well, high-quality raster graphics are definitely preferred over low-quality, so whatever tool is best for the job. :)

[Eduardo Silva Araújo]

I like the architecture described here; I'd propose to implement this architecture, the matplotlib syntax in ruby, and an agg backend - all with a nice battery of tests.

As matplotlib uses agg as backend, we could check its source for reference.

How many students are you planning to have working on this?

Eduardo

[Maurice Diamantini]

Bonjour à tous,

Plotting in ruby is a project that I read about for several year now (for GSOC).

Same as John, I like the two level approach.
I'd like to mention the Julia Plots package which is a two level plotting system.
- one uniform user interface which is Julia friendly,
- numerous backends renderer. One off them PyPlot, but the preferred one is GR.


Matplotlib
----------
Julia is already able to call Matplotlib ou even python directly...
But using a python feature require about 1 GBytes of dependencies added to the Julia installation!
This is is only acceptable for Julia which a new language (1.0 expected this year). But Ruby is more than 20 year old now.


GR Framework
------------
GR is a Graphic Framework based on Graphical Kernel System (GKS) and OpenGL. There is a Python and a Julia binding.

http://gr-framework.org/about.html

The presentation says:
...
Starting with release 0.6 GR can be used as a backend for Matplotlib
and significantly improve the performance of existing Matplotlib
or PyPlot applications written in Python or Julia.
...

So instead of writing a shell on a shell on GR (Are we going to create as much Ruby plotting systems than they are "Killer JavaScript Frameworks"?), why not directly white a GR binding for Ruby (and maintain it!).

You can see some Julia+Plots examples at:
http://docs.juliaplots.org/latest/examples/gr/


Whatever it is, I'm personally not going to write Ruby script which depend on Python.

Best regard,
-- Maurice

[John Woods]

Good find! This is a really wonderful and concise description of Matplotlib's architecture, and, I think, an excellent basic design for a Ruby matplotlib clone. :)

I think we could accommodate two students simultaneously working on this project. One way to divide it up might be:

1. Backend (image display/rendering, UI events, etc.) and the backend's interface, with a focus on AGG
2. Polyline pipeline, artists, syntax, etc.

The unit test framework is the orphan here, and it's pretty essential — but I don't see it as being a large amount of work. I'd say we might bend our normal applicant patch requirement and allow someone to write the basic unit testing functionality as their "patch" to an "existing" SciRuby project. (So, basically, reads in two PNG files and computes an RMS, attempts to determine whether they're "close enough.")

Again, I want to emphasize that we don't expect either of these projects to be completable during a single summer. We might measure completion-for-the-purposes-of-GSOC as something like:

1. It successfully demonstrates some simple basic plots with one or two backends.
2. It includes unit tests that can measure whether the whole pipeline is working, perhaps comparing to matplotlib output as a bootstrap.

How does that sound?

John

[Eduardo Silva Araújo]

That sounds good! About the tests, I think TDD might be a good approach. Having good tests and a nice test coverage will help any future development, as well.

The GR Framework seems nice! I'll read more about it; maybe it can be used as a backend later, as well.

I'd like to ask some questions about the GSoC schedule. May I pm you, John?

Eduardo

[Sameer Deshmukh]

Hi Eduardo,

If you want to work on this project for GSOC I suggest you come up with some test code ASAP, since the application deadline is coming close and we will NOT be able to accept your application if you do not submit within the deadline.

Therefore, I think the approach that you have come up with so far is sufficient for putting in a proposal draft, which you can keep editing later. Have a look at the application template and submit your initial plans to us ASAP.

[John Woods]

TDD is pretty much essential for the kind of libraries we write.

We kind of discourage private messaging for GSOC, generally, and I'm traveling so much you may not be able to get me in time. I'll try to be on our IRC channel today (during the workday in Texas) if you want to chat real-time.

John

[Pranav Garg]

Greetings,

I hope everyone here is doing well!

I am a Pre-Final Year Undergrad student in Electronics Engineering.

I am interested in contributing towards the creation of a Ruby Matplotlib.

Upon a lot of thought over this project, I believe that imitating the Matplolib architecture and creating a language independent library rather than  creating bridge between the C++ Matplotib code or Python would be the right way to go, for the very reasons mentioned in the details of this Project Idea. I am emphasizing on a language-independent Plotting library as it will be useful to a plethora of languages and can thus lead to the cross-community active development of the library rather than just Ruby-devs & enthusiasts working on the same and also provide a permanent solution to the plotting needs. I would also like to continue to contribute to the library after completion of Summer of code uptill the release of its first version and beyond,

As per Prasun's recommendation, I looked into AGG and I am trying to implement a toy code for creating scattergraphs and line graphs for given coordinates (https://github.com/pgtgrly/AGG_Playground). Currently, I am trying to figure out the template function calls for the Markers renderers, once that will be done I will be done with the first iteration of the scatterplot. It is proving to be a bit of a challenge because of the lack of documentation and online examples for the very same.
 I have discovered a newfound admiration for MatPlotlib as well as intrigued by the challenges that I can think of in the implementation.
 

I believe that this will be a great learning experience for me and will help me understand how to develop production-ready code in C++ as well as provide me a lesson in planning and implementation of software architecture. Previously, I have implemented a few end to end Deep Learning Pipelines in PyTorch. Although that is pygmy in comparison to this goliath task of creating a universal Library, it did give me an insight for planning out a modular pipeline.

Prasun, would it be possible for you to help me out with it since you have worked with AGG in NinjaPlot?

 
Regards

Pranav Garg

[John Woods]

Welcome aboard!

And in case any students are worried, don't be. There's plenty of work to be done on the matplotlib project. If we get six competitive applications, we'll do our best to place all six. :)

Please do remember that we require you to have submitted a patch to a SciRuby project to be eligible for GSOC.

I would consider waiving the code submission requirement if and only if all of the conditions are met:

1. You submit sufficiently detailed pre-agreed-upon concept demonstration code.
2. The code includes unit tests.
3. The code is related to this project.

(I mention that just to provide another option, but it's still probably easier if you submit a patch to an existing project.)

John

[Prasun Anand]

Hi Pranav,

Please work on rendering the markers. All you need is to stitch the
parts together before rendering.

I am reading the docs myself.

Also, start working on your application.

Best,
Prasun

[Prasun Anand]

Dear Students,

While writing the application please also try to address how you will
create the library.

1. Backend: Do some research about coming up with a static library
that provides the C/C++ APIs.
2. Frontend: Creating a dynamic/shared library that acts as a bridge
between the C/C++ APIs
and Ruby Frontend.

Regards,
Prasun

[John Woods]

I'd like to amend that a bit:

1. Backend: The portion of the library that provides the actual rendering (to a GUI, to a bitmap, to a scalable graphic, etc.).
2. Frontend: The portion of the library that provides the matplotlib-like API and communicates with the backend.

You should probably focus on one or the other, but I suggest studying how matplotlib does it. It's probable that you'll need to work in a combination of Ruby, C, and C++.

John

[Sameer Deshmukh]

Also, I am strongly of the opinion that the C++ code should be kept independent of language so that we can leverage the expertise of other language communities, not just our own.

[John Woods]

Could you clarify that a bit?

--