 Join me today before we begin the talk, might I request you to please put your phones on silent so that the others, let me check if I have put my phone on silent, I haven't, so that the others can enjoy it as well. Now since it's the first session after the keynote, let's talk Ruby. Now what are the good qualities of Ruby? Well, you have got the purity, you've got the polish, the refractive index, of course the chromium content. If you chuckled on that, then you'll love the joke I'm going to make at Perlcon. But seriously, the topic for the day is Ruby Plot, creating a plotting library in Ruby. Now we won't be coding along so if you'd like to, you can turn off your laptops. But who is this talk for? Is it for you? Let's take a quick survey. How many amateur Ruby's in the house? Cool. How many Ruby veterans? Awesome. Have you guys heard of this language named Python? Matplotlib, have you heard of that? It's a small plotting library, quite famous. Any Matplotlib users over here? A few, I see a few. And are these Matplotlib users only using Pipelot? Any hands? Cool. No Pipelot. I see one. 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, again, that was a question and it was a trick question. The correct answer is none of the above. Though my mom says that I'm a genius, I've got that. But let me introduce myself. Hi. I'm Tron of GERC. I am a senior year undergrad student from Bitspilani, India. I am amateur Rubyists. And I'm aspiring to be a researcher in the field of theoretical neuroscience and its conjunction with reinforcement learning. And finally, over the summer, I started working on a plotting library from the very scratch at Siruby because of Google Summer of Code. And there's a word of warning over here, so please don't judge me. What next? So let's go through a quick plan of the talk. Firstly, we had the introduction. The introduction is still going on. Then we'll talk about the general plotting library architecture, which is going to be modular so that you have different degrees of control. Then we'll be talking about a journey, well, my journey, to making a Ruby plot. Making some general thoughts, thoughts such as why should you use Ruby for scientific software, or apologies, why should you use Ruby for scientific software, and a crazy idea named language independent scientific software. Finally, at the risk of sounding like a snake oil salesman, I've got a brilliant opportunity just for you. And we will have a Q&A session, but it's going to be informal and it's going to be after the talk, so you can catch me around or you can tweet out to me anytime. Now, let's begin with the plotting library architecture. Since I want to drink some water, these are the sub points that we'll be going through. I won't be reading them out. You can see them for 10 seconds. You know what? I'm not patient, so let's make it three seconds. Cool. So what are the qualities of a good plotting library? Firstly, it should adapt to the needs of its user. You can be a high-level user who just wants a good bar plot. All I want to do is give in an array of values and I want a bar plot to be created. I don't want to define each in every pixel, but I can be a genius. Well, I am a genius. I can be a genius who wants to define a new plot altogether. These are the different layers of control that we want on the library, which brings us to our second point. It should be modular. By modular over here, I don't mean that the different degrees of control, but rather there should be different backends and the layers should be easily swappable. And finally, it should be dynamic. What do we mean by a static plotting library? What do we mean by a dynamic plotting library? We'll get to that. Also note that whenever I'll be talking about the plotting library, I'll be talking about the scientific plotting library. What's the different? The scientific plotting library is meant to handle a lot of data, and hence it has to be easily adaptable. Now, when we talk about plotting libraries, mat.lib is one of the best examples. It is the brainchild of late Dr. John D. Hunter. And importantly, it has been like any other open source software. It has been through a lot and a lot of iterations. In fact, while I was first looking through its source code, I found a comment in the C back end that said that the SWIG code goes over here. Now, that made me realize that the mat.lib devs use SWIG, which is scary. And secondly, that was depreciated quite a long time back. So the architecture for mat.lib has been perfected over and over years. And finally, it has a firm grasp over its API. So in Rubyplot, we took the mat.lib architecture, we took a take on that, and then we adapted it to Ruby specifically. Now, I usually like to share the lovely story about the creation of mat.lib. It was a screw you to Matlab because of the paid license. So force forever. John D. Hunter was a neuroscientist, and his lab only had one dongle for Matlab. Hence, he, just like any ordinary person, created his own plotting library, which would be used by millions and millions of people all together. Now, let's talk about the various degrees of abstraction. So these are the three, the back end layer, the artist layer, and the front end API or the scripting layer. Think of it as a cake, you get the back end layer, you get the artist layer, and finally, you got the scripting layer. In fact, I've got a better analogy. So have you guys seen this movie, Ratatouille? Awesome. For those who have not, Ratatouille has this crazy concept. This guy is named Lingweenie. He is a garbage boy who becomes a chef with help of that mouse. Now that mouse sits inside his cap and controls his body using the hair. But in our case, Lingweenie is a French artist who is going to be the perfect analogy for the plotting library. So let's go for the back end layer. Now, what is the back end layer over here? Well, if Lingweenie is the artist, then the back end layer is the canvas and the paint. The canvas over here is the place where you're gonna draw the image. For example, a PNG file or maybe a GTK window. Then you have got the renderers. So the renderer is the paint that you paint with. So you can see that there are two types of renderers mentioned over here. Vector graphics and Raster graphics. Raster graphics are simple matrix based renderer. But each in every pixel has a different RGB value. You can have an RGB alpha value, you can simply have a grayscale value. But that is Raster library. What a vector library is, just like its name, it contains various points and lines all together with relation to each other. So a Raster library takes more space, a Raster image takes more space, a vector image takes less space. But vector image requires specialized software to display itself in a Rasterized format. I hope I have got you all over here. Anyone lost? Cool. Finally, there is a secret ingredient. I'll get to that. Now, the artist layer. So this is Linguini over here. The artist layer has a class known as the axes. And then there is the transformation layer inside the artist layer. So you see the, hey, are you able to view the text at the back? Great, because I made a cardinal sin of not scaling up the font, sorry about that. But instead of coordinates, it's going to be coordinates as well as commands. What artist layer does, artist layer over here is Linguini, who uses the canvas, who uses the functions from the canvas to draw functions from the renderer to draw over the canvas. Now in artist layer, we firstly have the transformation sublayer. The transformation sublayer is used for simple scaling of the coordinates. For example, given an image, I'm going to scale it down from zero to one. Then I'm going to scale, then using simple linear algebra, I'm going to scale it, scale the input coordinates from zero to one. This is one of the most important layers when it comes to making the library dynamic. Now what the hell is dynamic library again? Have patience, I told you I'm going to get to that. Then we have axes over here. Now axes are your simple x and y axis. You have got the ticks on the various axes, the legends, and all the things which are required in a plotting library. So what Remy, the mouse has to do is simply tell the artist to have a particular type of axes or a particular type of legend to determine the scale of the figure. Great. Now here comes Remy, the front end API. Now you see the word coordinates written over here, just remove that and put a scripting layer over there. That scripting layer is Remy and our front end API. Now scripting layer is meant for laymen like me, who just want to make a good graph. I don't want to direct each and everything. I just simply want to say, let's say that A is a figure, I just want to say A dot bar equals this. And I want to get that. So scripting layer is simply a collection of routines which direct my artist to work along. So let's make a dynamic. Before making a dynamic, what exactly is a static plotting library? A simple PNG image, like a simple PNG or SVG or JPG image that we draw would be a static image, would be a static plotting library. Because you cannot click on that, you cannot move that around, you cannot translate through all the points, you cannot zoom in, you cannot zoom out and have the axes adapt accordingly. Any thoughts, how would you go ahead with that? How would you make this static image as a dynamic image? Anyone? All right, so I'll give you an interesting story from back when I was in my high school. So when I was in my high school, I think I was in the 11th grade. I had this brilliant idea that's gonna change my life forever. I was making this revolutionary game named Snake. Now, when the snake was moving, I didn't know how to make it look like it was moving along, but at the same time, its tail was getting shorter. So I had the idea that why not make its tail black when it moves a block further and make its head white? It was simply refreshing the screen over and over again. That is somewhat what we are going to do with the dynamic library. So the secret ingredient that we talked about is, I'm sorry, actually there are two secret ingredients. I was pulling your legs. Any electronics engineer over here? All right, anyone have heard of this term named control systems? Great, feedback loop, awesome. So the two important features over here are just a moment. Sorry about my sin. If you guys want to see the image up close, then you can simply go to this link over here. Or I will be having this slide over here, but well, I'll give you all 20 seconds. Till then, any questions, please no comments, just questions. All right, time's up. Yeah. So let's talk about the grand design of it all coming together. Firstly, what makes it dynamic? As you can see in the bottom most back in layer, there is an events layer which has been added to it. So let's say that we have got a GUI library. We'll go for GTK over here. We'll have different event handlers on the, we'll add different event handlers on the back end. Now these event handlers are going to communicate with the transformation layer. So let's say when you click the mouse on the image and you move it along pixel by pixel, it's going to have different translation, it's going to have different translation values. And again, using simple linear algebra, you can remove certain coordinates. You don't need to plot them to save memory. You can remove certain coordinates and you can change the various stick size as well as the X and Y values of the given coordinates. So it gives you an illusion of dynamic software, whereas it's just static images running together, just like movies. So let's go through the grand design. You get the scripting layer, I've removed the scripting layer for right now, but you've got the coordinates, you've got the commands. Those commands, they pass the coordinates through the transformation layer, which changes the coordinates from let's say, 20 comma 30 to 0.2 comma 0.3. And then those transform coordinates along with the axes specifications, such as the y-axis, the y-axis should go from 0 to 100, the x-axis should go from 0 to 100, the y, and it would be scaled from 0 to 1, along with the different lines and dots in the legend, which of course utilizes the backend renderers, the backend renderers, and at the same time, with the newly created events layer, we are communicating directly with the transformation layer. So whenever we move along, it seems like it's moving with you. Any questions over here? Do we have a question? No, all right. So let's talk about the making of Ruby Plot. Now, initially this talk had a different agenda altogether. I was here to promote the library, which I worked on. I wanted you all to know about the simple architecture, which I had made and a simple scripting API that you all can use. I would have gone through this diagram block by block, but I realized two things. Firstly, the aim of this talk is to get more and more people here working on open source scientific software. The reason why? We'll get to that. And secondly, I don't want to bore you with details. If you're interested in that, then I have links coming up. And it would also have some interesting conversations such as how we use the XKCD survey to name the different color symbols in Ruby and how it had some really good names such as Ruby, then we have Green Apple, then we have Dark Beach, then we have got Slime Green, and we have Mustard Green. Then I would have given you really good business tips as to how you can use Ruby Plot to make a power move at your work. But you can look at the two iterations of library on these links over here. So the first link is the official SyRuby repository, and the second link is the prototype which I created. So how I started with Ruby Plot. Back in summer, I was just going around a lot of projects. I just sifted through a list and here's the deal. I had never worked with Ruby before. In fact, I just thought that Ruby is a tool for web development, which is what most of the people think. But I came across this organization named SyRuby and they had this interesting idea. Why not create a plotting library which is going to be language independent? And which would be easily adaptable to each and any of this high level scripting language. That got my intrigue because I've been using Matlotlib for a long time. I didn't know how it worked. So I did loads and loads of research. I did loads and loads of research and I created a prototype using a vector graphics library. The prototype was in CF course, but over the iterations, we decided to create a prototype in Ruby and later on when the Ruby prototype is perfect, we would create the same thing in C. Now, so we decided to split development into two aspects. Me, I decided to work on something known as GR Framework. So GR Framework is a software library in C which is an artist layer created by an in-rear software engineer. It's a really brilliant piece of software. It's still in its beta, but it has a lot of potential. So I decided to create a Ruby wrapper over GR Framework and I've been recently informed that it's going to be used for Charity as well, so well, I'm quite happy about that. And the second, and along with me was my colleague, Arafat Khan, the creator of TensorFlow.RB and he decided to work directly on back end. One of the major mistakes that we made over here was that we forgot to put artist layer on his library. So I had a library which just had the artist layer implementation which I was not able to control and he had a library that directly interface with the back end. Hence, the control degree was gone. However, let's talk about my journey over here because I think I won't do justice to Arafat's journey. I started working on the Ruby wrapper, so initially I wanted some easy code, so I simply went for Fiddle. I realized that Fiddle did not have enough documentation. Cool, FFI has a lot of documentation. Let's go for FFI. Again, the issue was that I did not have a lot of control with FFI. So I went for the old fateful C extensions and because of the C extensions, after crashing my computer a lot of times and disabling it, I was finally able to get a working API over which I developed a scripting layer. Now, we'll be talking about the weird problems that we went through the scripting layer, but before we go for that, I'll give you a brief overview of the architecture of the library. So firstly, we have a class named Figure. Now, the Figure class over here is the scripting layer. The Figure class has something known as a subplot list. Each and every plot that you have in the library is a subplot by itself. Every subplot has a task list. What's a task list? We'll get to that and everything is a class. I know, weird idea. Then, we have got a plotting space. So if you guys have the image link on, you can perhaps look over there. Else, you can look at this image over here. However, let's talk about the weird problems which I failed, faced. Firstly, we had the chicken and the egg problem. Now, in GR framework, you had to do something quite weird. You had to define the plotting space before drawing the axes. That is, you needed to know what's going to be the minimum and the maximum coordinate before plotting. But to know that, I need to have all the different data points and all the different plots altogether. Now, how would I do that? So if it was some simple numbers, then I would have popped them into a stack. But it was functions. And how do you pop functions into a queue? Any ideas? So you would like to pop functions into queues. And when you have to plot it, all you have to do is press plot. It's going to see what's the highest value and it's going to plot it accordingly. So we came up with the idea of function classes. What we did was we wrapped each and every individual GR function into a class and whenever it was needed, we used to instantiate that class with a particular value. And while saying, let's say, figure.view, it's going to go through each and every iteration of the data point. And it's going to determine the minimum and the maximum data point. And while calling the object, it's going to pop the entire list and give you the optimal axes. So that's all the chicken and the egg problem. But I had a different problem altogether. So your backend functions have your lines, your dots, your rectangles. Now, to define a rectangle, you need to define the lower bounds and the upper bounds. But here's the issue. Let's say that I want to define a bar plot whose highest value is 10. As soon as I define that, I need to tell them that I need to say that the lowest low value is either going to be zero, it's going to be minus 10, it's going to be minus 100. So if I'm going to make a bar plot along with a line plot, and as initially I said that make a bar plot with the higher value 10 and the lower value zero, and then I said that make a dot on the graph with the lower value at minus 10, lower value at minus 20. What's going to happen is that you're going to have hanging rectangles with base at zero, with the base at zero, the upper bound at 10, and the axes is going to be somewhere down. So this was an issue that we found. That's right. So here we came up with something known as the lazy and robust plots. We had plots which were independent of other data points and were simply existing over the Cartesian plane. So we had different dots, those line plots, the dot plots, they existed over the Cartesian plane. And we also had plots such as the candlestick plots, we had the bar plots, we have histograms, we had pie charts, which required the location of the axes. Hence we came up with this idea. Now each and every plot over here is an object. Why not dynamically give the value to that object as and when we are calling that? So the figure class is going to have a subplot list which is going to have a subplot figure class. This subplot figure class is going to contain the various values such as the location of the origin, the maximum x value, the maximum y value, the minimum x value and the minimum y value. So while we are calling figure.view, all we have to do is iterate through hit and the call functions for lazy plots and robust plots would be different. So lazy plots are named so because they do everything at the end, just like me. So they do everything at the end and they instantiate their values at the end. While for the case of robust plots, all we had to do was call them as and when they were called. Finally, the problem of subplots. This is the issue that took me two months, one month. Because I, and again, I have already told you the solution but the problem was changing different plots. So if we go back over, a lot of poop, yeah. So if we go back over there, then you can see I have got a dot subplot two comma two comma one. What we mean by two comma two comma one is that you are defining imaginary matrix of two by two and if you go from, for row wise indexing, the first plot, which is going to be the upper left, is going to be changed. So how do you switch between those? For that, as I said before, we, yeah. So for that, as we said before, we had the subplot, we had the, just a moment, yeah. Yeah, for that, as I said before, we had the subplot list over here. So whenever a user asks for a subplot, firstly it's gonna check if that subplot exists. Let's say that user instantiates a new figure. So if a user instantiates a new figure, the subplot list is automatically going to have figure one comma one comma one, that is a one by one matrix and the only figure in that. But as soon as user asks for a new subplot, it's going to erase, it's going to empty the subplot list, it's going to start the new subplot, it's going to check if that subplot list already has that subplot because we had the identifier two comma two comma one. If it does not, if it does not, then it creates a new object and makes that your active subplot. If it has that object, then it looks for that, identifies the key, identifies the key and turns that into the active plot. So this is how we went through the subplot problem. Now, this might have been a bit fuzzy because frankly this requires a lot of diagrams and it requires a lot and a lot of code reading. But my good friend, Alish the Pani, has already worked on this and if you would like to go through the idea of the working, you can go through these two links. So you can either click a photograph or this is going to be uploaded at Confreaks. Next, we'll talk about the future of the library. So where are we right now? Well, in the official Rubyplot repo, we have a combined back end of mine and Arafat's work. So you have a front end and you have a messy artist and a back end. We have integrated that together so that you can use different back ends. But later on, we are going to separate these back ends. So you are going to have a predefined artist layer based on GR framework because frankly it's brilliant the way they have implemented the artist layer. And then we are going to have a back end renderer which we are going to define further later on. And finally, we are going to add the secret sauce, that feedback loop and the events layer. So some general thoughts. Now this is a dangerous issue to discuss over here because frankly these are my thoughts and I've been told that they can be quite controversial so bear with me. So firstly, why to use Ruby as an interface for scientific computing? Well, let me ask you a question. Why use Python? Anyone? Why would you use Python for scientific computing? Cool, let me answer the question then. Because it already has lots of library, cool. But why was Python chosen? Why not Ruby? So as Matt said before, Ruby was limited to Japan for a long time. And in 93 some researchers, I think it was from MIT, they created four different iterations of NumPy, numeric being one of them. They combined them together and that became NumPy. So Python had a head start along with its adaptation from Google. So Google pushed Python forward and hence you have got Python as the primary lingua of scientific computing. However, I tend to disagree. Now this is coming from a guy who had worked on Python quite a lot for the last three years and was introduced to Ruby this summer. What made me change my mind altogether? Well, firstly, Python is not as expressive as Ruby. That's what I feel because, come on, while working on an object-oriented language, you don't get public instances all over. Well, in Python, you don't have private variables. Secondly, you have got different accesses and good software development tools in Ruby. And finally, the most important aspect. Which has been derived from metaprogramming? Ruby has high metaprogramming capabilities, which Python lacks. So that is my take on why Ruby should be used for scientific computing. Great, I want to use Ruby for scientific computing, but how do I do that? There are no software libraries for that. Have patience. Before that, we'll be talking about language-independent scientific software. Now, I briefly told you guys about GR Framework. GR Framework was written in C and is an active component in the Julia plotting committee. So GR Framework is a brilliant software that I used. It was written in C and I was easily able to create an API for Ruby and use that for my own library. But what if GR Framework was more flexible then more flexible and allowed me access towards artist layer and the back-end layer. Again, it's in the beta stage of its development, so I won't be commenting on that. But the entire talk is about not reinventing the wheel again and again. I have got a plotting library for Python. I have got a plotting library for, let's say, Julia. Why do I have to create a plotting library all over again for Ruby? It's quite repetitive and it's a waste of time. What we can do is that we can work on language-independent software, something which would be written in a robust systems-level language, and in such a manner that it can be easily wrapped for different high-level languages and can adapt to them simply. Now, this sounds too easy when I say that, but I would remind you that initially my project was to create a language-independent library which I miserably failed at, and I created, and I created a language-based library. So this is something which I'm aiming for. But again, back to the question. How do you get the scientific instruments for Ruby? And this is where the brilliant opportunity comes for you. Get your QR scanners ready because we have a QR code, but firstly, why should you develop open-source software libraries? Why not just use the existing software libraries? Well, firstly, you'll get to learn various architectures. It would make you a better planner. Secondly, you'll be implementing each and everything by yourself, and of course, your GitHub profile is going to look good. So isn't that what we're looking for? And finally, why should you do it for Ruby? Since you are here at RubyConf, I am thinking that most of you work in Ruby and are quite comfortable with that. So this is giving back to your own community. This is telling the world that Ruby, the Ruby which is a language that whenever I type on Quora or Google, the first question that comes up is that is Ruby a dead language? Seeing the community over here, I know that it's very much alive and it's not just limited to web development. So this is your chance to go out there. This is your chance to contribute to Ruby, to contribute to scientific software. But how would you go forward with it? Well, there was an idea. An idea to get together the most brilliant people so that they can do something. Okay, it was gonna be the Avengers monologue, but I forgot that. So there is a group of people who work on open source scientific software at Ruby. Have you guys heard of NMatrix? So NMatrix is the Ruby equivalent of NumPy. Then we have got Daru, which is data analytics for Ruby. It's an equivalent to the Jupyter notebooks at Python. And finally we have got Rubyplot. There are many more projects, there are many more projects and that is for CyRuby. So why not introduce yourself to mail English? Because I am at the lowest rung of CyRuby. I am the most idiotic member at the team and trust me, there are brilliant people out there and those brilliant people, they are polymaths, something which has strived to be, we have got biologists who are programming, we have got cell biologists, we have got open source software developers who double as neuroscientists. So it carries on the passion of the scientific community. So I hope to see you at the Ruby mailing list. Now finally, special thanks to my mentors, Samir Deshmukh, Prasannan, John Woods, Piotr Prince and my co-author for Rubyplot, Arafat Khan. Of course, the RubyConf organizing team. Special thanks to Abigail Phoenix, I troubled her quite a lot and shout out to Google Office Suite. It's a brilliant free software, of course they're collecting my data, which I'm quite angry about, but it's a brilliant free software and it led to the development of these slides. And finally, if you would like to abuse me, you can tweet me out at PGTGRLY. If you'd like to make fun of my GitHub repository, it's right over there. Or if you'd like to ask me certain questions, then here's my mail. Also just to get the word out there, I'm looking for undergraduate research thesis. So if you have any leads, please mail me. All right, this is it and wow. So it's 39 minutes, we have one minute left. Would you like to grill me with questions? Or any comments? Cool, so I'll be roaming around here attending talks and trying to win the Nintendo Switch. So if you see me over here, just drop by and say hi. Also I'm looking for hashtag RubyFriends. See you guys and thank you very much for joining me today. I love you all. Well, more of a like. Bye bye.