HN user

elliott34

176 karma
Posts4
Comments83
View on HN

I have a lot of experience with this problem. The simplest way is via data munging in python/ pandas etc by finding what percent users convert/churn after doing an event N times within the first X days, and all the permutations thereof, using statistical tests around the change point. A more clever way is to use bayesian change point analysis.

The tricky thing is that these insights wind up being kind of obvious from the first analysis. You will find things like "users who use the software more are more likely convert." Other times these types of analysis will confirm what you already know. The tricky thing is making sure you have the right tagging/events and place to make sure you're getting at the right level of detail to get something worthwhile. It's very a much a garbage in garbage out type of thing.

Because the author draws a lot of parallels between computer science majors and physics majors, citing that physics majors are better prepared for the type of work ML requires. I am a physics major turned data scientist, and my argument is that I would have better prepared having been a CS major, given what the majority of my work requires. While in a CS major, a lot of data structures and algorithms haven't changed in 50 years either, you're much more likely to take electives with marketable skills or with up-to-date technologies (distributed systems, operating systems, OO/fp, databases, concurrency) that would've helped me in my day to day more than a math course or too did during my physics degree.

Doesn't really seem like the author spoke to a lot of actual physicists to write this article. Don't get me wrong, physics majors attract a certain type of intellect, but the vast majority of curriculum (quantum, EM, mechanics) are things THAT HAVE BARELY CHANGED IN THE PAST 50 YEARS. Meanwhile, CS majors come out much more prepared and hirable on the job market.

As far as the machine learning market goes, 90% of the projects require software engineering skills, the last 10% requires being able to go underneath the covers of linear algebra libraries, etc.

I just think the whole physics>cs degree for machine learning argument is not totally persuasive given my experience.

I think one of the only companies doing this right, and that has the resources to do this right, is facebook, as they seperate AI research and teams that are focused on putting these things into production (i.e. ML engineers vs Ml researchers). Trying to combine these two things into the same role is resulting in continued confusion and frustration. I like this Stitchfix article as an overview (http://multithreaded.stitchfix.com/blog/2016/03/16/engineers...)

2001: A Space Odyssey

Sunshine

Blade Runner, gattaca, the matrix, alien etc.etc. basically just google "best sci fi movies of all time"

Getting things done 10 years ago

Disagree about motivation. See Steven Pressfield's "War of Art" and "Do the work."

Motivation is ephemeral. Hard work, habit, consistently applying yourself regardless of your motivation, is key.

Not dangerous, in my experience. It doesn't take deep theoretical knowledge to provide value (i.e. value to a customer or to a business) through machine learning. Assuming here that one knows how to cross validate, check for overfitting, etc., and not shoot themselves in the foot.

EDIT: Note that it's still EXCEPTIONALLY difficult to provide true, lasting value to a given organization with this stuff and takes years of experience (note I didn't mention deep knowledge and experience with the latest techniques aboard the hype train).

The Math Myth 10 years ago

I wish everyone on r/MachineLearning and those preparing for data science careers would read this comment and heed the advice of those of us who have actually spent time on data science teams and have experienced all of this first hand.

The good news is you don't have to bookmark this blog because when you're writing scala and googling questions, it's going to come up on page one, because it's one of the best.

Yeah I mostly agree with this. There are some small wins though like how BigML allows you to export random forests into plain text node.js and you can just deploy in shitty php pipelines and boom you're doing machine learning.

I think the best part of this article is the approach to learning new things he presents--going beneath the surface, learning the fundamentals below the “API” layer (abstractly speaking). Really great explanation of that insight!

The part I am having trouble with, with ~5 years of real world data science experience in industry, is the implicit assumption that we all need or want to become good at deep learning.

In my experience, most businesses, at best, are still struggling with overfitting logistic regression in Excel let alone implementing/integrating it with a production code base. And we all know that toy ML models that sit on laptops create ZERO value beyond fodder for Board presentations or moving the CMO's agenda forward.

The fact of the matter is that the vast majority of businesses, with respect to statistics/ML, aren’t doing super duper basic shit (like a random forest microservice that scores some sort of transaction) that might increase some metric 10%. This is due to lack of sophisticated analytics infrastructure/bureaucracy/ lack of talent/ being too scared of statistics. Ultimately when you’re rolling out a machine learning product internally (I’m not talking about Azure/ other aws-model-training-as-a-service type things), the hardest part isn’t: “We need to increase our accuracy by 2% by using Restricted Convolutionallly Recurrent Bayesian Machines!” The hardest part is convincing people you need to integrate a new process into a “production” workflow, and then maintaining that process.

yeaaaaaahh but is that really the most annoying? dimensional modeling, getting all the joins right, scripting all the transforms (the T in ETL) is pretty annoying. Getting data into redshift is like, just the beginning. Not to mention, skips the transform part, at least.

The ideas of PID theory are really useful in a lot of operational/automation contexts.

For example, if your business is using any sort of machine learning model to govern a process, and you have some sort of idea of how you want this process to run throughout the day, you can build a PID system to change the model thresholds automatically to govern that plan.

An example might be any sort of retention/marketing strategy where you want to reach out to customers based on some factors X, and have a certain quota/capacity to do so during a day, and the expected number of customers with the best factors X can change throughout the day/week or is just erratic.

"Sometimes I wish that I was like an air-cooled Porsche mechanic or something very stable and non-computer related, so I could just work away in my shop and not have to ever touch this fucking demon box."

What was nice about working in scientific research back in undergrad in that whenever you got tired of coding the demon box, you could do some good physical labor in the lab.

"a toolset that allows non- and minimally-technical employees to quickly and easily build new reports"

Been there, done that.

This is the mantra of the BI system marketing machine that I've never actually seen work in practice.

But I'm glad you've seen BI enterprise systems succeed where the end users are happy and feel their toolset is flexible enough for the new daily challenges they encounter (sincerely).

I love Tableau as an exploration tool and think the UX and visualization capabilities are awesome. Just not the solution end users wanted. I've also rolled out a massive cloud based enterprise BI system (data warehousing, ETL, etc.) at a separate company. That wasn't the solution, either. Plotly was. But, just my two cents.