Propel – Machine learning for Javascript(propelml.org)
propelml.org
Propel – Machine learning for Javascript
http://propelml.org/
63 comments
If I had heard someone talking about ML in Javascript a few years ago I would think it was a joke, probably because my professors seem to love to make fun of javascript, PHP.
It binds directly to the TensorFlow C API, if you run it in NodeJS, which is awesome. I get tired of having to setup a python env anytime I want to play around with ML.
So now you'll have to setup a nodeJS env? I don't really see the difference.
Setting up a node env is arguably easier. An installer from the NodeJS downloads page includes both the Node runtime and NPM. One executable to get started.
Python, on the other hand, requires a python installer, then a pip or conda installation script. Not to mention python vs python3 decisions.
Python, on the other hand, requires a python installer, then a pip or conda installation script. Not to mention python vs python3 decisions.
There's no python vs python3 decision to make. There's no (sane) reason to pick Python 2 in 2018 for new projects.
Conda installer comes with Python prepackaged. So it's really a single exe and one CMD to get a Tensorflow env setup. And, of course, you have access to numpy, pandas, jupyter, PIL ...
Conda installer comes with Python prepackaged. So it's really a single exe and one CMD to get a Tensorflow env setup. And, of course, you have access to numpy, pandas, jupyter, PIL ...
+ virtualenv
I always forget to set that up. Also I never learned python packaging, with npm it was trivial.
I always forget to set that up. Also I never learned python packaging, with npm it was trivial.
The basic rule of thumb is npm is 'virtualenv by default' while pip is 'global by default'.
If you use pipenv it takes care of the virtualenv stuff behind the scenes for you.
You say this, but coremltools (convert from industry standard to Apple's ML framework) initially only supported python 2, so it was annoying to work with some code in Python 2 and some in 3.5.
ES5 and ES6 differ a lot. There's reverse compatibility, but they do differ.
pipenv --three shell
pipenv install pkg_1 pkg_ pkg_3 etc.
Seems pretty easy to me.
Plus, no one should be using Python 2 for any new project now, so that's not even a decision to bother with anymore.
Seems pretty easy to me.
Plus, no one should be using Python 2 for any new project now, so that's not even a decision to bother with anymore.
What's pipenv? Same as conda? Not using the system python also means installing python3 beforehand.
Pipenv is like virtualenv's but improved: https://docs.pipenv.org/
Conda is like pip, but focused only on the sciences/data stuff. Pip has everything that Conda has and more as it's the standard packaging solution for Python.
Conda is like pip, but focused only on the sciences/data stuff. Pip has everything that Conda has and more as it's the standard packaging solution for Python.
Conda is like pip
Conda is more like pipenv in that it does both package management and environment/version management. And while it's true that not every python package is in conda, that vast majority are and conda and pip play nicely together if you want to use pip to install some packages.
Also conda can be used to install both surrounding tooling (like gcc and make, super useful on Windows) and, in many cases, build dependencies and necessary C libraries. Something pip doesn't handle. Doing for example "pip install gdal" will very likely leave you chasing down third party dependencies, while doing "conda install gdal" will just work.
Finally, conda has recently added R support. So you can now manage your R packages and environments with the same tools as python. Super handy if you have project that uses both R and python.
Conda is more like pipenv in that it does both package management and environment/version management. And while it's true that not every python package is in conda, that vast majority are and conda and pip play nicely together if you want to use pip to install some packages.
Also conda can be used to install both surrounding tooling (like gcc and make, super useful on Windows) and, in many cases, build dependencies and necessary C libraries. Something pip doesn't handle. Doing for example "pip install gdal" will very likely leave you chasing down third party dependencies, while doing "conda install gdal" will just work.
Finally, conda has recently added R support. So you can now manage your R packages and environments with the same tools as python. Super handy if you have project that uses both R and python.
But some version python comes pretty much with every system, then you only need to install tensorflow with pip.
I've come across benchmarks claiming a 7x speedup if you build Tensorflow from source. So you basically don't want to install using a binary wheel.
If you're happy with Python, great. But the market for something like this can be so much bigger.
Let's say you already have a NodeJS service. This reducers the friction to add some ML into the mix to basically zero. Install the optional propel_linux_gpu package, throw it on a GPU instance on AWS and call it a day.
ML right now is still mostly the domain of the tech giants and researchers, efforts like these will serve to make it an everyday component of software stacks everywhere.
Let's say you already have a NodeJS service. This reducers the friction to add some ML into the mix to basically zero. Install the optional propel_linux_gpu package, throw it on a GPU instance on AWS and call it a day.
ML right now is still mostly the domain of the tech giants and researchers, efforts like these will serve to make it an everyday component of software stacks everywhere.
I don't know what is the best practice. `pip` `virtualenv` `pipenv` `conda`?
NodeJS has `npm` or `yarn`, and they basically do and setup the same thing. You can switch between the two without headache. As a new user (or one who has tried on multiple attempts to get into it), python is hard to start.
NodeJS has `npm` or `yarn`, and they basically do and setup the same thing. You can switch between the two without headache. As a new user (or one who has tried on multiple attempts to get into it), python is hard to start.
Maybe they already have a Node environment set up and appreciate not having to context switch?
The difference is now you don't have to setup a python env.
Looks like Mr Dahl was among the inaugural class of the Google Brain Residency:
http://tinyclouds.org/residency/
http://tinyclouds.org/residency/
Going back to the Tensorflow C API and adding plotting + networking + async capability is a smart engineering choice.
Will this project expand faster than Tensorflow Python to make it worth investing in? We will see in the coming months :)
Will this project expand faster than Tensorflow Python to make it worth investing in? We will see in the coming months :)
Python has a larger ecosystem for data intensive application and pratictoners. As a language it's very easy to learn for JavaScript devs.
The only "killer" feature JS may bring to the table would be client side, browser based inference that leverages GPU. But we're eons away from that.
The only "killer" feature JS may bring to the table would be client side, browser based inference that leverages GPU. But we're eons away from that.
I get your point, I think it is a bit reductive.
I agree that JS is king in client side from PWA, desktop and native (with react), but also in async/API/distributed architecture. From a web server point of view, it took a large share of what usually went to Rails or PHP. It is a trend here to stay.
JS is also the largest community of devs, with 12M people very well versed in UX and ergonomics, something ML desperately needs to deploy faster.
Finally JS is a fast moving and innovative language due to many factors, from the fact we have several implementations, a light process for the tc39, transpilers, typescript/flow and wasm... What JS lacks from a syntax point of view may be adopted in months.
So wait and see, history is not written yet.
I agree that JS is king in client side from PWA, desktop and native (with react), but also in async/API/distributed architecture. From a web server point of view, it took a large share of what usually went to Rails or PHP. It is a trend here to stay.
JS is also the largest community of devs, with 12M people very well versed in UX and ergonomics, something ML desperately needs to deploy faster.
Finally JS is a fast moving and innovative language due to many factors, from the fact we have several implementations, a light process for the tc39, transpilers, typescript/flow and wasm... What JS lacks from a syntax point of view may be adopted in months.
So wait and see, history is not written yet.
Agreed. Scientific computing has centered on two languages for well over a decade. I don’t think JavaScript is going to dethrone python as the interpreted language of choice because it can now push computation to the GPU via a well designed API.
Arguably the only "killer" feature Python has is the ecosystem. There are efforts to build out a similar ecosystem for JS. For example https://github.com/jacobbogers/libRmath.js is a typescript port of R's core math library https://svn.r-project.org/R/trunk/src/nmath/
And the full force of the entire machine learning research community (except for a few still on Lua/Torch).
We JS folks just need 1 good deep-learning system in JS. I really want that system to be propel as it leverages the work that has gone in on tensorflow. Let that piece fall into place, and just watch as the last bastion of python gets overrun.
>>...watch as the last bastion of python gets overrun
That is a naive point of view. The python community has been growing for decades [1]. Even if it is not growing as fast as javascript community, the growth is sustainable, and probably won't slow until the companies that rely on it for core parts of their infrastructure are gone (that could be 5 decades). Google, youtube, instagram, and countless other enormous corporations with trillions of dollars in combined market cap are dependent on it. Python isn't going anywhere.
[1] https://trends.google.com/trends/explore?date=today%205-y&q=...
That is a naive point of view. The python community has been growing for decades [1]. Even if it is not growing as fast as javascript community, the growth is sustainable, and probably won't slow until the companies that rely on it for core parts of their infrastructure are gone (that could be 5 decades). Google, youtube, instagram, and countless other enormous corporations with trillions of dollars in combined market cap are dependent on it. Python isn't going anywhere.
[1] https://trends.google.com/trends/explore?date=today%205-y&q=...
How do you figure that deep learning is "the last bastion of python". From where I'm sitting deep learning is just the newest of many bastions.
Also JS has possibilities for better interactive visualization using D3 and other things.
Does the tensorflow C API use CUDA if you have it installed?
I was going to say that this seems like the same as deeplearn.js[0], but it turns out this is built on top of it.
So I guess the real feature is cross-platform compatibility between node and browser?
[0] https://github.com/PAIR-code/deeplearnjs
So I guess the real feature is cross-platform compatibility between node and browser?
[0] https://github.com/PAIR-code/deeplearnjs
Didn’t he left the nodejs ecosystem because he said vocally that Go is so much better? Just curious what changed his mind...
He just hates almost all software anyway:
http://tinyclouds.org/rant.html
http://tinyclouds.org/rant.html
You might be paraphrasing a little there [1]
> Pramod: Yeah, I like the programming model of Go. Using goroutines is so much easy and fun. In fact, we are using at work for building a distributed application.
> Ryan: Yeah, I think it’s… for a particular class of application, which is like, if you’re building a server, I can’t imagine using anything other than Go. That said, I think Node’s non-blocking paradigm worked out well for JavaScript, where you don’t have threads. And I think that a lot of the problems with kind of the call-back soup problem, where you have to jump into many anonymous functions to complete what you’re doing has been alleviated these days, with the async keyword, the async feature that’s in Javascript now.
> So, kind of the newer versions of Javascript has made this easier. That said, I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever.
> Yeah. I think where Node has shined, weirdly, on the client side. So, doing kind of scripting around building websites. So, Browserify, for example. Kind of bundles up client-side Javascript. So, you can have all this server-side processing of client-side Javascript. And then, you know, maybe small servers to… maybe little development servers, and here and there, maybe some real servers serving live traffic. Node can be useful, or it can be the right choice for it. But if you’re building a massively distributed DNS server, I would not choose Node
[1] https://www.mappingthejourney.com/single-post/2017/08/31/epi...
> Pramod: Yeah, I like the programming model of Go. Using goroutines is so much easy and fun. In fact, we are using at work for building a distributed application.
> Ryan: Yeah, I think it’s… for a particular class of application, which is like, if you’re building a server, I can’t imagine using anything other than Go. That said, I think Node’s non-blocking paradigm worked out well for JavaScript, where you don’t have threads. And I think that a lot of the problems with kind of the call-back soup problem, where you have to jump into many anonymous functions to complete what you’re doing has been alleviated these days, with the async keyword, the async feature that’s in Javascript now.
> So, kind of the newer versions of Javascript has made this easier. That said, I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever.
> Yeah. I think where Node has shined, weirdly, on the client side. So, doing kind of scripting around building websites. So, Browserify, for example. Kind of bundles up client-side Javascript. So, you can have all this server-side processing of client-side Javascript. And then, you know, maybe small servers to… maybe little development servers, and here and there, maybe some real servers serving live traffic. Node can be useful, or it can be the right choice for it. But if you’re building a massively distributed DNS server, I would not choose Node
[1] https://www.mappingthejourney.com/single-post/2017/08/31/epi...
I think his argument at that time was mainly on network applications.
I think you are talking about TJ holowaychuck, the guy who build http infrastructure for node.js
this project does not work out of the box via npm install. seems like you have to get all babel.js with it and maybe use a typescript executor like ts-node
ES2015 imports took javascript back to 2008, before node and npm made it awesome.
use NPM and require if you are building tools for other people, that way they can implement your work without adding compilers and obscure configurations to their build. don't nobody want to use be forced to use alternative and backwards incompatible technology
use typescript and import for "business logic"
ES2015 imports took javascript back to 2008, before node and npm made it awesome.
use NPM and require if you are building tools for other people, that way they can implement your work without adding compilers and obscure configurations to their build. don't nobody want to use be forced to use alternative and backwards incompatible technology
use typescript and import for "business logic"
Although propel itself is written in typescript, supporting users that want to write javascript is an explicit design goal.
The npm package contains "vanilla" javascript that targets node.js 8.x and later.
This could a fun way to learn ML using just your browser. I'm still skeptic about the performance but for prototyping it could be viable.
One thing bothering me about reading the API is the inconsistent way of adding semicolons. Not an important thing I'm sure and as my personal opinion I'd much rather have the examples without them. To me they are just waste of time. Also it makes the code look more like Python.
Anyway, looks great!
One thing bothering me about reading the API is the inconsistent way of adding semicolons. Not an important thing I'm sure and as my personal opinion I'd much rather have the examples without them. To me they are just waste of time. Also it makes the code look more like Python.
Anyway, looks great!
You will hate to hear that there is a serious proposal to make semicolons mandatory in the next version of ECMAScript.
I found [this pull request] that adds language recommending the use of semicolons, but no proposals to require semicolons or to remove Automatic Semicolon Insertion.
Removing ASI from ECMAScript would break backwards compatibility - modern JS engines couldn't run scripts that use ASI which would break a lot of websites that are alread deployed. ECMA will add features that won't run in old engines (older V8 can't parse arrow functions) but they won't add/remove/change features that break existing behavior.
Today there are code patterns where ASI is ambiguous, or at-least hard for a developer to grok. TC39 is warning developers that new language features will not be designed for ASI and might have confusing behavior if those new features are used without semicolons.
[this pull request]: https://github.com/tc39/ecma262/pull/1062/files
Removing ASI from ECMAScript would break backwards compatibility - modern JS engines couldn't run scripts that use ASI which would break a lot of websites that are alread deployed. ECMA will add features that won't run in old engines (older V8 can't parse arrow functions) but they won't add/remove/change features that break existing behavior.
Today there are code patterns where ASI is ambiguous, or at-least hard for a developer to grok. TC39 is warning developers that new language features will not be designed for ASI and might have confusing behavior if those new features are used without semicolons.
[this pull request]: https://github.com/tc39/ecma262/pull/1062/files
Can you provide a source for that?
Closest thing I could find was this, which simply adds an ASI hazard clause: https://github.com/tc39/ecma262/pull/1062
Closest thing I could find was this, which simply adds an ASI hazard clause: https://github.com/tc39/ecma262/pull/1062
No, there isn't. I am on TC39.
Python doesn't use semicolons as statement terminators. C does.
Though they’re rarely used in practice, the Python grammar does allow the use of semicolons to separate multiple statements on the same line.
https://docs.python.org/3/reference/compound_stmts.html
Is there a practical use case for this system? It looks great. I want to parse out textual data and this system seems to only work on numbers sets.
I guess it's still work in progress, but they are probably aiming to achieve something in the direction of the scientific Python stack (i.e. Jupyter, TensorFlow and the like). Maybe starting with a subset of methods useful in ML.
It will be interesting to see how this scientific JS toolchain evolves. Would be fun to get a more feature-complete Propel ML working with Mike Bostock's Observable project:
https://beta.observablehq.com/
It will be interesting to see how this scientific JS toolchain evolves. Would be fun to get a more feature-complete Propel ML working with Mike Bostock's Observable project:
https://beta.observablehq.com/
> achieve something in the direction of the scientific Python stack (i.e. Jupyter, TensorFlow and the like).
Seems to be quite far away. IIRC, there are a lot of immature, scattered math libs for JS.
Most of the ML libs I've seen are proof-of-concept, like brain.js or synapse. Those libs seem to implement basic perceptrons and other textbook examples, but not much else.
Seems to be quite far away. IIRC, there are a lot of immature, scattered math libs for JS.
Most of the ML libs I've seen are proof-of-concept, like brain.js or synapse. Those libs seem to implement basic perceptrons and other textbook examples, but not much else.
Wonder if JS notebook environments like this one, Observable and runkit.com will eventually all consolidate and (hopefully) integrate with Jupyter Notebook / Lab
https://jupyter.org/
https://jupyter.org/
I enjoy machine learning and I'm interested in learning Javascript, so this seems really interesting. That said, what would be a good way to build some Javascript experience that would be useful for something like this?
We need more projects like this to bring better AI to JS. Thanks.
Is anyone aware of a GAN example using propel or deeplearn.js ?
I didn't explore the full API yet, but already seeing the plotting functionality for functions is a tremendous win for ML in JavaScript.
In case anyone is interested in doing ML in JS in 2018, there exists a larger article which I wrote a couple of weeks ago that tries to convey the state of the art of Machine Learning in JavaScript. [0]
- [0] https://www.robinwieruch.de/machine-learning-javascript-web-...