After data is collected for month 13, it can be used to predict through month 18
It means we can perform recursive forecasts. Using a huge context window is too hardware-resource-consuming. Probably, it is better to use a balanced approach of direct and recursive forecasts. I hope we will not face drastic error accumulation.
Scaling Scaling needs specialized tooling. It is currently not practical to use vanilla git with very large repos, or very large files, without any extra tooling. For monorepo scaling, teams invest in writing custom tooling and providing custom training. Scaling needs specialized coordination. It is currently not practical to use vanilla git with many projects across many repos, where a team wants to coordinate code changes, testing, packaging, and releasing. For polyrepo scaling, teams invest in writing coordination scripts and careful cross-version compatibility.
Might be roadblocker in case of very large teams. https://github.com/microsoft/rushstack
Coupling Tight coupling of projects. No coupling of projects. Thinking Encourages thinking about conjoins among projects. Encourages thinking about contracts between projects.
This is probably the most important difference between these two approaches.
DiD Study Group, organized by Taylor Wright
Causal Inference with Panel Data lecture series,
zt[1]
Mistake. It should be tt[1]
zt[1]
Mistake. It should be tt[1]
p∼Beta(61,41)p∼Beta(61,41)p \sim Beta(61, 41)
Good to know why we use N + 1 here?
не дающие формального доказательства, но обеспечивающие практическую применимость результата[⇨] — вероятностные, статистические, приближённые
Подобные методы используются в машинном обучение. Часто в последствии находят формальные доказательства.
This problem is called overfitting—it's like memorizing the answers instead of understanding how to solve a problem.
Simple and clear explanation of overfitting