> The code is a mixture of C++ for performance-critical parts and Python for everything else. They’re glued together using pybind11, which I’m a big fan of.
Nice, I'm a big fan of this combo! Hits the right balance of prototype speed plus performance.
Some of the players (ZipRecruiter, etc) might also give you a feed. They generally just want traffic.
I used to work on the ML system that rated resumes when the applications were submitted. The ATSes are scoring and sorting the applications that come in, so IMO it's better if everyone "applies" and their matching program runs instead of waiting for people to apply anyways.
The only time I really feel like I understand something is by building something with it. So actually writing a CUDA kernel to do grayscale conversion and then tweaking the code.
BUT... both the video and the article are useful before you do that. They both allow you to build a mental model of how GPUs work that you can test later on.
This is incredible. I have a biochemistry and bioinformatics background, and I've always been curious about how easy and cheap it could be to do various experiments at home. Godspeed!
During the forward pass you sample a discrete outcome given your NN weights to get an error for backprop. During the backward pass you directly propogate through the weights.
This GradTree paper[1] does a good job covering how to do discrete gradient-based optimization (i.e. NNs w/ discrete representations).
Another option is to use a GFlowNet[2]. Then you have a NN policy that takes discrete actions like you're playing an RL game. You're not back-propogating through something that isn't continuous, but you're utilizing a NN to make informed decisions about a problem with a discrete representation.
If you've never used Pybind before these pybind tests[1] and this repo[2] have good examples you can crib to get started (in addition to the docs). Once you handle passing/returning/creating the main data types (list, tuple, dict, set, numpy array) the first time, then it's mostly smooth sailing.
Pybind offers a lot of functionality, but core "good parts" I've found useful are (a) use a numpy array in Python and pass it to a C++ method to work on, (b) pass your python data structure to pybind and then do work on it in C++ (some copy overhead), and (c) Make a class/struct in C++ and expose it to Python (so no copying overhead and you can create nice cache-aware structs, etc.).
> I do not recommend anyone use python for anything performance sensitive
My default philosophy is to use python _until_ you find something that is performance sensitive, and then make a C/C++ extension for the slow bits. Pybind works great for a hybrid Python/C++ codebase (https://pybind11.readthedocs.io/en/stable/).
Then you can develop and prototype much quicker w/ Python but re-write the slow parts in C++.
Definitely more of a judgement call when threading and function call overhead enter the equation, but I've found this hybrid "99% of the time Python, 1% C++ when needed" setup works great. And it's typically easier for me to eventually port mature code to C++/Go/etc once I've fleshed it out in Python and hit all the design snags.
Depends on game/environment and—since it's using a GBDT and not a NN—how good you are at feature extraction/selection for your problem.
High level, I'd say it's a good way to test a new environment w/out spending time/effort on GPUs until you understand the problem well, and then you can switch to the time/money costly GPU world.
Chasing pointers in the MCTS tree is definitely a slow approach. Although typically there are ~ 900 "considerations" per move for alphazero. I've found getting value/policy predictions from a neural network (or GBDT[1]) for the node expansions during those considerations is at least an order of magnitude slower than the MCTS tree-hopping logic.
In this comment thread, for e.g., you can have your eyes target the [+] or [-] icons, and then click to expand/collapse those. If you had the "eye-track button" you move you eye to [+], tap button, and left click.
The main use case for me is jumping cursor close to some position while text editing. I'm a Vimmer and I typically just want to look somewhere and instantly move my cursor to where I'm looking sometimes. Easymotion style jumping is nice (I use it in fzf menus, for instance). But there's still that slight mental overhead of figuring out what I gotta type in to jump. Or if I use a mouse then I take hands off keyboard, move mouse, hands back on keyboard. Which sounds pretty simple but it's so slow compared to just jumping around in vim w/ hands always on keyboard.
(Can't reply to your other comment for some reason)
Why is the IR part of the spectrum better for the cameras? Is it because if I take an image of my eye and look at the IR part of the spectrum is it just easier to see parts of my eye that determine where it's looking?