But the 2010 "American Community Survey" says the average houshold size is 2.63 (https://data.census.gov/cedsci/table?q=b25010&tid=ACSDT1Y201...), so for this survey the trend is flat.
2,341 karma · joined July 15, 2012
Worked on machine learning for medicine at Cardiogram. Studied CS at UC Berkeley. Former undergrad researcher and teaching assistant for Berkeley's ML class. Former intern at Twitter on Ads Analytics Infrastructure.
Email: bc@brianchu.com
github.com/bchu
twitter.com/brrrianchu
But the 2010 "American Community Survey" says the average houshold size is 2.63 (https://data.census.gov/cedsci/table?q=b25010&tid=ACSDT1Y201...), so for this survey the trend is flat.
Yes, NYC was the only place in America where the system was close to overrun and some hospitals actually were overrun, I'm not disputing that.
Models were predicting hundreds of thousands of deaths in the USA over the next few months, with lockdown. Many people were predicting hospitals would be widely overrun in New York City, parts of California, etc (again, with lockdown). These models and predictions, of course, were wrong.
Printing money and stimulus should have been expected (given the government's response in 2008) and therefore priced in, at least in theory. If we actually had massive numbers of bodies piling up outside hospitals in all major US cities, no amount of money printing would have propped up the markets.
The main study from Wuhan that people cite for airborne SARS-Cov-2 only found high levels of airborne SARS-Cov-2 in poorly ventilated areas of a hospital setting (where certain medical procedures like intubation are known to generate aerosols): https://www.nature.com/articles/s41586-020-2271-3. Well-ventilated areas had very low levels. A separate study in Singapore found no airborne samples in a hospital setting (https://jamanetwork.com/journals/jama/fullarticle/2762692). Documented spreading events are consistent with the disease not being aerosolized (one example: https://twitter.com/zeynep/status/1251556084424347649).
When I did the math, if I lived in the city it would be cheaper to use rideshare everywhere and rent cars when needed, than to own a car.
You can buy put options on Robinhood already.
Regardless of what common sense might say, the point is that the study didn't actually do a direct comparison.
All this regulatory squabbling is arguing over whether a square peg fits a round hole or fits a triangular hole.
We need a third classification for gig workers that affords them some protections while preserving the economic viability of ridesharing companies. Disregarding any problems we might have with specific companies, I think ridesharing companies are a benefit to consumers.
1. In my experience, each data source and each data format requires a lot of custom work. Each kind of prediction task requires additional custom work. I don't see this going away. Even if a company develops a solid core of reusable engineering infrastructure, it will always need to be adapted to the problem at hand. At this point, this company would seem more like a consultancy, with non-trivial marginal/variable costs. This reminds me of Palantir, which operates this way - core set of tools and infrastructure, consultants implement and apply these tools/infra at each client company with a lot of custom integration work.
2. Assuming this is not a problem and the shared infrastructure is able to generalize enough of the custom work to be feasible, this thesis actually seems like an argument for the big tech companies dominating all data companies. Google, Microsoft, and Amazon have the engineering talent and resouces to develop this hypothetical infrastructure. They also have the internal political will because they can then expose this as cloud APIs. Indeed, it appears they are already attempting this in certain domains.
3. Superior engineering infrastructure is indeed a competitive advantage, but isn't enough of a moat for a single company to dominate this space. Yes, great engineers are hard to find, but there are enough of them for more than one company to feasibly develop this infrastructure, with a lot of money. You can't say the same about trying to buy the social network of Facebook or Instagram.
Assuming autonomy is make or break for Tesla in the long term: if Tesla fails at it your stock will still be worth something (versus a useless upgrade). If Tesla succeeds you'll make more than enough to cover a retrofit.
2. Compiling Tensorflow from source on CPUs is a bit of a hassle but I have seen nice performance gains (10-20%) for LSTM tasks. I bet you would get even higher gains for CNNs since they're more parallelizable. (Note: I've never gotten the latest TF to work with Intel MKL).
3. I haven't fully tested this myself, but with the P100s you also have full support for half precision floats, which supposedly offer a huge speedup.
4. Also would have liked to see benchmarks of other frameworks like PyTorch, etc. I haven't used them myself but everything I've heard indicates that Tensorflow is often slower.
Our mission is to reinvent preventive medicine using consumer wearables. Our goal is for Cardiogram to be a “doctor” on your wrist that continuously screens your health based on your exercise and wearable data.
We have an Apple Watch app and an Android Wear app that help users track their heart rate and exercise, both built using React. We’re a small team funded by a16z and we’ve scientifically validated our algorithms with UCSF (https://techcrunch.com/2017/05/11/apples-watch-can-detect-an...).
We’re looking for engineers wth 2-4+ years of frontend, mobile, UI, product design, and/or product development experience to help us design and build out our mobile apps. Our stack is React, Node.js, and Postgres. You’d be working directly with our two founders and another engineer-designer. There is a ton of exciting design and frontend work we need to do around helping our users stay healthy, screening them for medical conditions, and providing them with options for diagnosis and treatment. We have hundreds of thousands of daily active users and our Apple Watch app has been featured by Apple in the past. All the time we hear anecdotes from our users about how their cardiologist recommended they use our app to track their heart rate.
Email me at brian@cardiogr.am.
The default behavior of TF is to allocate as much GPU memory as possible for itself from the outset. There is an option (allow_growth) to only incrementally allocate memory but when I tried it recently it was broken. This means there aren't easy ways to figure out exactly how much memory TF is using (e.g. if you want to increase the batch size). I believe you can use their undocumented profiler, but I ended up just tweaking batch sizes until TF stopped crashing (yikes).
TF does not have in-place operation support for some common operations that could use it, like dropout (other operations do have this support, I believe). Even Caffe, which I used for my research in college, had this. This can double your GPU RAM usage depending on your model, and GPU RAM is absolutely a precious resource.
Finally, I've had issues where TF runs out of GPU RAM halfway through training, which should never happen - if there's enough memory for the first epoch, there should be enough memory for every epoch. The last thing I want to do is debug a memory leak / bad memory allocation ordering in TF.
The original dropout paper's handwavy justification for dropout is that it prevents co-adaptation. It prevents individual units (nodes/neurons) in the network from relying on specific units in the previous layer firing as well. This is a bad thing because it's fragile (if one unit is off). I say handwavy because this is just intuition; there is not really any proof that this is actually what is happening.
Another commonly cited motivation is that dropout is like learning an ensemble of multiple networks.
The only paper I've seen that theoretically analyzes dropout is: https://arxiv.org/pdf/1506.02142v6.pdf, which proves it's equivalent to approximating gaussian processes (this is beyond me).
EDIT (reply to below): in general these statements are either vague and nonspecific, or perfectly correct and non-informative, comments that don't have much to do with my original point.