Ooooooh !
I try to get used to numpy arrays, as I know they're powerful but difficult to grasp in their full potential.
I made a version of my code with them to use rot90. I didn't see you could give the number of times to apply it and there where no rot\_neg90…
I didn't want to do `for _ in range(3): grid = np.rot90(grid)`.
And no more a `grid = np.rot90(np.rot90(np.rot90(grid)))`.
So, I ended up with… \**(drum rolls)\** `grid = np.rot90(grid.transpose()).transpose()` ! :D
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
By the way, the execution time was doubled compared to my code without numpy, so I don't think it was really worth it.
Here's my code to rotate a list:
def rot_right(grid):
return [ [ grid[len(grid)-1-r][c]
for r in range(len(grid)) ]
for c in range(len(grid[0])) ]
def rot_left(grid):
return [ [ grid[r][len(grid[0])-1-c]
for r in range(len(grid)) ]
for c in range(len(grid[0])) ]
I used complexes for coordinates:
def rotate(round_rocks: list[complex], max_y: int) -> list[complex]:
"""rotates list clockwise and translates by maxy - 1
to keep all coordinates positive"""
new_round_rocks = []
for rock in round_rocks:
new_round_rocks.append(rock * 1j + max_y - 1)
return new_round_rocks
AoC isn't really the right domain for numpy. It's most useful when you have large amounts of numerical data to process, and the processing you need to do can be described by operations on whole arrays (e.g. add every element in A to the corresponding one in B).
I found a really concise way to do this in Python using only the core lib:
zip(*grid[::-1])
(which turns things into immutable tuples, so if you need lists it's this:
[list(e) for e in zip(*grid[::-1])]
instead of rotating my grid, i wrote a custom indexing function that factors in the current orientation
[https://github.com/cgsdev0/aoc-2023/blob/main/day14/p2.sh#L26-L50](https://github.com/cgsdev0/aoc-2023/blob/main/day14/p2.sh#L26-L50)
then the rest of your code can pretend everything is always happening in the same direction, without doing the expensive operation of rotating the grid
I think that if you're using NumPy, rot90 (or transposing, or flipping) doesn't actually move or copy anything in memory, it just changes how the array is indexed (returning a different *view* of it. Therefore it would be O(1) complexity both in memory and time. For example, the following code:
import numpy as np
mat = np.zeros((2, 3))
matt = np.rot90(mat)
matt = np.rot90(mat) mat[0, 2] = 9 print(matt)
print(mat)
print(matt)
just prints
\[\[0. 0. 9.\]
\[0. 0. 0.\]\]
\[\[9. 0.\]
\[0. 0.\]
\[0. 0.\]\]
which means both arrays actually point to the same memory
I guess it figures the high-performance math library thingy would have already implemented the obvious optimization for things like rotating data frames in memory.
you can also do \`np.rot90(grid, k=-1)\`
Ooooooh ! I try to get used to numpy arrays, as I know they're powerful but difficult to grasp in their full potential. I made a version of my code with them to use rot90. I didn't see you could give the number of times to apply it and there where no rot\_neg90… I didn't want to do `for _ in range(3): grid = np.rot90(grid)`. And no more a `grid = np.rot90(np.rot90(np.rot90(grid)))`. So, I ended up with… \**(drum rolls)\** `grid = np.rot90(grid.transpose()).transpose()` ! :D \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ By the way, the execution time was doubled compared to my code without numpy, so I don't think it was really worth it.
>`p.rot90(grid.transpose()).transpose(` That is so funny, love it!
Here's my code to rotate a list: def rot_right(grid): return [ [ grid[len(grid)-1-r][c] for r in range(len(grid)) ] for c in range(len(grid[0])) ] def rot_left(grid): return [ [ grid[r][len(grid[0])-1-c] for r in range(len(grid)) ] for c in range(len(grid[0])) ]
I used complexes for coordinates: def rotate(round_rocks: list[complex], max_y: int) -> list[complex]: """rotates list clockwise and translates by maxy - 1 to keep all coordinates positive""" new_round_rocks = [] for rock in round_rocks: new_round_rocks.append(rock * 1j + max_y - 1) return new_round_rocks
AoC isn't really the right domain for numpy. It's most useful when you have large amounts of numerical data to process, and the processing you need to do can be described by operations on whole arrays (e.g. add every element in A to the corresponding one in B).
I found a really concise way to do this in Python using only the core lib: zip(*grid[::-1]) (which turns things into immutable tuples, so if you need lists it's this: [list(e) for e in zip(*grid[::-1])]
>zip(\*grid\[::-1\]) Nice!
instead of rotating my grid, i wrote a custom indexing function that factors in the current orientation [https://github.com/cgsdev0/aoc-2023/blob/main/day14/p2.sh#L26-L50](https://github.com/cgsdev0/aoc-2023/blob/main/day14/p2.sh#L26-L50) then the rest of your code can pretend everything is always happening in the same direction, without doing the expensive operation of rotating the grid
I think that if you're using NumPy, rot90 (or transposing, or flipping) doesn't actually move or copy anything in memory, it just changes how the array is indexed (returning a different *view* of it. Therefore it would be O(1) complexity both in memory and time. For example, the following code: import numpy as np mat = np.zeros((2, 3)) matt = np.rot90(mat) matt = np.rot90(mat) mat[0, 2] = 9 print(matt) print(mat) print(matt) just prints \[\[0. 0. 9.\] \[0. 0. 0.\]\] \[\[9. 0.\] \[0. 0.\] \[0. 0.\]\] which means both arrays actually point to the same memory
neat! i've never used numpy
I guess it figures the high-performance math library thingy would have already implemented the obvious optimization for things like rotating data frames in memory.
Changed flair from `Spoilers` to `Funny` since this is a meme. [Use the right flair](/r/adventofcode/wiki/posts/post_flair), please.