That is exactly correct. From javascript to an abstract syntax tree, and then to whatever target language we need. In this case GLSL.
>Presumably there's a not-significant overhead in both starting it up
That has been the goal, we're really careful to measure it with releases.
>and getting data back from the gpu.js function
That is correct as well, it is about as costly as it would be without GPU.js. However you can enable pipeline on kernels, so they can communicate via textures, which is significantly faster, as we don't need to transfer back to the CPU.
>Is there a way to "compile" a gpu.js function to remove the translation step? That could be really useful.
It is built into every kernel. You simply call `kernel.toString(...args)`.
A lot of neural networks start by first constructing the neural network structure, and eventually getting around to running the data through it. Where in brain.js, line 2 in most examples (just after instantiation) is train with data.
1. Tensorflow.js closely (not exactly) mirrors the python counterpart, and its api's, and thinking. We feel it does not reflect node ideologies well. And not the shify, what is in today is out tomorrow, thinking. The thinking that is practical, and applies well to business tastics. Brain.js started in node, and was original in its way it tackled the problem. Being data first, easy api, and then speed. It just works.
2. The vast majority of machine learning needs are encompassed within the library, and are only getting better.
3. The library can be learned in a matter of hours rather than weeks or months.
4. We can do it faster, simpler, than tensorflow.js. GPU support is coming in NodeJS, but is already partially implemented for browser, with fallback to CPU.
5. Brain.js was measured, where its benchmark was even better than industry standards, including IBM's Watson: https://github.com/jesus-seijas-sp/demo-nlp (note: project uses brain.js). Tensorflow.js isn't mentioned in this link, but I talked with the author about using Tensorflow.js, which he did try for this exact project, and his exact reply was: "with tensorflow.js same implementation I got a 0.91, but taked more time to train with CPU" (complete with typo)
6. Any corporation as powerful as those who maintain tensorflow should not have all the say in something as powerful as machine learning. Everyone should, and can.
7. We choose to.
What happened was essentially bullies. I think it is apparent now that the library and, more importantly, the idea of a data first neural network architecture in javascript isn't going away.
This is Robert, the lead developer for brain.js. Ty for the plug! I was going to mention this, nice to see people listening and helping spread the word. Working on it hard guys! When spare time cannot be had, just stay up late, and get up early!
Ty for asking this question! "Reinforcement learning" has a wide definition, but in this case because we are using a simple feed forward neural network, "reinforce" is more principled by dynamic programming with supervised learning. We are not actually using a "Deep reinforcement learning" algorithm.
The idea here is that the net can continue to train, reinforcing its previous understanding with new understandings, if new training data is provided.
It may be that we need to clarify the tutorial, as your point is based around unsupervised learning, not having training data.
All you need know are basic function calls, objects and arrays. I share the same fears you have about the JS ecosystem, especially when they overcomplicate something simple. By keeping the course thought out and simple we can adhere to a wide audience, and show off that the priciples are the same.
Usage: Javascript is everywhere and can be learned quickly.
Speed: GPU can easily be tapped into inside Javascript with projects like GPU.js, which brain.js uses.
>I guess it's doing some sort of transformation
That is exactly correct. From javascript to an abstract syntax tree, and then to whatever target language we need. In this case GLSL.
>Presumably there's a not-significant overhead in both starting it up
That has been the goal, we're really careful to measure it with releases.
>and getting data back from the gpu.js function
That is correct as well, it is about as costly as it would be without GPU.js. However you can enable pipeline on kernels, so they can communicate via textures, which is significantly faster, as we don't need to transfer back to the CPU.
>Is there a way to "compile" a gpu.js function to remove the translation step? That could be really useful.
It is built into every kernel. You simply call `kernel.toString(...args)`.