Since this is the comment thread talking about the algorithm I'm gonna add my 2 cents here:
Here's the problem statement as far as I see it:
Each tile has a number of move points to spend to go through it (1 for regular and 2 for water). Each tile also has a cost associated with it. Given a max number of move points find the lowest cost path between two tiles or return none if no such path exists.
I'm gonna say this is still modified dijkstra with a small twist. The fire has cost 1, the other tiles have cost 0. However instead of pathing on a 2d grid (x, y) we path on a 3d grid (x, y, moves). All "goal" tiles within (goal_x, goal_y, moves < total_move_points) have a 0 cost edge which brings them to the true goal node. The implementation difference is that the get neighbors function queries neighbors in later grid layers (x+..., y+..., moves + 1 or 2)
Wow some of these comments seem harsh. The author isn't claiming to have invented these techniques and it's cool to see them being applied in the "real world" to save money.
Agreed. Fine-tuning GPT-3 is often called out as expensive and sometimes unnecessary given K-shot & embeddings. I'm glad they shared their success story even if it's not ground-breaking.
Thanks - we used to use a bunch of k-shot prompts (particularly with our previous idea before we pivoted when we got into YC), but with the davinci model we were sending ~3.5k tokens per invocation, which in the long term was costing far more than finetuning!
I would guess combining pieces of two images is a simple place where the graph could become non linear. Agree that if that is the case they should indicate it in their gifs tho
From friends I've had who have made the jump, learn a game engine (unity / unreal / etc), make some small games (can be for a game jam or whatever) to put on a portfolio and mass apply to lots of different companies of many sizes. You may have to take a job title hit (i.e going from senior -> junior) / large pay cut.
Neat post! I'd be curious to see some simple examples of each what the slow queries looked like. It seems to my limited knowledge they attempted to use row based dbs / mongo for column based workloads then saw a large perf boost after switching to Clickhouse.
That's exactly right! As I explained in the post, we made a big tradeoff to get things started at the beginning, which was using mongo to handle large analytics workloads. It's been a year since I wrote this post but we've had a lot of success improving query performance within ClickHouse as well. Will write about that soon :)
Generally I find that shallowly learning topics adjacent to the areas I know deeply works best but trying to glean the idea of topics way outside of my understanding (i.e quantum physics) does not end well for me.
Always great to see "don't write a shader language" on someone's new years list. Wishing Raph the best in 2023, I've learned more about curves and gpus from his blog then anywhere else
Here's the problem statement as far as I see it: Each tile has a number of move points to spend to go through it (1 for regular and 2 for water). Each tile also has a cost associated with it. Given a max number of move points find the lowest cost path between two tiles or return none if no such path exists.
I'm gonna say this is still modified dijkstra with a small twist. The fire has cost 1, the other tiles have cost 0. However instead of pathing on a 2d grid (x, y) we path on a 3d grid (x, y, moves). All "goal" tiles within (goal_x, goal_y, moves < total_move_points) have a 0 cost edge which brings them to the true goal node. The implementation difference is that the get neighbors function queries neighbors in later grid layers (x+..., y+..., moves + 1 or 2)