Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Machine Learning Crash Course

developers.google.com

Post reply on HN
Print view View original

111–120 of 233 posts

Re: Machine Learning Crash Course

#111

Post by eanzenberg »

xamuel wrote: post #64
minimaxir wrote: post #12

Looking through the topics covered, the standard AI-course caveats ( https://news.ycombinator.com/item?id=16247629 ) apply. Yes, AI/ML MOOCs teach the corresponding tools well, and the creation of new tools like Keras make the field much more accessible. The obsolete gatekeeping by the AI/ML elites who say "you can't use AI/ML unless you have a PhD/5 years research experience" is one of the things I really hate about…

The other day I met with someone who was visiting my city to attend a big ML conference. In the course of our discussion, it transpired this person did not know the Halting Problem. He'd "heard of" Turing machines, but nothing more than "hearing" of them. Gatekeepers shouldn't keep gates just for gatekeeping sake. But if so-called ML experts don't even know undergraduate computer science, that should really give you…

I could have the same reverse worldview:

"I attended a big software dev conference. Someone I met did not know about data bias. They heard of gradient boosting but nothing more than hearing them. If so-called dev experts don't even know undergraduate statistics, that should really give you pause before you open up your wallet for them."

Re: Machine Learning Crash Course

#112

Post by bitL »

3pt14159 wrote: post #23
minimaxir wrote: post #12

Looking through the topics covered, the standard AI-course caveats ( https://news.ycombinator.com/item?id=16247629 ) apply. Yes, AI/ML MOOCs teach the corresponding tools well, and the creation of new tools like Keras make the field much more accessible. The obsolete gatekeeping by the AI/ML elites who say "you can't use AI/ML unless you have a PhD/5 years research experience" is one of the things I really hate about…

Unless you work for a company obviously known for their ML the "expertise" out there right now is brutal. People are building recommendation engines without knowing the very, very, very basics like Jaccard indexes, ROC Curves, or topic drift. I've even had to explain type two error to someone working on one of these before. I agree with your general thrust, and you're right, messy data is often 95% of the problem, bu…

> Jaccard indexes

Funny you mention Jaccard; I was looking up if IoU (Intersection over Union) has any other name known to ML people when I was preparing my self-driving car presentation (IoU is used in semantic segmentation), and found out it is called Jaccard index as well. To my surprise, all ML experts I know knew about IoU but nobody about Jaccard. I guess it might depend on which university you attended?

Re: Machine Learning Crash Course

#113

Post by ssivark »

minimaxir wrote: post #12

Looking through the topics covered, the standard AI-course caveats ( https://news.ycombinator.com/item?id=16247629 ) apply. Yes, AI/ML MOOCs teach the corresponding tools well, and the creation of new tools like Keras make the field much more accessible. The obsolete gatekeeping by the AI/ML elites who say "you can't use AI/ML unless you have a PhD/5 years research experience" is one of the things I really hate about…

> Yes, AI/ML MOOCs teach the corresponding tools well, and the creation of new tools like Keras make the field much more accessible. The obsolete gatekeeping by the AI/ML elites who say "you can't use AI/ML unless you have a PhD/5 years research experience" is one of the things I really hate about the industry.

The problem is that having a hammer makes one see everything as a nail. Sure, given a suitably clean set of images, anyone who's done a couple of tutorials will be able to apply a pre-trained neural on them to get something.

The hard part is getting an understanding of what tweaks to use when, and when to give up on a method. Otherwise, it is very easy to get carried away and waste time/resources.

For that, one needs to develop a good understanding of the landscape of ML algorithms, why each of them works and how they could break. That typically takes (intensive) experience or an understanding of the theory. Otherwise you'll be doing a brute-force search through a list of possible algorithms. As they say, "a few days in the lab might save a few hours in the library..."

Yes, things can get painful during hiring because the process is broken as it is, with additional complications due to not knowing how to vet for quality in a nascent field. But the "ML elite" are not morons and they don't mean to be obnoxious gatekeepers.

Re: Machine Learning Crash Course

#114

Post by redditmigrant »

bkanber wrote: post #84
redditmigrant wrote: post #46

As someone who is trying to learn ML, all the courses available are hugely helpful. One thing I wish I had easy access to is the process that someone goes through while trying to build a model on a real dataset. Specifically following questions are the ones I struggle with: 1. How did you figure out what features would be useful? 2. How did you figure out what algorithm(s) are appropriate? 3. how and why did you mass…

> How did you figure out what features would be useful? There are various feature engineering and feature extraction techniques. Filter methods, wrapper methods, and embedded methods. Principle component analysis, autoencoding, variance analysis, linear discriminant analysis, Gini index, genetic algorithms, etc -- the feature selection process will depend on the dataset, the problem domain, the analysis algorithm you…

Thanks for the response!

> There are various feature engineering and feature extraction techniques. Filter methods, wrapper methods, and embedded methods. Principle component analysis, autoencoding, variance analysis, linear discriminant analysis, Gini index, genetic algorithms, etc -- the feature selection process will depend on the dataset, the problem domain, the analysis algorithm you ultimately use, etc.

Obviously thats a big toolbox and Im sure it takes time to develop an intuitive understanding for all these techniques. What I hope for is some sort guidebook on what to look for when I stumble across problems. So lets say you try out an algorithm and your accuracy(or whatever evaluation criteria you might have) is low. How do you figure out if thats due to the algorithm, or is it due to (or due to the lack of) feature selection?

An analogy that might be useful is, when I see my database queries are slow, I can use EXPLAIN to guide what knobs to tune. Obviously it requires understanding what indexes are, what a full table scan is etc. etc. but the EXPLAIN plan provides a guidebook of sorts.

Re: Machine Learning Crash Course

#115

Post by kevincennis »

eanzenberg wrote: post #61
ariwilson wrote: post #56

Earlier quoted context omitted.

Life skills? Communicative skills? What?

IMO essentially ML experts don't work in a bubble and may interface with potentially anyone at a company; C-level, engineering, product, marketing, ops, etc etc. What other tech-employee needs that flexibility? So, I grouped communication / life skills into being able to understand, read, interpret and ultimately provide value to potentially any team. Just having the technical skills will only get you so far.

I might be an outlier, but I interface with all of those on a daily basis in my role as a software engineer

Re: Machine Learning Crash Course

#116

Post by joshuamorton »

xamuel wrote: post #93
joshuamorton wrote: post #89

Earlier quoted context omitted.

Why does an ML-expert need to know the halting problem? Considering that ML is really a CS-oriented form of statistics, why would you expect a statistician to know CS theory?

Thinking more, it's the misleading names ("machine learning", "AI") that rustle my jimmies so much. Sure, you don't need to know the halting problem to approximately solve MNIST by fitting a million-parameter curve to a dataset. But you're misleading people if you're claiming to have any kind of insight into how computers can be made intelligent, or how computers can "learn", when you don't even know the halting prob…

Does this just come down to a semantic idea that if something isn't in pursuit of AGI, its not really AI? That feels unfair to most of these researchers who absolutely disagree with that.

And to consider these algorithms to not "learn" is similarly unfair. They do. They learn to solve specific problems (at least right now), but they do learn.

Re: Machine Learning Crash Course

#117

Post by jazoom »

throwaway84742 wrote: post #10

Unless you have already invested a lot of time into learning (and building on top of) TF, I would advise to pick up PyTorch. It’s much easier to learn and use (imperative!), and has higher performance on common workloads.

Except there aren't many good resources to learn it and the documentation isn't very good. Hopefully this will improve soon.

Re: Machine Learning Crash Course

#118

Post by aoki »

bitL wrote: post #112
3pt14159 wrote: post #23

Earlier quoted context omitted.

Unless you work for a company obviously known for their ML the "expertise" out there right now is brutal. People are building recommendation engines without knowing the very, very, very basics like Jaccard indexes, ROC Curves, or topic drift. I've even had to explain type two error to someone working on one of these before. I agree with your general thrust, and you're right, messy data is often 95% of the problem, bu…

> Jaccard indexes Funny you mention Jaccard; I was looking up if IoU (Intersection over Union) has any other name known to ML people when I was preparing my self-driving car presentation (IoU is used in semantic segmentation), and found out it is called Jaccard index as well. To my surprise, all ML experts I know knew about IoU but nobody about Jaccard. I guess it might depend on which university you attended?

i think the term is more prominent on the NLP side, via information retrieval (IR) and clustering. i first saw it in IR, and you'd see it in stanford's CS 124 or CS 224N, for example. if the parent is talking about people who are working on a system that has text-understanding component, i can understand their surprise.

Re: Machine Learning Crash Course

#119

Post by icc97 »

p1esk wrote: post #102
icc97 wrote: post #48

Earlier quoted context omitted.

I fully agree with you that after a MOOC you've barely scratched the surface and until you're implementing them yourself then you're not going to jump into a ML job. However personally I view the rest of the opposite way round. Getting through a course on Deep Learning takes months [0]. Then reading through Keras code once you understand the appropriate NNs is easy. For example it takes a while of going through Neura…

Understanding NNs is easy. Understanding, collecting, and cleaning up data is the hard part. Also, DL != ML. Paraphrasing "The Tao of Network Protocols": If all you see is DL, you see nothing.

The parent was referring to Keras which is a NN API hence why I responded talking about NN.

Re: Machine Learning Crash Course

#120

Post by aoki »

ardit33 wrote: post #57
eanzenberg wrote: post #33

Earlier quoted context omitted.

You probably can't communicate effectively. If you are describing "Type two error" of course you will get eyes glossing over. A huge problem with research fields is their terse banal labels. Confusion matrix anyone?

Or you can just say "false negative", and every CS major will understand you. I find people in Math and CS have often very different names for the same type of concepts and they could easy understand each other if they stuck to the more common terms. In this case, saying: TYPE 2 ERROR, makes you look like you are trying too hard.

type ii error is statistics, not mathematics. there is no equivalent concept in CS because type ii error relates specifically to statistical inference and hypothesis testing.

that said, if you are just pointing to a box in a confusion matrix and saying "TYPE II ERROR," you are probably trying too hard.

Post reply on HN