bin/
...all personal bash scripts can be found here...
documents/
audiobooks/
backups/
books/
personal/
projects/
videos/
work/
downloads/
hosts/
...sshfs to all important folders on several servers, no sync...
images/
music/
share/
...for locally installed software, no sync...
temp/
...remove all files in this folder once a month, no sync...
I (r)sync these folders with all my computers once every day. I have used this structure for the last 15 years. Therefore, I know by heart where to find what. Perhaps I could move the downloads folder into my temp folder. I don't know why I don't.
I take an approach a lot like this - brief straightforward lowercase names e.g.
books/
periodicals/
films/
television/
That's the root directory.
Now for subfolders I keep a numerical scheme e.g.
films/000_action
films/000_docudrama
books/000_science/000_biology
So the 000_ prefix indicates a major class - fits well with a "grep" or to sort by name in a file browser gui both.
Then from that I can add suffixes such as
001_90s_cartoons_megaset
to signify this is a massive multi-terabyte wallop of interest
The upside of this approach is structure. The downside is that if one is building a good characterization of these things you soon realize a tag-based system might be better - the filesystem forces a tree structure. If these were managed by a database/indexing system, then presumably the tags would live there (not the filesystem) and the filesystem could merely be some sort of balanced tree that maximizes performance, filenames may as well be random 64 character IDs. This approach then requires some effort to organize into the tree (much effort over decades) for some structure to "bleed through" to the filesystem. But at this scale to really manage it, it's scripts and automation and indexes all the way.
The other hard part of it is maintenance and adding new data since data tends to grow exponentially. Still manual, could be automated if I was hardcore about it. One can also build search indexes but I personally tend to do every few months a simple "find | gzip -9 > listing.txt.gz" and then grep that for fast search in the future. There are faster ways to do this algorithmically surely, but this is perhaps the fastest way as far as minimizing the amount of time & effort I put in with a good payoff ratio for "just working"
I had exactly the same feeling when reading this blog. Sure, the techniques used to find the solutions are really interesting. But the claim more than they achieve. The problem statements are not available in Lean, and the time limit is 2 x 4.5 hours. Not 3 days.
The article claims they have another model that can work without formal languages, and that it looks very promising. But they don't mention how well that model performed. Would that model also perform at silver medal level?
Also note, that if the problems are provided in a formal language, you can always find the solution in finite amount of time (provided the solution exists). You can brute-force over all possible solutions until you find the solution that proofs the statement. This may take a very long time, but it will find the solutions eventually. You will always solve all the problems and win the IMO at gold medal level. Alphaproof seems to do something similar, but takes smarter decisions which possible solutions to try and which once to skip. What would be the reason they don't achieve gold?
Not only did these techniques save me money, but they also saved me a considerable amount of time. I've employed these same strategies at work and private to navigate away from requests and projects in which I have no interest.
I 100% do exactly the same. I gave up following what's new in Artificial Intelligence (Machine Learning?) years ago. 99% of it is distraction, and not worth my time to find that last 1% of useful information. Instead, I focus on improving my foundations: statistical inference, linear algebra, calculus, classical machine learning (e.g., regression, boosting, component analysis, ...), programming, domain knowledge, social skills, ... I only learn a new technique if I cannot solve it with my usual toolbox (which is not very often).
I'm way more productive, have to work less hard, and I'm not distracted. Sure, I don't do that fancy new thing, but at the end of the day (or earlier) I get the job done. And I'm judged on what I do, and how it brings money into the company, not how I do it.
Another benefit working mostly with a box of boring, old tools, is that it will likely still be relevant in the next 30 years. You never know how long that new popular thing will remain popular and useful. But I'm pretty sure we'll still fit datasets with linear/logistic regressions, optimize processes with linear programming, or do straightforward A/B testing for the next few decades (if not centuries or millennia).
I used this library very often when writing a new paper. When the paper was a draft I would put coffee stains on the pages. In this way, I always knew if I was looking at a draft or the final version.
