[HN Gopher] Writing Snake in 12 Lines of PyTorch
___________________________________________________________________
Writing Snake in 12 Lines of PyTorch
Author : todsacerdoti
Score : 70 points
Date : 2022-08-11 15:03 UTC (7 hours ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| nsxwolf wrote:
| I used to be jealous of people that write big impressive things
| in tiny amounts of lines of code. But honestly, not anymore. I
| can't make heads or tails of it and I wouldn't want to try.
|
| If I wrote my own Snake, it would probably be like 500 lines and
| that's OK.
| Nydhal wrote:
| Good stuff. It would've been nice if there ever was an actual
| "Next Step" tensor that once multiplied (or some other operation)
| by any tensor representing current state, would give you the next
| state. That was my initial thinking when I read "Using Linear
| Algebra".
| eliasffyksen wrote:
| Are you asking for the Hamiltonian of the Snake world? I don't
| think it exists. The transformation is non-linear :P
| alberth wrote:
| Is writing X in Y lines of code having any real meaning? I'm not
| trying to be negative, just genuinely asking.
|
| For example, in _1-line-of-code_ I can write "hello world". This
| hello world is physically lighting up individual pixels on my
| display. It's rendering the letters to be the shape "hello world"
| should be. It has antialiasing applied. All in 1 line of code!!!
| eliasffyksen wrote:
| I wrote more for the fun of it than anything else. The
| challenge was just getting it as small as possible, just for
| the sake of it
| ratg13 wrote:
| https://en.wikipedia.org/wiki/Code_golf
| qsort wrote:
| It has some merit when you are comparing different solutions.
| For example (and I know people loathe python on here, I'm just
| using it for the sake of example, please bear with me), writing
| a simple web service in python takes fewer lines of code than
| doing the same in say, Rust.
|
| This doesn't imply that a language is better than another, it's
| just an objective fact one might find useful to keep in mind.
|
| The article's usage is admittedly clickbait, another recent
| article that popped up on the home page was titled something to
| the effect of "Speech Recognition in 100 lines of C++".
| Predictably, it turned out that they depend on a multi-million-
| line library.
| alberth wrote:
| But if you're importing in a library that might have 100,000
| LoC just so that you can say you "wrote X in 12 LoC" ... is
| that really a far representation?
| qsort wrote:
| Yes, that's my point. What these articles do is effectively
| to "hijack" that metric.
| eliasffyksen wrote:
| I'm glad someone liked it. r/programming didn't seem to enjoy it
| much :P
| sason wrote:
| It was an enjoyable and enlightening read. Now I'm thinking how
| I can rewrite my tile-based path-finding RL project to utilize
| more Tensors and less for loops.
|
| Well done! I'm looking forward to reading how you concurrently
| ran 100 million mini snake games.
| eliasffyksen wrote:
| Really cool. That's how this project got started. I was doing
| the exact thing you were doing (tile-based RL path finding).
| But it was soooo slow, so I started implementing it in
| tensors, and that's when I realized I could do a whole game
| of Snake.
| cullinap wrote:
| this is great
| orlp wrote:
| In a past codegolf contest you had to parse some input consisting
| of L, S, R for left, straight, right to follow a path.
|
| I used complex numbers and the fact that L, S, R respectively
| have ASCII codes 82, 83, 76 in the identities
| i^(82 + 1) = -i i^(83 + 1) = 1 i^(76 + 1) = i
|
| to get a very compact path reconstruction.
| tomstuart wrote:
| This is incredibly clever. In case anyone else is confused by
| the order: the ASCII codes for L, S, R are 76, 83, 82
| respectively, so L encodes i and R encodes -i as you'd expect.
| comma_at wrote:
| I'll wait for the 1-line APL/J/K implementation in the comments.
| Dzugaru wrote:
| Implementing certain things in PyTorch can be fun. I've recently
| started to make an economic game simulator (where you have
| players that can buy and sell items, do fighting etc.) and began
| to outline the design in the usual C#, but then, suddenly,
| thought - why not make the whole thing run on GPU and support
| millions of players with tens of millions sim steps per sec? This
| should make experiment cycles really fast - and that's what
| simulators are for!
|
| If you don't want to program CUDA kernels yourself, what's the
| easiest tool for the job? PyTorch, of course. Mutable by default
| tensors, lots of library operations and generally a pleasure to
| use.
|
| The programming is really interesting - you start to think in
| batches - every operation is a parallel operation, it's not 1
| player/item doing something, it's a whole lot of them at once -
| and that's really fast.
|
| I've eventually did run into some problems - for example,
| ragged/sparse tensors support is not designed for this at all,
| and since I have variable number of items per player - this is a
| problem. Also, producing something like logs inside tensors is
| challenging - reallocation is very expensive and must be done in
| batches too. There are some other interesting things like
| launching several operations / CUDA kernels at once.
| eliasffyksen wrote:
| Very cool. I would definitely like to see this in action!
___________________________________________________________________
(page generated 2022-08-11 23:01 UTC)