1. Introduction to Adam 2 and the Engineering Problem
But first, a quick word about how you can start using React to write your own code. So here's a scenario. There's Adam, right, for machine learning for what do they call it? The trainer. You come up with this new idea trainer. It's called Adam 2. And it's revolutionary. And so you're like psyched about it. It represents an engineering problem. The implementations that we have to manage.
But first, a quick word about how you can start using React to write your own code. Probably the least qualified to be here. But that aside, I want to set up a scenario and we'll walk through it. And I want to propose something.
So here's a scenario. There's Adam, right, for machine learning for what do they call it? The trainer. There's various words for it. You come up with this new idea trainer. It's called Adam 2. And it's revolutionary. It's going to change everything with machine learning. And so you're like psyched about it. You want to get it implemented somewhere. And it's amazing because it represents innovation. And that's really what machine learning is kind of all about. We're innovating at breakneck speed.
And so we don't want things to hinder us in this arena. So here's our elegance and simple solution that represents Adam. And here's Adam 2. So, yeah, it's amazing. You're going to see it everywhere. But there's a problem even with just adding that one little number there. And that's this. It represents an engineering problem. The implementations that we have to manage. So, I personally write in Node. I'm in charge of a – or I'm rather the tech lead on the machine learning team. And for us to use this in Node, we would have to come up with translations in all these languages. And potentially more if we wanted it to execute in these environments. So, we've got JavaScript, WebGL, up-and-coming WebGPU, Wasm, native bindings, perhaps TPU, and even new languages.
2. Challenges of Implementation and Abstractions
So, yeah, that's what you need to know to add that little two in there. And also, you don't want to forget about unit tests for each language because you want to make sure that your stuff stays together. Each implementation has various needs, and so they're going to need different abilities, different capabilities. And that problem compounds because of those bugs, you have to fix them. Each implementation that you add nearly squares the complexity of the original implementation. And all you wanna do is add it to. Abstractions take away our understanding of what we're trying to actually get at. It all slows innovation.
So, yeah, that's what you need to know to add that little two in there. And also, you don't want to forget about unit tests for each language because you want to make sure that your stuff stays together. And they don't tell you this when you're developing on the GPU or when you start getting really close to the hardware, that there are precision differences that have to be managed.
And that each implementation has various needs, and so they're going to need different abilities, different capabilities. And each one is going to eventually compound technical debt. That's just kind of how development goes. And that problem compounds because of those bugs, you have to fix them. The underlying languages are constantly being refined and changed, right? And they have to be managing to add that to that Atom function. You have to go into those languages and actually alter them. And then what if somebody creates Atom 3? What does that do to Atom 2? Did they extend Atom 2 with Atom 3 if they did? And they use some sort of class structure, or maybe they can't because they use functional, depending on the environment, and each one's different. And so that leads to diverged code, because each code is different. And each code being different has to be tested differently, and you have diverged management. Each one, because each language requires different strategies, different system to manage what you've implemented.
And then two, there's how you arrive at the math. That diverges. And so each implementation, think about this carefully. Each implementation that you add nearly squares the complexity of the original implementation. And all you wanna do is add it to. And I haven't even mentioned the worst one, which is abstractions. Abstractions take away our understanding of what we're trying to actually get at. The math, right? It makes it really hard to understand. And that's why we're so afraid of it. Like we talk about, you don't wanna have to worry about this underlying math, because if you do, you'll go nuts. There's so much to think about, because there's so many different levels of abstractions. And it all slows innovation. So our elegant and simple, Atom2, which you can see on YouTube. It's not really on YouTube, I made all that up. It doesn't stay elegant and simple, even though in theory, in the math, it doesn't stay that way. And so we have to kind of change our understanding of things. If we want to scale, right, and our elegant and our simple, our engineering, right? What was the main objective we wanna get out? Innovation.
3. Innovation and Implementing Once
We want to be more innovative than we currently are. Without thinking about things differently, we're gonna just keep going down this road of divergence. In the movie Big Hero 6, the main character simplifies the design of a robot and makes it smaller and more portable, resulting in incredible capabilities. Implementing something once, without adding new languages or implementing it twice, is a more radical approach.
We want it to be innovative. We wanna be more innovative than we currently are. So Frank Zappa, he mentioned this, without deviation from the norm, progress is not possible. He's kind of a interesting fellow, but what he said was absolutely on par. Without thinking about things differently, we're gonna just keep going down this road of divergence and it becomes more and more difficult as time goes on.
So I'm gonna change pace here a little bit. There's this movie I watched recently with my kids and I loved it, it's such a great movie. I won't spoil anything for you in it, if you haven't seen it, but Big Hero 6. Now in it, there's this fantastic illustration. A hero, the main character, he builds a robot and that robot is really cool. It's extremely capable of doing all these kinds of really gnarly things and he sets his mind to innovate, to do something even more amazing than he's ever done before and all he does is simplify the design and make it smaller and more portable and when he presents it to everyone, nobody's head even turns. It's not even that big of a deal and then he shows what they're capable of by simplifying, by innovating, by using this little bitty bot, he basically turns into a superhero and everybody, they turn and they look at him and they're like, what? He's like floating from the ceiling and he's skating through the air because these little bots are aiding him because they're simple, because they're innovative and all he did was make it simpler. So there's a really amazing story to be expounded upon there. So if we were to kind of take some of that away from Big Hero 6 of all things.
What if we did something more radical? So implement it once and I mean truly once. Now think about that for a second, implement it once. There's currently being planned by very large machine learning players, huge entities out there that run the biggest search engines on the planet. They run my phone. They say we're going to do it, we're going to implement it once. So let's walk down that path what they're talking about. They implement a new language right at the start, brand new language. Yay. Right. Amazing. So now you don't have, you know, eight languages or six or five languages or three. You've got two languages, but you still have bindings and you have a new language. Now think about that. We have a new language. Guys, we do not need another language and we do not need to implement it twice. These are not...
4. Describing Math, Brain.js, and Implementing Once
We have a means of describing how to perform the math. However, we still don't have a means of talking directly to hardware devices. The internals of Brain.js sparked my interest in machine learning. Brain.js used two forms of training, which I named the Arthur Deviation. Brain.js outperformed larger libraries in natural language processing. Implementing once can be challenging due to language differences, but GPU.js translates to GPU code for JavaScript.
We don't need to do that. We have... We've had for 30, 40, 50 years low-level math being handled on hardware and we have a means of describing that in higher level languages such as for us, JavaScript or Python or whatever the case may be. We have a means of describing how to perform the math.
The problem is we don't have a means of talking directly to those hardware devices or at least we haven't. And this implemented, they quote once, but really it's twice. It still leads to abstractions. So that's still a problem. So we have to reboot our way of thinking if we really want to get down to the metal and think of things and implement them once.
Now I got started in machine learning. I did a lot of research prior but what really kind of sparked it for me was when I was looking at the internals of Brain.js. Brain.js is a really nice JavaScript library and it's written in JavaScript and at the time it was written just for the CPU. Now it runs on both but they did everything in one language. And their backpropagation used two forms of training rather than just one. So two optimizers, two trainers, whatever you want to call it. We call them praxis and brain. And to me that was super innovative. I'd never seen anything, anybody do that before, backpropagating using two different forms of training. And I actually went ahead and named it to the Arthur Deviation because it deserved more credit than it was given.
In fact this fellow here, Jesus Ciajes I think is his name, I probably am pronouncing that incorrectly. He went on and he took Brain and he turned it into a natural language processor and his quote from this URL. We broke all the records and he was comparing Brain.js, this little meek little library to Google Diagflow, Microsoft Luis and IBM Watson. He outperformed those with this little bitty. And I think in part is because of the the quick innovative ability to edit in one language. And that for me that turned Brain.js into a superhero. That that was amazing.
So if we were to truly implement it once we run in some difficulties here the type inference transpiling error handling type handling language differences because you have multiple languages to kind of translate into but we really don't have time to expound on that because I'm building my argument and I'm over half my time has been made up. So we're going to skip that. But we're going to we're going to just tell you right now that GPU.js translates to GPU code for JavaScript. And right now it does it for both Node and the browser.
5. Brain.js and the Principle of Writing Once
And Brain.js is written in JavaScript and it's currently being converted to TypeScript. The idea is to write it once. Bugs are handled once. There's no divergence, you embrace the math. Let that be a commanding force. By doing that, you keep your sanity and innovate faster. You become like a superhero. Here are some practical examples to convey what I mean. Our first example is Colorblind, written by Gant Laborde. It's the TensorFlow version, and I call it the canned approach.
And Brain.js is written in JavaScript and it's currently being converted to TypeScript. It implements GPU.js. So I'm not just here to plug Brain.js and GPU.js I'm really here talking about the principle. I just want to make sure I convey that. The idea is to write it once. Bugs are handled once. There's no divergence, you embrace the math. Because the math, when we write out the math for these operations, the math is beautiful. But as soon as we engineer it. We take all that beauty away. But I'm saying let's embrace it and get as close to that as possible. And let that be a commanding force. And by doing that, you keep your sanity and you innovate faster. You become like a superhero. You think about some superheroes that really set them apart. The guys that were normal. Like Batman. It was the car or the suit, right? It made him a superhero. It was something. I mean, maybe it wasn't very simple. But the car, for Big Hero 6 it was that little bot. So here are some practical examples to convey, I guess, kind of what I mean. So our first example was written by Gant Laborde. And he wrote Colorblind. What it's like to be colorblind in TensorFlow. And so this is the TensorFlow version. I call this the canned approach. Okay, so we've got like these functions that we get. And there's nothing wrong with those functions. In fact, in particular, in parts of Brain.js, we use those functions, just the same.
6. TensorFlow.js, Brain.js, and the Mandelbrot Set
With TensorFlow.js, you have to be able to alter any one of those methods like split, mean, stack or concat. That's the canned approach. Now this is the I've got Brain.js up here. That's actually the GPU.js version. This is next one is a green screen. We took that baboon. I took a green screen from Wikipedia, and I merged them together just thinking, hey, what would that look like? And so this is the math behind that. I've gotten this one before. Mandelbrot said a lot of people look at that and they see the math and it's so simple. Well, this is the Mandelbrot set. Beautiful.
But just bear with me. With TensorFlow.js, you have to be able to alter any one of those methods like split, mean, stack or concat. You'd have to be able to get at the code, the underlying code and for each of the environments. So that's really what I'm talking about here.
So that's the canned approach. Now this is the I've got Brain.js up here. That's actually the GPU.js version. So we set up our environment. You see settings. We have our output width and height that we're graphical. But really everything that is important is in the create kernel function. So we're grabbing a pixel and we're just basically dialing in what the red green average is and then setting our color. So there's really like three lines of operations there. And that is for me the direct approach because you're dealing directly with the numbers. And for me, that's more innovative. So that's one version.
This is next one is a green screen. We took that baboon. I didn't even show off that picture, the baboon right there, the top right. That's what it looks like, the output, right? So it's kind of like, whoa, there's some color missing. Because that's what it looks like when you're colorblind. The green screen, I took that baboon. I took a green screen from Wikipedia, and I merged them together just thinking, hey, what would that look like? And so this is the math behind that. So you basically just take the color difference, and you're just saying, hey, should I replace? Because they're within a max difference or min difference. I've gotten this one before. Mandelbrot said a lot of people look at that and they see the math and it's so simple. And they're like, what? I can't understand it. It's too complex. Well, this is the Mandelbrot set. Beautiful.
7. Mandelbulb for GPU.js and End-to-End Examples
Somebody wrote Mandelbulb for GPU.js, which is the code for the Mandelbrot set. In Brain.js, there's a practical example with just one line of code for the add layer. I'm working on an end-to-end solution called Welton, which allows you to customize beer taste and provides brewing instructions. Brain.js also has an end-to-end example using the FeedForward architecture, similar to React components, with input, hidden, and output layers.
Somebody even wrote Mandelbulb for GPU.js. This is the code actually. It is the Mandelbrot set, just we run it recurrently, in a loop. So it just kind of compounds on itself. But that's what it looks like in JavaScript right at the math.
And here's a more practical example in Brain.js. So in machine learning, there are layers and there are forward propagation and back propagation. Well, just taking this one layer, which is the add layer, and we look at the predict or forward propagate function, we can see there's really one line of code. Aside from setting up the actual function name and the arguments, we have a return of the input weights one, we get the X and Y value, and then input weights two, X and Y value and add them together. So super, super simple.
Now, is there an end-to-end solution? That's kind of much bigger, right, because we're talking GPUs all across the board. Well, I'm working on Welton. I'll have it finished maybe today or tomorrow. And links to it, that you can actually pick how you want a beer to taste and smell and how alcoholic you'd like it, and it will tell you what type of beer that you're trying to brew, what color it will be, and even how to brew it. And it's actually not that hard, it's actually a standard classification problem. It's just we haven't really thought about the normalization, denormalization of the values. But I'll have links to that on the presentation. And as a more general use, we have a practical example, end-to-end for brain.js. This is just XOR, or Zor, or however you wanna say it. The most important thing here is that the net is built on this new architecture called FeedForward, which relies almost entirely on the graphics processor. You can switch it, I say almost entirely, you can switch it between the CPU and the GPU. But here you sort of work with layers like you would with React components, if you guys are familiar with setting up websites and that type of thing. So if you can think of brain sort of being like the React for machine learning. We have a input layer defined as an input, hidden layers as an array, and the input from the argument previous, which is the actual layer instantiated is gonna be fed in. So these feed in recurrently from one to the next. You can have as many hidden layers as you like, each return value from one is gonna be the input into the next and you have your output layer and then it goes to the output. And then you basically net dot train, net dot run and outcomes and values. So that's not only just the end to end that's the entire training. That's the entire running. That's everything.
8. Evolution of Ideas and Simplifying Implementation
All the layers and maximum terse readability right there for you. We're talking about evolution of ideas. One idea builds on another idea builds on another. Everything is strongly typed when you're right at that layer right at the execution layer. The high-level language becomes the chalkboard. So you write your innovation once, you embrace the math and that leads to faster innovation. That's my talk.
All the layers and maximum terse readability right there for you. So that's kind of like the proof behind this idea. And ultimately we just want to make sure that we're trying to make something that's super straightforward not just in engineering but all the way down to the math. So the evolution revolution that's the name of the talk that I've got today and we're not talking about evolution with animals or anything like that. We're talking about evolution of ideas. One idea builds on another idea builds on another. For the longest time all we have done is abstract into these separate layers. It's been very hard to do it the other way which is to read the high level language and compose the lower level language. Well that's what I'm proposing. And I've actually found out after you understand the environment and it's really not that complex. In fact everything is strongly typed when you're right at that layer right at the execution layer because you can detect what's coming in and you know what's going out and you're detecting where it's going. And so if I can simplify it the high-level language becomes the chalkboard. The atom two implementation that we originally talked about becomes super simple and super elegant because the IDE that you implement it on is exactly where you're testing it and you no longer have to worry about those underlying languages because they're composed for you. So you write your innovation once, you embrace the math and that leading on that previous innovation that even leads to faster innovation. So that makes you like a superhero. That's my talk.
Acknowledgments, Q&A on TensorFlow vs Brain.js
I want to thank CallHammer Supply, Gantlabord, and the contributors to GPJS, BrainJS, and the Sli.Go. It's good to see that you still have some sun on your side. Let's jump to the questions. Someone asked about the innovation behind using JavaScript for neural network training compared to frameworks like TensorFlow and PyTorch. TensorFlow is open-ended and requires manual setup, while Brain.js automates repeat steps. Re-implementing is necessary for new languages and technologies. The long-term investment is to write code once and create an engine that transpiles it. Programming languages have different strengths and purposes. Rust is memory safe, Golang is good for small tasks. Brain.js has its own definition.
I want to thank these guys, CallHammer Supply, in addition our ML Conf EU CallHammer Supply for the beer recipes, Gantlabord, I mentioned him briefly. He's been a really nice colleague in driving machine learning and understanding of it. As well as contributors to GPJS, BrainJS and then the Sli.Go from these slides.
Thanks, and hope you guys enjoy the conference. Hey, how's it going? Hey, it's going pretty good. I really did enjoy your talk. How's it going for you? Like I see that you still got a bit of sun on your side. Oh yeah. It's just a pleasure to be a part of the whole operation. You guys are really put together a tight set of sessions, I guess. Yeah. Yeah, it's funny that we have speakers all around the globe, right? And you never know what time is it right now, right? And it's good to see that you still have some because for me, it's already like night.
But let's jump to the questions. I've seen some questions already on our Discord channel, so people can ask it in ML Q&A. And one is really open-ended, but I guess it's still helpful to answer since you're also part of a team of maintainers of Braintree.js. So, the person is basically asking, hey, it sounds amazing, right? But do you want to copycat everything for neural networks training in JavaScript when we have powerful deploying frameworks like TensorFlow, PyTorch, and Python? What is innovation behind it? And by the way, how big is the audience? Who is using? Where is the edge for this one? So the question is really open-ended, but if you can maybe slice a bit more on your developer audience and why, let's say, there is a new graduate basically from university, and he or she has a choice between TensorFlow or Braintree.js and what they should decide and how this decision process is going to look like.
Well, so TensorFlow is a very open-ended tool, right? It's very... Each time that you use it, you end up starting, connecting up everything layer by layer, input and output, and then explaining that and then running it. Whereas Brain.js is not really designed that way. It's more designed to allow for those repeat steps to be done for you. And so you can kind of get quickly to what you want to do without thinking about it a ton. As far as re-implementing, I mean, languages change over time and there's new languages that come out. WebGPU, for example, is something that's brand new. So it'll have to be re-implemented in there no matter where we're talking about, at least for those that want to take advantage of the graphics processor and JavaScript. So there's work being done in TensorFlow to do that. We're having it started with Brain.js, but really all we have to do is change the underlying engine, GPU.js, and then all of a sudden, Brain.js will just speak that. So it's more of the idea between a long-term and a short-term investment. Short-term investment is duplicate the code and you're building up technical debt, whereas long-term investment is write it once and then create an engine that transpiles it to whatever environment that we need to run it in.
Yeah. No, and I completely agree with you, right, because you can also ask like, hey, we have like C, right? So why do we need any programming languages, right? We just copy and paste from one place to another, right? And it is helpful, right? As long as we understand how is it different, right? Because you know that Rust is like memory safe, right? You know that Golang is like good for tiny things, right? And I guess you still have your definition for Brain.js.
Explaining Brain.js and Its Use in Research
Brain.js is a practical machine learning library that is tailored to working with data first. It allows for creativity and going the extra mile in applying machine learning in different ways. The implementation of convolutions in Brain.js was based on a different approach that made it more efficient. Brain.js is used by both researchers and developers, with researchers finding it easy to convey their ideas and implement them. The team behind Brain.js aims to make it easier for researchers and considers them as part of their audience.
Maybe, I mean, it's like very impromptu question, but how would you explain Brain.js like in one sentence, right? What is this, you know, like Rust is like for memory safe, right, and Brain.js is like for... Okay, well, I would say it's a practical machine learning library that is data-centric, it works, it's really tailored to working with data first, and I don't know, there's a way that I would clean that up, probably. I wouldn't broadcast it, you know, to thousands of people, but... Yeah, no, I mean, it's also a bit of like me asking you like on spot, right? So don't worry about having like super clean answer. And I guess like, you know, what you said practical is something that sometimes we're also forgetting, right? Because by you just using like, out of the box perfect like working solution, right? You don't learn much, right? You cannot be creative, right? You cannot go extra mile and apply it in a different fashion, right? So it's definitely like a good USP, right? You just need to find what is a strong side around this one. Yeah, I mean, so an example, we started working with convolutions, and there's parts of the network, parts of Brain.js, the project, not the network, where there's different networks that you can use different. And in researching for example, convolutions, and actually looking at the shape of them, I found it really not well understood. There are, you can look at an algorithm that's implemented, but actually seeing what it does is so much different than, rather how it does this is so much different than the way that we have traditionally thought. And that's why you'll see these really inefficient implementations of it, where they step through each cell and they basically just ask if something relates to it. Whereas the really quick way is to bend the other way around, where you say from the outputs, look exactly up your inputs, and then like calculate. But I found that there's not really any good examples for the backpropagation of that. And it really bother me. But anyway, we ended up writing it. After you see it though, like in JavaScript, in a language you don't understand, it's like a light bulb moment. Oh, it's so simple. You're just like looking up the locations, and it becomes a whole lot more digestible. No, it's a good point. I think it's like a good way to also... I mean, I don't want to say sell, because you don't have to sell anybody's open source product, but a good way to explain what is it about. So this is a good point. Maybe a different type of question. I'm not sure if you did follow for as a bigger machine learning frameworks. But now I have a feeling also that who is using framework in research? It's like a good indicator who's going to be, like, what people are going to follow later. The more cutting-edge research, the more pre-trained models, the more exciting models that are available for developers or engineers, the more easy it is to transition from, I don't know, to TensorFlow, to PyTorch, to Brain.js, or whatever else. The question, I guess, is going to be like in two parts. One part, do you feel or do you see a community of researchers trying to use Brain.js? Because it's so easy for them to convey what they want to try to implement. And second part, do you try with maybe a team of Brain.js to make it easier for researchers? And do you feel that they are also part of your audience? Or are you mostly focusing on developers and consumers, basically? How do you feel about this one? Yeah. So, I'll try to answer and and try to remember the best I can. Are there teams of researchers that use it? Yes, there are. One project that I saw was the ability to look through a human body from different points of view.
Graphics Processing, Innovation, and JavaScript
You can process data easily on the graphics processor using GPU.js. Brain.js beat Watson and other machine learning players with its innovation in natural language processing. It targets simplicity and JavaScript, aiming to provide efficient tools for hardware utilization. JavaScript developers worldwide would find it exciting to have one more tool. Thank you for your answers, open source contribution, and amazing talk.
So, you could actually pull out meaning from those slides. But having it basically on the graphics processor, you can basically process that data very easily. You can see it and then you can actually end up using GPU.js for that too.
But I think it's more about if you can see the results of something, if it can prove that it is a valid tool by numbers alone and by the logic of it being simple, then it's a shoe-in for anybody to pick up. One of the examples that I highlighted in my talk was that of natural language processing with brain.js, where it actually beat Watson and the biggest machine learning players of the time, because there was a bit of innovation that happened within the net. You could use different types of activation, which is now something that you can do, but I hadn't seen it at the time.
What was the latter part of your question? I didn't recall. Do you try to explicitly target researchers? I don't know. Maybe some people try to do something for them or try to just engage what problems they're having, because I guess engineers who are using already established models and somebody who tries to be flexible, they have different needs. They need different APIs or whatever else. No. Not targeting anybody. Just targeting simplicity and JavaScript. We don't have really mature tools yet in JavaScript outside of TensorFlow that are really efficient, that really take advantage of the hardware of the computer. So Brain.js is my selfish work to achieve that basically for myself.
Yeah. And it's a cool hobby as well, so I completely agree. Additionally, there is also quite a bunch of JavaScript developers all around the globe. So for them, having one more tool is definitely something cool and exciting. If I were a JavaScript developer, I would definitely open my console and just be like, hey, let's do some Node.js. But for now, I'm more on a Python side. So let's see. Let's see how it's gonna develop. Cool. It was awesome having you. Thank you again for your answers, for your open source contribution, and for your amazing talk. Thank you very much.
Comments