News for hackers. Stuff that matters.
Re:A Brief Introduction to Machine Learning for Engineers (2... by tw1010 on Sunday February 25, 2018 @06:47PM (#16461941)
This makes a good case for not learning machine learning three years ago. If you wait long enough for new paradigms to coagulate, you can use your energy more wisely during the chaotic transient period (e.g. by spending your effort on time-invariant parts of human knowledge, such as gaining a deeper understanding of parts of pure mathematics, or even philosophy or history), while you wait for a new set of fundamentals to converge, and really solid pedagogical explanations to surface.

The same could be said about skipping the earlier period of javascript frameworks. Had you used your time to learn things that are still useful today, and will remain useful decades in the future, while waiting for the industry to jump here and there, eventually converging to what seems to be a fairly robust steady state (react), then you'd probably be better off today than if you followed along with the hype cycle month after month.

A counter argument is that you might miss out on a lot of the monetary rewards that comes from learning the much desired skill that others don't have the time or will power to tackle in the period where doing so involves a lot of friction.

Re:A Brief Introduction to Machine Learning for Engineers (2... by wirrbel on Monday February 26, 2018 @04:20AM (#16464122)
> This makes a good case for not learning machine learning three years ago.

Have you looked at the monograph at all? This could have been written 5 to 10 years ago, 15 years ago, maybe a few sections would have looked a little different. In fact, I like to recommend Mitchell's Machine Learning book (I think it was written in the 90s) as an introduction to people with a serious interest.

There currently is a lot of hype going on for machine learning algorithms, because we see good progress in things like computer vision / pattern recognition. This kicks of a marketing machinery that really blurs the reality.

In reality, we have an established body of methods and modelling techniques that are sufficient, because the available data is the bottleneck for prediction quality. The actual challenge is to come up with a valuable business proposition, not necessarily to build the predictive model.

Re:A Brief Introduction to Machine Learning for Engineers (2... by bitL on Monday February 26, 2018 @07:32AM (#16464830)
I'd like to point out the fact that there is a split within Machine Learning into "classical" and "Deep Learning"-based one. While Deep Learning are just neural networks with Big Data on GPU, they obliterated many areas of classical ML. What you really want to learn is Deep (+Reinforcement) Learning, or what is coming known as differentiable programming. For classical ML, learn how to use Spark's MLlib and take Ng's Coursera course, that might be all you need from practical point of view.
Re:A Brief Introduction to Machine Learning for Engineers (2... by wirrbel on Monday February 26, 2018 @11:19AM (#16466375)
Deep learning has shown to have obliterated much of the computer vision area and other examples where classical approaches such as feature engineering are naturally hard. This comes at a price of a massive hunger for data of Deep Learning models to achieve an acceptable prediction accuracy. So with use cases like image recognition, etc. the relative performance of deep learning models is much better than with classical algorithms.

In general (you'll probably find specific counterexamples for this, but as I said _in general_) the relative performance of deep learning models to classical machine learning may drop below that of classical models when you start looking at medium-sized data sets. And I can assure you, there are many data sets, with many applications for machine learning. And while the world talks about deep learning, I know of many companies, where random forests, suport vector machines or bayesian models have been running for years (which means, cross-validated by data unavailable during model development) with a prediction performance that a business can depend on.

I agree with you that Reinforcement learning will as a technology become much more important in the next years. However, only if exploration is cheap enough. I expect Deep Reinforcement learning not to be the answer, at least not in its current state, but I can very well imagine that we will see more machine-learning-algorithm in the reinforcement-learning-loop experiments. I personally would hope to see more research in the bayesian reinforcement learning area.

Re:A Brief Introduction to Machine Learning for Engineers (2... by bitL on Monday February 26, 2018 @11:28AM (#16466466)
I know, DL works only if you have massive datasets, DRL is even worse for the number of training episodes. Maybe you've heard about recent craziness of using GANs to generate training set fillers when your training sets are small, i.e. you have only 1,000 examples but need 10,000 for reasonable performance. Instead of gathering more examples, you use GAN to create believable training data, and it seems to be working quite well (i.e. a bump from 60% accuracy to 80% while bigger training dataset with real examples would bump you to 90%).

What I observed is that many ML companies now run two pipelines in parallel, one based on Deep Learning and the other on classical ML, then cherry pick solutions that work best for the problem/scale they have.

Re:A Brief Introduction to Machine Learning for Engineers (2... by wirrbel on Monday February 26, 2018 @11:38AM (#16466573)
> I know, DL works only if you have massive datasets, DRL is even worse for the number of training episodes. Maybe you've heard about recent craziness of using GANs to generate training set fillers when your training sets are small, i.e. you have only 1,000 examples but need 10,000 for reasonable performance. Instead of gathering more examples, you use GAN to create believable training data, and it seems to be working quite well (i.e. a bump from 60% accuracy to 80% while bigger training dataset with real examples would bump you to 90%).

Sounds a bit like Baron Münchhausen pulling himself and the horse on which he was sitting out of a mire by his own hair.

I'd assume that instead of pulling such stunts, a reasonable generative model might have done the trick.

> What I observed is that many ML companies now run two pipelines in parallel, one based on Deep Learning and the other on classical ML, then cherry pick solutions that work best for the problem/scale they have.

Putting it this way, I agree. And my personal addendum here is: classical ML outperforms DL more often than the hype might make people think.

Re:A Brief Introduction to Machine Learning for Engineers (2... by bitL on Monday February 26, 2018 @11:44AM (#16466627)
> Sounds a bit like Baron Münchhausen pulling himself and the horse on which he was sitting out of a mire by his own hair.

It sounds crazy, but you've likely seen what NVidia did with high-resolution synthetic faces using their progressive GANs; I'd totally use them as training examples without any hesitation.

Re:A Brief Introduction to Machine Learning for Engineers (2... by dotancohen on Monday February 26, 2018 @07:28AM (#16464808)
> Have you looked at the monograph at all? This could have been written 5 to 10 years ago

The counterpoint is that a _lot_ could have been written 5 to 10 years ago, and only 10% of it would still be relevant. This is the relevant 10%.

Re:A Brief Introduction to Machine Learning for Engineers (2... by wirrbel on Monday February 26, 2018 @11:27AM (#16466452)
Looking at the table of contents, it is a subset of PRML [Bishop 2006]. And I suppose it is more than 10% PRML. And the things contained in PRML but not in the monograph are still relevant I'd say (Kalman filters, ...).

[Bishop 2006] http://www.springer.com/de/book/9780387310732

Re:A Brief Introduction to Machine Learning for Engineers (2... by briga on Sunday February 25, 2018 @11:12PM (#16463061)
A lot of the recent successes in ML haven't been based on new breakthroughs in theory. For instance deep neural networks have been studied for decades now. Same with the reinforcement learning algorithms behind advances like AlphaGo. So I don't think skipping ahead five years will necessarily help you.

That said, there was a lot of AI work with hand-crafted features and expert systems that has no basically been rendered obsolete by deep learning. But advances generally don't emerge out of a vacuum, and it helps to have some background knowledge of previous work to have a good idea of what has and hasn't worked in the past.

Re:A Brief Introduction to Machine Learning for Engineers (2... by cscurmudgeon on Monday February 26, 2018 @12:41AM (#16463370)
We have replaced hand-crafted features with hand-crafted architectures.

While performance might be important, at least the features were easy to understand by non experts. :)

Re:A Brief Introduction to Machine Learning for Engineers (2... by halflings on Monday February 26, 2018 @02:43AM (#16463799)
I find it's much easier to understand why 3 CNN layers applied on the raw image can learn convolutions that are relevant to solving my task... than it is to understand what is being done by "artisanal hand-engineered authentic patches" with a couple obscure dimensionality reduction algorithms thrown in, and an SVM on top.

Expert systems were also incredibly hard to build and debug, and weren't nearly as useful as ML systems are nowadays.

Re:A Brief Introduction to Machine Learning for Engineers (2... by metasyn on Sunday February 25, 2018 @07:52PM (#16462213)
Looking through the TOC - It seems like most of this was in just as a "fairly robust steady state" as it was three years ago? Was there some part of this that struck you as having solidified in the last few years?
Re:A Brief Introduction to Machine Learning for Engineers (2... by LouisSayers on Monday February 26, 2018 @04:56AM (#16464240)
Funnily enough this is a strategy I’ve been using for years.

At University I used to wait a while for others to complete their projects and then pick their brains about how they went about solving them.

Now in industry I don’t bother learning new tech until I start seeing those skills show up on job sites or if I have a very particular need that requires a particular technology as part of the solution.

This strategy has treated me well but I believe has only done so because not everyone takes this approach. I’m also grateful for the time and effort others put in to allow me to essentially freeload off of their hard work. Every now and then I do find something I can be truly passionate about to help others do the same.

Re:A Brief Introduction to Machine Learning for Engineers (2... by ardillaroja on Monday February 26, 2018 @06:04AM (#16464495)
Relevant xkcd (https://xkcd.com/989/)
Re:A Brief Introduction to Machine Learning for Engineers (2... by jimothyhalpert7 on Monday February 26, 2018 @05:37AM (#16464390)
This is my reasoning about blockchain. It was the first time I realised that just because I'm disposed to understand something better than the average person, doesn't mean I have to. Even if that something will be part of everyday life for every person. Society will just take care of packaging it into a familiar interface, e.g. credit card.

I then however realised that it would be a shame to let my advantage go to waste. So I use this:

> a lot of the monetary rewards

to partially motivate myself.

Re:A Brief Introduction to Machine Learning for Engineers (2... by nabla9 on Monday February 26, 2018 @04:16AM (#16464113)
Programming frameworks have lots of stuff that becomes obsolete over time. You don't really learn complex, open-ended and expanding mathematical subject like machine learning like you describe.

There is no book you just read and then you understand and now it's behind you. You are constantly making new connections and deepening your understanding when you learn more. Ten years is small time for things to start to sink in and make a connected whole in the mind.

Re:A Brief Introduction to Machine Learning for Engineers (2... by vikiomega9 on Monday February 26, 2018 @02:26AM (#16463746)
> A counter argument is that you might miss out on a lot of the monetary rewards that comes from learning the much desired skill that others don't have the time or will power to tackle in the period where doing so involves a lot of friction

Perhaps it can be argued that one is not in the position to take advantage of such situations. Switching jobs is not necessarily cheap

Re:A Brief Introduction to Machine Learning for Engineers (2... by FullMtlAlcoholc on Monday February 26, 2018 @03:10AM (#16463892)
Another counter-argument is you're still learning about frameworks in general which should help you pick up new ones quicker or provide a more comprehensive base of knowledge to draw upon when developing your own.