cgreerrun

Check out Quoridor

Short explainer for how the control of the SO-100 robot works.

Highly recommend LeRobot.

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.

Not sure how you are sourcing your jobs, but fyi you can get a feed of 1M+ jobs here too:

https://xmlfeed.directemployers.org/default

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.

Good luck!

The SO100 arm[1] and LeRobot[2] community are great too if you're getting into robotics from the software side of things.

Demonstration of the arm: https://x.com/ChrisMGreer/status/1867278261631561996

[1]https://github.com/TheRobotStudio/SO-ARM100

[2]https://github.com/huggingface/lerobot

You're welcome! I highly recommend the CPU/microchip one too.

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 video is a great explainer too:

How do Graphics Cards Work? Exploring GPU Architecture (https://youtu.be/h9Z4oGN89MU?si=EPPO0kny-gN0zLeC)

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!

You're welcome! If you're interested, there is a follow up paper about a method that extends GradTree to a boosted tree as well called GRANDE[1].

[1]https://arxiv.org/abs/2309.17130

You can use the straight through operator!

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.

[1] GradTree (https://arxiv.org/pdf/2305.03515.pdf) [2] GFlowNet (https://arxiv.org/abs/2111.09266)

Academics should write readable papers

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.).

[1] https://github.com/pybind/pybind11/blob/master/tests/test_py...

[2] https://gitlab.unistra.fr/benzerara/pybind11/-/tree/master/e...

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.

I came up with a nifty implementation in Python that outperforms the naive impl by 30x, allowing a pure python MCTS/NN interop implementation. See https://www.moderndescartes.com/essays/deep_dive_mcts/

Great post!

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.

[1] https://github.com/cgreer/alpha-zero-boosted

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.

Ah, interesting! So you can ensure you get illumination on the eyes w/out shining annoying, visible light at them. Very cool.

(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?

Maybe you could place 3-4 30-60FPS cheapish CMOS cams around the edge of the screen and stagger their frame captures? You'd get different angles (better for detecting eye vectors) and increase the sampling rate.

Looks like mice poll at around 125Hz. High bar.

I've been trying to flit my eyes around the screen to get a sense for how fast you'd need to track. Definitely seems pretty fast! At least sample 30Hz I'd bet. I could see how doing all the image processing that quick might be tricky w/out custom hardware (even w/out the glasses problem you mentioned).

For the UX, I was imagining you have to press a button to instruct the computer that "Hey I'd like for you to move my cursor via eye-tracking". That way the cursor only moves when you want it to (same as today w/ a mouse) and isn't constantly moving around when you look around. Press down to have it move cursor to eye-tracked position and stop when you release.

Could possibly decompose the space bar to have that space for that button. Like have 3 mouse buttons where the right side of space bar is: (a) Track my eye movement while I press down and stop when I release, (b) left-click, (c) right click. Then you don't have to leave home row on your keyboard.

Or add one of those IBM Thinkpad mouse knubs somewhere on a keyboard and use those as mouse buttons instead of a mouse itself.

Idk, easy to dream of course. Hard to execute.

I wonder why it's a hard problem? I'm sure it is, but it would be interesting to know the key issues if anyone here has experience with it.

It seems like w/ an image sensor you can track eye vectors and head location relative to screen w/ a degree of certainty. And—much like tracking a rocket position—you could use a Kalman/Particle Filter to get a screen position pretty close to wherever I'm looking on the screen. I'd guess within 3 characters.

Feels like the kind of thing Apple should invest in and revolutionize...

I wish eye-tracking hardware worked better. I feel like if it did it would be the ultimate "mouse".

I've seen a few products but, IIRC, the reviews all conclude that the tech isn't there yet.

Stereo Reconstruction

It's the algorithm(s) for how to compute a depth map when you have images from two cameras spaced some distance apart (for e.g., our eyes). It's gotten really good recently and it's fascinating on a technical level. Check out this YT video/playlist if interested: https://www.youtube.com/watch?v=6hr6xpOU-uw

Also, great question! Should do it every week.

Will it reduce the water available? I'm not sure either way. I've been imagining it like you're sucking the evaporated water out of the top of a half-full glass of covered water. The evaporated water is in equilibrium with the liquid water, and if you suck out evaporated water, then more liquid water evaporates. But that's just my dumb mental model.

I'm not aware of a consumer product. The authors of the paper started this company: https://www.infinite-cooling.com/. It looks like it's targeting industrial processes (cooling towers) where the collection efficiency is really high. Makes sense, why do B2C when you can do B2B w/ million dollar contracts...

I'm personally looking into making something that can continually top up something like a 500 gallon water tank every night (when humidity is high) on a residential property. These tanks are prevalent in the drought-stricken, coastal community I live in. You need about 2200 gallons/person/month, of which only 15 gallons/person/month is used for drinking water. So if you can continually collect water throughout the month and have the space for a tank (about the size of a truck bed) then it should be possible to supply most of your water usage off the grid and in a way that isn't draining reservoirs.

Collecting fog electrostatically is 2x more efficient than desalination. It works by ionizing the droplets in the air and collecting them on wire meshes: https://www.science.org/doi/10.1126/sciadv.aao5323. The technique also doesn't produce tons of salt waste that you have to dispose of.

It's a potential solution for towns/cities next to the ocean. Desalination is cheap enough already if we get desperate.

It won't be cost or technical feasibility that prevents us from solving the drought problem.

Maddness is their more recent work and yields 100x speedups: https://arxiv.org/pdf/2106.10860.pdf

The code for Maddness is in the same github repo if you search for "Mithral".

SIMD instructions can work wonders in the right context.