this post was submitted on 13 Dec 2023
1 points (100.0% liked)

Advent Of Code

761 readers
2 users here now

An unofficial home for the advent of code community on programming.dev!

Advent of Code is an annual Advent calendar of small programming puzzles for a variety of skill sets and skill levels that can be solved in any programming language you like.

AoC 2023

Solution Threads

M T W T F S S
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25

Rules/Guidelines

Relevant Communities

Relevant Links

Credits

Icon base by Lorc under CC BY 3.0 with modifications to add a gradient

console.log('Hello World')

founded 1 year ago
MODERATORS
 

We all know and love (!) the leaderboard, but how about a different method?

One can solve a problem with a simple, naive method resulting in a short program and long runtime, or put in lots of explicit optimizations for more code and shorter runtime. (Or if you're really good, a short, fast program!)

I propose the line-second.

Take the number of lines in your program (eg, 42 lines) and the runtime (eg 0.096 seconds). Multiply these together to get a score of 4.032 line-seconds.

A smaller score is a shorter, faster program.

Similarly, (for a particular solver), a larger score is a "harder" problem.

top 3 comments
sorted by: hot top controversial new old
[–] CameronDev@programming.dev 2 points 10 months ago

Some of the challenges feasably could be solved with a pen and paper amd a keen eye, giving a line count of 0.

#nocode :D

[–] hades@lemm.ee 2 points 11 months ago

Lines of code can be arbitrarily reduced, and seconds to solve depends to a large extent on how good my hardware is. So both metrics are useless, and multiplying them makes a useless-squared metric.

I love it!

Here are my stats for the solutions so far (with no optimisation beyond the initial solution):

+-----+-----------+-------+---------------+
| Day | Time (s)  | Lines | line-seconds  |
+-----+-----------+-------+---------------+
|  1  |  0.003    |   35  |   0.098       |
|  2  |  0.001    |   47  |   0.042       |
|  3  |  0.006    |   60  |   0.348       |
|  4  |  0.003    |   41  |   0.115       |
|  5  |  0.077    |   74  |   5.708       |
|  6  |  0.000    |   45  |   0.001       |
|  7  |  0.005    |   87  |   0.395       |
|  8  | 10.175    |   60  | 610.476       |
|  9  |  0.004    |   31  |   0.128       |
| 10  |  0.084    |  103  |   8.634       |
| 11  |  0.240    |   49  |  11.771       |
| 12  |  2.448    |   93  | 227.633       |
| 13  |  0.009    |   83  |   0.707       |
+-----+-----------+-------+---------------+
[–] exocortex@discuss.tchncs.de 1 points 11 months ago* (last edited 11 months ago)
  1. I think a more consistent approach would he to not count lines, but filesizes after the code has been minimized with a specific minimizer. I could write everything in one line in many languages, so lines isn't very clever.

  2. The code has to be compiled and run on a specific architecture and with specific test input (we don't know if the AoC-example-data is always the same in size or resulting computanional complexity.

  3. The final metric could be: [minified filesize] * [code execution time] * [problem solving time].