Fast.ai

How's the fast.ai Introduction to Machine Learning for Coders! Course?

It doesnt seem like the usual Machine Learning courses as it there are only two topics : Random forests and Gradient descent in which the whole course is covered. There are many topics missing like Clustering , other classification models.

[D] An Opinionated Introduction to AutoML and Neural Architecture Search - Rachel Thomas [fast.ai]

Starting with Deep Learning in 2025 - Suggestion

I'm aware this has been asked many times here. so I'm not here to ask for a general advice - I've done some homework. My questions is - what do you think about this curriculum I put together (research + GPT)? Context: \- I'm a product manger with technical background and want to get back to a more technical depth. \- BSc in stats, familiar with all basic ML concepts, some maths (linear algebra etc), python. Basically, I got the basics covered a while ago so I'm looking to go back into the basics and I can learn and relearn anything I might need to with the internet. My focus is on getting hands on feel on where AI and deep learning is at in 2025, and understand the "under the hood" of key models used and LLMs specifically. Veterans - whats missing? what's redundant? Thanks so much! 🙏🏻 PS - hoping others will find this useful, you very well might too! |Week/Day|Goals|Resource|Activity| |:-|:-|:-|:-| |Week 1|Foundations of AI and Deep Learning||| |Day 1-2|Learn AI terminology and applications|DeepLearning.AI's "AI for Everyone"|Complete Module 1. Understand basic AI concepts and its applications.| |Day 3-5|Explore deep learning fundamentals|Fast.ai's Practical Deep Learning for Coders (2024)|Watch first 2 lessons. Code an image classifier as your first DL project.| |Day 6-7|Familiarize with ML/LLM terminology|Hugging Face Machine Learning Glossary|Study glossary terms and review foundational ML/LLM concepts.| |Week 2|Practical Deep Learning||| |Day 8-10|Build with PyTorch basics|PyTorch Beginner Tutorials|Complete the 60-minute blitz and create a simple neural network.| |Day 11-12|Explore more projects|Fast.ai Lesson 3|Implement a project such as text classification or tabular data analysis.| |Day 13-14|Fine-tune pre-trained models|Hugging Face Tutorials|Learn and apply fine-tuning techniques for a pre-trained model on a simple dataset.| |Week 3|Understanding LLMs||| |Day 15-17|Learn GPT architecture basics|OpenAI Documentation|Explore GPT architecture and experiment with OpenAI API Playground.| |Day 18-19|Understand tokenization and transformers|Hugging Face NLP Course|Complete the tokenization and transformers sections of the course.| |Day 20-21|Build LLM-based projects|TensorFlow NLP Tutorials|Create a text generator or summarizer using LLM techniques.| |Week 4|Advanced Concepts and Applications||| |Day 22-24|Review cutting-edge LLM research|Stanford's CRFM|Read recent LLM-related research and discuss its product management implications.| |Day 25-27|Apply knowledge to real-world projects|Kaggle|Select a dataset and build an NLP project using Hugging Face tools.| |Day 28-30|Explore advanced API use cases|OpenAI Cookbook and Forums|Experiment with advanced OpenAI API scenarios and engage in discussions to solidify knowledge.|

Advise Needed] Mechanical engineer trying to venture into ML

Hello fellow redditors, ​ As the title suggests, I am a mechanical engineer with a masters in mechanical design from a top institute in India. Directly after my masters, I got a job but left it after exactly one year to pursue civil services. And that decision has left a 3 year void in my career sheet. During these three years, the most I have been in touch with tech/science was through random personal automations using python and digital notetaking systems or a few readings here and there. I don't know if they have anything to do with each other, but I am lazy (for repetitive work) and have an eye to optimize /automate my workflow. The later led to me learning python, a bit of git and css/html. With regard to my prgramming skills, I learn quickly and had good grades in all the computer science courses we had at the college (C++, DSA and Modelling-Simulation). I have also programmed in Matlab for basic usage in research and also in LAMDA for nanomechanics/molecular simulation. At my work, I had written a python code to automate the process of model setup for FE which reduced the human intervention from very menial routine work (hindi: gadha majdoori). As for my mechanical engineering skills, I am good with CAE softwares and can readily work with them. So first thing I am doing right now is applying in various positions in the same domain as I had worked 3 years ago. All this while, I got introduced to the world of Machine Learning, AI and Deep Learning. So, I wish to learn ML to slowly venture into that line. So yeah, my question here to the CS veterans is, how to start with the learning, from where, what can I expect from the field and how much time is necessary for be able to get a decent opportunity in that domain? Currently, I have started with Andrew Ng's course on Courcera: Course 1 of Deep Learning Specialisation. https://www.coursera.org/learn/neural-networks-deep-learning but it seems rather theoretical to me and without implementation it will be difficult for me to grasp (I feel). Also, I explored fast.ai course which follows top-down approach unlike Andrew. I haven't committed to it. Kindly guide. All kinds of opinon are welcome. PS. I am 28yo

[D] Here are 17 ways of making PyTorch training faster – what did I miss?

I've been collecting methods to accelerate training in PyTorch – here's what I've found so far. What did I miss? What did I get wrong? The methods – roughly sorted from largest to smallest expected speed-up – are: Consider using a different learning rate schedule. Use multiple workers and pinned memory in DataLoader. Max out the batch size. Use Automatic Mixed Precision (AMP). Consider using a different optimizer. Turn on cudNN benchmarking. Beware of frequently transferring data between CPUs and GPUs. Use gradient/activation checkpointing. Use gradient accumulation. Use DistributedDataParallel for multi-GPU training. Set gradients to None rather than 0. Use .as\_tensor rather than .tensor() Turn off debugging APIs if not needed. Use gradient clipping. Turn off bias before BatchNorm. Turn off gradient computation during validation. Use input and batch normalization. Consider using another learning rate schedule The learning rate (schedule) you choose has a large impact on the speed of convergence as well as the generalization performance of your model. Cyclical Learning Rates and the 1Cycle learning rate schedule are both methods introduced by Leslie N. Smith (here and here), and then popularised by fast.ai's Jeremy Howard and Sylvain Gugger (here and here). Essentially, the 1Cycle learning rate schedule looks something like this: ​ https://preview.redd.it/sc37u5knmxa61.png?width=476&format=png&auto=webp&s=09b309b4dbd67eedb4ab5f86e03e0e83d7b072d1 Sylvain writes: \[1cycle consists of\]  two steps of equal lengths, one going from a lower learning rate to a higher one than go back to the minimum. The maximum should be the value picked with the Learning Rate Finder, and the lower one can be ten times lower. Then, the length of this cycle should be slightly less than the total number of epochs, and, in the last part of training, we should allow the learning rate to decrease more than the minimum, by several orders of magnitude. In the best case this schedule achieves a massive speed-up – what Smith calls Superconvergence – as compared to conventional learning rate schedules. Using the 1Cycle policy he needs \~10x fewer training iterations of a ResNet-56 on ImageNet to match the performance of the original paper, for instance). The schedule seems to perform robustly well across common architectures and optimizers. PyTorch implements both of these methods torch.optim.lrscheduler.CyclicLR and torch.optim.lrscheduler.OneCycleLR, see the documentation. One drawback of these schedulers is that they introduce a number of additional hyperparameters. This post and this repo, offer a nice overview and implementation of how good hyper-parameters can be found including the Learning Rate Finder mentioned above. Why does this work? It doesn't seem entirely clear but one possible explanation might be that regularly increasing the learning rate helps to traverse saddle points in the loss landscape more quickly. Use multiple workers and pinned memory in DataLoader When using torch.utils.data.DataLoader, set numworkers > 0, rather than the default value of 0, and pinmemory=True, rather than the default value of False. Details of this are explained here. Szymon Micacz achieves a 2x speed-up for a single training epoch by using four workers and pinned memory. A rule of thumb that people are using to choose the number of workers is to set it to four times the number of available GPUs with both a larger and smaller number of workers leading to a slow down. Note that increasing num\_workerswill increase your CPU memory consumption. Max out the batch size This is a somewhat contentious point. Generally, however, it seems like using the largest batch size your GPU memory permits will accelerate your training (see NVIDIA's Szymon Migacz, for instance). Note that you will also have to adjust other hyperparameters, such as the learning rate, if you modify the batch size. A rule of thumb here is to double the learning rate as you double the batch size. OpenAI has a nice empirical paper on the number of convergence steps needed for different batch sizes. Daniel Huynh runs some experiments with different batch sizes (also using the 1Cycle policy discussed above) where he achieves a 4x speed-up by going from batch size 64 to 512. One of the downsides of using large batch sizes, however, is that they might lead to solutions that generalize worse than those trained with smaller batches. Use Automatic Mixed Precision (AMP) The release of PyTorch 1.6 included a native implementation of Automatic Mixed Precision training to PyTorch. The main idea here is that certain operations can be run faster and without a loss of accuracy at semi-precision (FP16) rather than in the single-precision (FP32) used elsewhere. AMP, then, automatically decide which operation should be executed in which format. This allows both for faster training and a smaller memory footprint. In the best case, the usage of AMP would look something like this: import torch Creates once at the beginning of training scaler = torch.cuda.amp.GradScaler() for data, label in data_iter: optimizer.zero_grad() Casts operations to mixed precision with torch.cuda.amp.autocast(): loss = model(data) Scales the loss, and calls backward() to create scaled gradients scaler.scale(loss).backward() Unscales gradients and calls or skips optimizer.step() scaler.step(optimizer) Updates the scale for next iteration scaler.update() Benchmarking a number of common language and vision models on NVIDIA V100 GPUs, Huang and colleagues find that using AMP over regular FP32 training yields roughly 2x – but upto 5.5x – training speed-ups. Currently, only CUDA ops can be autocast in this way. See the documentation here for more details on this and other limitations. u/SVPERBlA points out that you can squeeze out some additional performance (\~ 20%) from AMP on NVIDIA Tensor Core GPUs if you convert your tensors to the Channels Last memory format. Refer to this section in the NVIDIA docs for an explanation of the speedup and more about NCHW versus NHWC tensor formats. Consider using another optimizer AdamW is Adam with weight decay (rather than L2-regularization) which was popularized by fast.ai and is now available natively in PyTorch as torch.optim.AdamW. AdamW seems to consistently outperform Adam in terms of both the error achieved and the training time. See this excellent blog post on why using weight decay instead of L2-regularization makes a difference for Adam. Both Adam and AdamW work well with the 1Cycle policy described above. There are also a few not-yet-native optimizers that have received a lot of attention recently, most notably LARS (pip installable implementation) and LAMB. NVIDA's APEX implements fused versions of a number of common optimizers such as Adam. This implementation avoid a number of passes to and from GPU memory as compared to the PyTorch implementation of Adam, yielding speed-ups in the range of 5%. Turn on cudNN benchmarking If your model architecture remains fixed and your input size stays constant, setting torch.backends.cudnn.benchmark = True might be beneficial (docs). This enables the cudNN autotuner which will benchmark a number of different ways of computing convolutions in cudNN and then use the fastest method from then on. For a rough reference on the type of speed-up you can expect from this, Szymon Migacz achieves a speed-up of 70% on a forward pass for a convolution and a 27% speed-up for a forward + backward pass of the same convolution. One caveat here is that this autotuning might become very slow if you max out the batch size as mentioned above. Beware of frequently transferring data between CPUs and GPUs Beware of frequently transferring tensors from a GPU to a CPU using tensor.cpu() and vice versa using tensor.cuda() as these are relatively expensive. The same applies for .item() and .numpy() – use .detach() instead. If you are creating a new tensor, you can also directly assign it to your GPU using the keyword argument device=torch.device('cuda:0'). If you do need to transfer data, using .to(non_blocking=True), might be useful as long as you don't have any synchronization points after the transfer. If you really have to, you might want to give Santosh Gupta's SpeedTorch a try, although it doesn't seem entirely clear when this actually does/doesn't provide speed-ups. Use gradient/activation checkpointing Quoting directly from the documentation: Checkpointing works by trading compute for memory. Rather than storing all intermediate activations of the entire computation graph for computing backward, the checkpointed part does not save intermediate activations, and instead recomputes them in backward pass. It can be applied on any part of a model. Specifically, in the forward pass, function will run in torch.no\grad() manner, i.e., not storing the intermediate activations. Instead, the forward pass saves the inputs tuple and the functionparameter. In the backwards pass, the saved inputs and function is retrieved, and the forward pass is computed on function again, now tracking the intermediate activations, and then the gradients are calculated using these activation values. So while this will might slightly increase your run time for a given batch size, you'll significantly reduce your memory footprint. This in turn will allow you to further increase the batch size you're using allowing for better GPU utilization. While checkpointing is implemented natively as torch.utils.checkpoint(docs), it does seem to take some thought and effort to implement properly. Priya Goyal has a good tutorial demonstrating some of the key aspects of checkpointing. Use gradient accumulation Another approach to increasing the batch size is to accumulate gradients across multiple .backward() passes before calling optimizer.step(). Following a post by Hugging Face's Thomas Wolf, gradient accumulation can be implemented as follows: model.zero_grad() Reset gradients tensors for i, (inputs, labels) in enumerate(training_set): predictions = model(inputs) Forward pass loss = loss_function(predictions, labels) Compute loss function loss = loss / accumulation_steps Normalize our loss (if averaged) loss.backward() Backward pass if (i+1) % accumulation_steps == 0: Wait for several backward steps optimizer.step() Now we can do an optimizer step model.zero_grad() Reset gradients tensors if (i+1) % evaluation_steps == 0: Evaluate the model when we... evaluate_model() ...have no gradients accumulate This method was developed mainly to circumvent GPU memory limitations and I'm not entirely clear on the trade-off between having additional .backward() loops. This discussion on the fastai forum seems to suggest that it can in fact accelerate training, so it's probably worth a try. Use Distributed Data Parallel for multi-GPU training Methods to accelerate distributed training probably warrant their own post but one simple one is to use torch.nn.DistributedDataParallel rather than torch.nn.DataParallel. By doing so, each GPU will be driven by a dedicated CPU core avoiding the GIL issues of DataParallel. In general, I can strongly recommend reading the documentation on distributed training. Set gradients to None rather than 0 Use .zerograd(settonone=True) rather than .zerograd(). Doing so will let the memory allocator handle the gradients rather than actively setting them to 0. This will lead to yield a modest speed-up as they say in the documentation, so don't expect any miracles. Watch out, doing this is not side-effect free! Check the docs for the details on this. Use .as_tensor() rather than .tensor() torch.tensor() always copies data. If you have a numpy array that you want to convert, use torch.astensor() or torch.fromnumpy() to avoid copying the data. Turn on debugging tools only when actually needed PyTorch offers a number of useful debugging tools like the autograd.profiler, autograd.grad\check, and autograd.anomaly\detection. Make sure to use them to better understand when needed but to also turn them off when you don't need them as they will slow down your training. Use gradient clipping Originally used to avoid exploding gradients in RNNs, there is both some empirical evidence as well as some theoretical support that clipping gradients (roughly speaking: gradient = min(gradient, threshold)) accelerates convergence. Hugging Face's Transformer implementation is a really clean example of how to use gradient clipping as well as some of the other methods such as AMP mentioned in this post. In PyTorch this can be done using torch.nn.utils.clipgradnorm(documentation). It's not entirely clear to me which models benefit how much from gradient clipping but it seems to be robustly useful for RNNs, Transformer-based and ResNets architectures and a range of different optimizers. Turn off bias before BatchNorm This is a very simple one: turn off the bias of layers before BatchNormalization layers. For a 2-D convolutional layer, this can be done by setting the bias keyword to False: torch.nn.Conv2d(..., bias=False, ...).  (Here's a reminder why this makes sense.) You will save some parameters, I would however expect the speed-up of this to be relatively small as compared to some of the other methods mentioned here. Turn off gradient computation during validation This one is straightforward: set torch.no_grad() during validation. Use input and batch normalization You're probably already doing this but you might want to double-check: Are you normalizing your input? Are you using batch-normalization? And here's a reminder of why you probably should. Bonus tip from the comments: Use JIT to fuse point-wise operations. If you have adjacent point-wise operations you can use PyTorch JIT to combine them into one FusionGroup which can then be launched on a single kernel rather than multiple kernels as would have been done per default. You'll also save some memory reads and writes. Szymon Migacz shows how you can use the @torch.jit.script decorator to fuse the operations in a GELU, for instance: @torch.jit.script def fused_gelu(x): return x 0.5 (1.0 + torch.erf(x / 1.41421)) In this case, fusing the operations leads to a 5x speed-up for the execution of fused_gelu as compared to the unfused version. See also this post for an example of how Torchscript can be used to accelerate an RNN. Hat tip to u/Patient_Atmosphere45 for the suggestion. Sources and additional resources Many of the tips listed above come from Szymon Migacz' talk and post in the PyTorch docs. PyTorch Lightning's William Falcon has two interesting posts with tips to speed-up training. PyTorch Lightning does already take care of some of the points above per-default. Thomas Wolf at Hugging Face has a number of interesting articles on accelerating deep learning – with a particular focus on language models. The same goes for Sylvain Gugger and Jeremy Howard: they have many interesting posts in particular on learning rates and AdamW. Thanks to Ben Hahn, Kevin Klein and Robin Vaaler for their feedback on a draft of this post! I've also put all of the above into this blog post.

How-to-learn-Deep-Learning

Approach A practical, top-down approach, starting with high-level frameworks with a focus on Deep Learning. UPDATED VERSION: 👉 Check out my 60-page guide, No ML Degree, on how to land a machine learning job without a degree. Getting started [2 months] There are three main goals to get up to speed with deep learning: 1) Get familiar to the tools you will be working with, e.g. Python, the command line and Jupyter notebooks 2) Get used to the workflow, everything from finding the data to deploying a trained model 3) Building a deep learning mindset, an intuition for how deep learning models behave and how to improve them Spend a week on codecademy.com and learn the python syntax, command line and git. If you don't have any previous programming experience, it's good to spend a few months learning how to program. Otherwise, it's easy to become overwhelmed. Spend one to two weeks using Pandas and Scikit-learn on Kaggle problems using Jupyter Notebook on Colab, e.g. Titanic, House prices, and Iris. This gives you an overview of the machine learning mindset and workflow. Spend one month implementing models on cloud GPUs. Start with FastAI and PyTorch. The FastAI community is the go-to place for people wanting to apply deep learning and share the state of the art techniques. Once you have done this, you will know how to add value with ML. Portfolio [3 - 12 months] Think of your portfolio as evidence to a potential employer that you can provide value for them. When you are looking for your first job, there are four main roles you can apply for Machine Learning Engineering, Applied Machine Learning Researcher / Residencies, Machine Learning Research Scientist, and Software Engineering. A lot of the work related to machine learning is pure software engineering roles (category 4), e.g. scaling infrastructure, but that's out of scope for this article. It's easiest to get a foot in the door if you aim for Machine Learning Engineering roles. There are a magnitude more ML engineering roles compared to category 2 & 3 roles, they require little to no theory, and they are less competitive. Most employers prefer scaling and leveraging stable implementations, often ~1 year old, instead of allocating scarce resources to implement SOTA papers, which are often time-consuming and seldom work well in practice. Once you can cover your bills and have a few years of experience, you are in a better position to learn theory and advance to category 2 & 3 roles. This is especially true if you are self-taught, you often have an edge against an average university graduate. In general, graduates have weak practical skills and strong theory skills. Context You'll have a mix of 3 - 10 technical and non-technical people looking at your portfolio, regardless of their background, you want to spark the following reactions: the applicant has experience tackling our type of problems, the applicant's work is easy to understand and well organized, and the work was without a doubt 100% made by the applicant. Most ML learners end up with the same portfolio as everyone else. Portfolio items include things as MOOC participation, dog/cat classifiers, and implementations on toy datasets such as the titanic and iris datasets. They often indicate that you actively avoid real-world problem-solving, and prefer being in your comfort zone by copy-pasting from tutorials. These portfolio items often signal negative value instead of signaling that you are a high-quality candidate. A unique portfolio item implies that you have tackled a unique problem without a solution, and thus have to engage in the type of problem-solving an employee does daily. A good starting point is to look for portfolio ideas on active Kaggle competitions, and machine learning consulting projects, and demo versions of common production pipelines. Here's a Twitter thread on how to come up with portfolio ideas. Here are rough guidelines to self-assess the strength of your portfolio: Machine learning engineering: Even though ML engineering roles are the most strategic entry point, they are still highly competitive. In general, there are ~50 software engineering roles for every ML role. From the self-learners I know, 2/3 fail to get a foot in the door and end up taking software engineering roles instead. You are ready to look for a job when you have two high-quality projects that are well-documented, have unique datasets, and are relevant to a specific industry, say banking or insurance. Project Type | Base score | -------------| -----------| Common project | -1 p || Unique project | 10 p | Multiplier Type | Factor -----------------|----------------- Strong documentation | 5x 5000-word article | 5x Kaggle Medal | 10x Employer relevancy | 20x Hireable: 5,250 p Competative: 15,000 p Applied research / research assistant/ residencies: For most companies, the risk of pursuing cutting edge research is often too high, thus only the biggest companies tend to need this skillset. There are smaller research organizations that hire for these positions, but these positions tend to be poorly advertised and have a bias for people in their existing community. Many of these roles don't require a Ph.D., which makes them available to most people with a Bachelor's or Master's degrees, or self-learners with one year of focussed study. Given the status, scarcity, and requirements for these positions, they are the most competitive ML positions. Positions at well-known companies tend to get more than a thousand applicants per position. Daily, these roles require that you understand and can implement SOTA papers, thus that's what they will be looking for in your portfolio. Projects type | Base score --------------| ----------- Common project | -10 p Unique project | 1 p SOTA paper implementation | 20 p Multiplier type | Factor ----------------| --------------- Strong documentation | 5x 5000-word article | 5x SOTA performance | 5x Employer relevancy | 20x Hireable: 52,500 p Competitive: 150,000 p Research Scientist: Research scientist roles require a Ph.D. or equivalent experience. While the former category requires the ability to implement SOTA papers, this category requires you to come up with research ideas. The mainstream research community measure the quality of research ideas by their impact, here is a list of the venues and their impact. To have a competitive portfolio, you need two published papers in the top venues in an area that's relevant to your potential employer. Project type | Base score -------------| ---------------- Common project | -100 p An unpublished paper | 5 p ICML/ICLR/NeurIPS publication | 500p All other publications | 50 p Multiplier type | Factor ------------------| ------------------ First author paper | 10x Employer relevancy | 20x Hireable: 20,000 p Competitive roles and elite PhD positions: 200,000 p Examples: My first portfolio item (after 2 months of learning): Code | Write-up My second portfolio item (after 4 months of learning): Code | Write-up Dylan Djian's first portfolio item: Code | Write-up Dylan Djian's second portfolio item: Code | Write-up Reiichiro Nakano's first portfolio item: Code | Write-up Reiichiro Nakano's second portfolio item: Write-up Most recruiters will spend 10-20 seconds on each of your portfolio items. Unless they can understand the value in that time frame, the value of the project is close to zero. Thus, writing and documentation are key. Here's another thread on how to write about portfolio items. The last key point is relevancy. It's more fun to make a wide range of projects, but if you want to optimize for breaking into the industry, you want to do all projects in one niche, thus making your skillset super relevant for a specific pool of employers. Further Inspiration: FastAI student projects Stanford NLP student projects Stanford CNN student projects Theory 101 [4 months] Learning how to read papers is critical if you want to get into research, and a brilliant asset as an ML engineer. There are three key areas to feel comfortable reading papers: 1) Understanding the details of the most frequent algorithms, gradient descent, linear regression, and MLPs, etc 2) Learning how to translate the most frequent math notations into code 3) Learn the basics of algebra, calculus, statistics, and machine learning For the first week, spend it on 3Blue1Brown's Essence of linear algebra, the Essence of Calculus, and StatQuests' the Basics (of statistics) and Machine Learning. Use a spaced repetition app like Anki and memorize all the key concepts. Use images as much as possible, they are easier to memorize. Spend one month recoding the core concepts in python numpy, including least squares, gradient descent, linear regression, and a vanilla neural network. This will help you reduce a lot of cognitive load down the line. Learning that notations are compact logic and how to translate it into code will make you feel less anxious about the theory. I believe the best deep learning theory curriculum is the Deep Learning Book by Ian Goodfellow and Yoshua Bengio and Aaron Courville. I use it as a curriculum, and the use online courses and internet resources to learn the details about each concept. Spend three months on part 1 of the Deep learning book. Use lectures and videos to understand the concepts, Khan academy type exercises to master each concept, and Anki flashcards to remember them long-term. Key Books: Deep Learning Book by Ian Goodfellow and Yoshua Bengio and Aaron Courville. Deep Learning for Coders with fastai and PyTorch: AI Applications Without a PhD by Jeremy Howard and Sylvain. Gugger. Deep Learning with Python by François Chollet. Neural Networks and Deep Learning by Michael Nielsen. Grokking Deep Learning by Andrew W. Trask. Forums FastAI Keras Slack Distill Slack Pytorch Twitter Other good learning strategies: Emil Wallner S. Zayd Enam Catherine Olsson Greg Brockman V2 Greg Brockman V1 Andrew Ng Amid Fish Spinning Up by OpenAI Confession as an AI researcher YC Threads: One and Two If you have suggestions/questions create an issue or ping me on Twitter. UPDATED VERSION: 👉 Check out my 60-page guide, No ML Degree, on how to land a machine learning job without a degree. Language versions: Korean | English

Practical-Deep-Learning-For-Coders

Practical Deep Learning for Coders Material for my Proctor of Fast.AI's course. This course is originally done by Jeremy Howard and Rachel Thomas, and is taught at the University by course alumni. The course can be found here: https://course.fast.ai The Fast.AI forums can be found at: https://forums.fast.ai