RubyPlot - Creating a Plotting Library for Ruby

by Pranav Garg

The video titled 'RubyPlot - Creating a Plotting Library for Ruby' presented by Pranav Garg at RubyConf 2018 focuses on the development of RubyPlot, a plotting library designed for Ruby programming. Pranav introduces the library's architecture, drawing inspiration from Python's Matplotlib while incorporating Ruby's unique features. He highlights several key aspects of an effective plotting library:

User Adaptability: A good library should cater to different users, from high-level needs to advanced customization.
Modularity: The design must allow for interchangeable components, enabling flexibility in backend choices.
Dynamic Nature: Unlike static libraries, RubyPlot supports interaction capabilities to modify visualizations based on user input.

Drawing parallels with Matplotlib, Pranav shares the story of its creation by John Hunter, emphasizing its evolution as an open-source project. He outlines the three-layer architecture of RubyPlot:
- Backend Layer: Functions as the core rendering engine.
- Artist Layer: Handles graphical representations and transformations.
- Frontend API: Serves as the user interface to create plots easily.

To illustrate these concepts, he uses the analogy of a cake or the movie 'Ratatouille' to explain the layered structure. Pranav also recounts his journey of building RubyPlot, including challenges like generating dynamic plots and managing subplots effectively.

In advocating for Ruby's use in scientific computing, he emphasizes its expressive syntax and metaprogramming features, arguing for the potential of developing language-independent scientific software. He concludes by encouraging engagement from the Ruby community in collaborative open-source initiatives to develop robust scientific tools. Special thanks are extended to mentors and contributors, and he invites discussions post-presentation.

00:00:15.740 I'm really glad that you're able to join me today. Before we begin the talk, might I request you to please put your phones on silent so that others can enjoy it as well?

00:00:27.060 Now, since it's the first session after the keynote, let's talk Ruby. What are the good qualities of Ruby? Well, you have the purity, you've got the polish, and the refractive index, of course.

00:00:42.450 Now, if you chuckled at that, then you’ll love the joke I’m going to make. But seriously, the topic for the day is RubyPlot: creating a plotting library in Ruby.

00:00:54.510 We won't be coding a lot along, so if you'd like to, you can turn off your laptops. But who is this talk for? Let's take a quick survey. How many amateur Rubyists are in the house? Good. How many Ruby veterans? Awesome!

00:01:13.260 Have you guys heard of this language named Python and its plotting library Matplotlib? It's a small sorting library, quite famous. Any Matplotlib users in the audience? A few, I see. But are these not total users, only using Matplotlib? Cool!

00:01:27.840 Now, how many of you like really bad jokes? Cool! So this presentation is virtually for everyone. Now, you must be thinking, 'Who the hell is this loud guy on the podium?' Well, that was a trick question, and the correct answer is none of the above, though my mom says I’m a genius.

00:01:51.000 But let me introduce myself. Hi, I’m Pranav Garg, a senior undergraduate student from BITS Pilani, India. I am a mature Rubyist and aspiring researcher in the field of theoretical neuroscience and its conjunction with reinforcement learning.

00:02:19.110 Finally, over the summer, I started working on a plotting library from scratch at SCI Ruby as part of Google Summer of Code. And there's a word of warning over here, so please don't judge me.

00:02:39.540 Now, let's go through a quick plan for the talk. Firstly, we have the introduction, which is still ongoing. Then we'll discuss the general plotting library architecture, which is going to be modular, allowing you different degrees of control.

00:03:11.610 We'll be talking about my journey in the creation of RubyPlot, followed by some general thoughts such as why you should use Ruby for scientific software, and a crazy idea called language-independent scientific software.

00:03:30.030 Finally, at the risk of sounding like a snake oil salesman, I’ve got a brilliant opportunity just for you. We will have a Q&A session, but it's going to be informal and after the talk, so you can catch me around or tweet at me anytime.

00:03:44.549 Now, let’s begin with the plotting library architecture. Since I want to drink some water, here are the sub-points that we will be going through. I will read them out, and you can see them for 10 seconds. You know what? I’m not patient, so let’s make it 3 seconds.

00:04:06.870 So, what are the qualities of a good plotting library? Firstly, it should adapt to the needs of its user. You could be a high-level user who simply wants a good bar plot: you just want to provide an array of values and have a bar plot created without defining every single pixel.

00:04:40.620 On the other hand, you might be a genius who wants to define a new plot altogether. These represent the different layers of control we wish to have in the library.

00:05:06.120 This brings us to the second point: it should be modular. By modular, I don’t just mean different degrees of control but that there should be different back ends that are easily swappable.

00:05:41.580 Finally, it should be dynamic. What do we mean by static versus dynamic plotting libraries? We will get into that, but know that whenever I talk about a plotting library, I will be referring to a scientific plotting library.

00:06:06.630 What is the difference? Well, a scientific plotting library is meant to handle a lot of data and has to be easily adaptable. When we talk about plotting libraries, Matplotlib is one of the best examples.

00:06:34.410 It was the brainchild of the late Dr. John D. Hunter and, like any other open-source software, it has undergone many iterations. In fact, while I was looking through its source code, I found a comment indicating old code paths that had become deprecated, revealing just how much maturity the architecture of Matplotlib has gone through.

00:07:18.180 In RubyPlot, we took the Matplotlib architecture and adapted it specifically to Ruby. I like to share the lovely story about its creation, which began as a reaction to the paid license of MATLAB.

00:07:50.449 John Hunter, a neuroscientist, faced a similar predicament with only one MATLAB license in his lab. Like any ordinary person, he created his own plotting library that would later be used by millions.

00:08:14.100 Now, let’s discuss the various degrees of abstraction. There are three layers: the backend layer, the artist layer, and the frontend API or scripting layer. Think of it as a cake: you have the backend at the base, the artist layer in between, and finally the scripting layer.

00:08:59.130 I have a better analogy for you. Have you guys seen the movie Ratatouille? Awesome! For those who haven’t, the movie features a garbage boy named Linguini, who becomes a chef with the help of a mouse.

00:09:19.890 In our case, Linguini is the artist, and the backend layer represents the canvas and paint he uses to create masterpieces.

00:09:48.090 The canvas is where you draw the image, which could be a PNG file or maybe a GTK window. The renderer is the paint you use, and importantly, there are two types of renderers: vector graphics and raster graphics. Raster graphics involve a collection of pixels, while vector graphics consist of paths and lines, allowing scalability without losing quality.

00:10:23.940 Finally, there is a secret ingredient to all this. Let’s move on to the artist layer. This layer has a class known as 'Axes' and contains a transformation layer to handle simple scaling of coordinates.

00:10:43.670 For example, given an image, I need to scale it down from 0 to 1 using simple linear algebra. This transformation layer is crucial for making the library dynamic. The 'Axes' represent the standard x and y axes with ticks and legends.

00:11:17.220 The front-end API, which I like to refer to as the scripting layer, is meant for users who want to create simple graphs without needing to manage all details.

00:11:54.480 A static plotting library is exemplified by a simple PNG image, which you cannot interact with. To make a static image dynamic, you need to have interaction capabilities, enabling user input to modify the visualizations.

00:12:27.180 An interesting story from my high school days is relevant here. I created a game called Snake, which had to appear animated while its tail got shorter. I refreshed the screen each frame, merely updating what was drawn. This concept of refreshing will also apply in making dynamic libraries.

00:12:54.960 Now, regarding the secret ingredient we discussed, there are actually two: an electronics engineer’s feedback loop and good event handling.

00:13:19.860 To facilitate better interactions, we integrate the GUI library with event handlers that communicate with the transformation layer, allowing dynamic updates based on user interactions without replotting everything from scratch.

00:13:58.620 Let’s talk about the grand design. The front-end layer directs commands to the transformation layer, which processes them and passes the information to the backend, rendering it all into a cohesive dynamic experience.

00:14:23.840 Now, let’s discuss the making of RubyPlot. Initially, my talk aimed to promote the library I worked on and share its architecture, but I've realized the main objective should be encouraging more people to work on open-source scientific software.

00:14:50.050 During its development, we decided to create a Ruby wrapper around the gr framework while integrating it with other essential components. I partnered with others in the community, which helped broaden the scope and capabilities of the project.

00:15:13.550 I initially explored various methods such as FFI and C extensions before landing on C extensions as the most reliable, albeit challenging, solution.

00:15:41.680 Our biggest challenge was handling plotting space effectively. We developed solutions to instantiate data classes dynamically, allowing automated plotting while ensuring proper axis scaling and data display.

00:16:01.800 The final challenge involved managing subplots, ensuring that when new figures or subplots were created, they would be accurately recognized and rendered.

00:16:20.010 Through perseverance, we succeeded in building a robust and flexible plotting library capable of accommodating various scientific plotting needs.

00:16:46.890 In summary, as we look towards the future of RubyPlot, our aim is to elaborate on the existing frameworks and encourage developers to contribute, making Ruby a viable alternative for scientific computation.

00:17:03.570 I encourage developers to explore Ruby as a language for scientific computing, arguing that its features make it suitable compared to Python, especially with its expressive syntax and metaprogramming capabilities.

00:17:43.570 Additionally, I discussed the potential for developing language-independent scientific software, emphasizing the importance of community-driven open-source projects.

00:18:07.460 In conclusion, I urge our audience to participate in collaborative efforts within the Ruby community, to build quality libraries and contribute to scientific software solutions.

00:18:23.570 Special thanks to my mentors and organizing bodies who contributed to the success of this initiative. I'm eager to connect with more developers and research participants to explore further opportunities.

00:18:49.350 Thank you so much for your attention! I look forward to engaging with you through questions and discussions.