this post was submitted on 18 Dec 2024
17 points (94.7% liked)

Advent Of Code

1012 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 2024

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 2 years ago
MODERATORS
Ategon
[email protected]
CameronDev
17
Is it possible to not brute force day 7? (lemmy.ml)
submitted 2 months ago by [email protected] to c/advent_of_code
11 comments fedilink hide all child comments
 

I thought about it for 15 mins, but couldn't think of any mathematical tricks. I thought of lots of minor tricks, like comparing the number to the result and not adding any more multiplications if it's over, things that would cut 10%-20% here and there, but nothing which fundamentally changes big O running time.

For reference, here's my solution for part 2 in smalltalk. I just generated every possible permutation and tested it. Part 1 is similar, mainly I just used bit magic to avoid generating permutations.

(even if you haven't used it, smalltalk is fairly readable, everything is left to right, except in parens)

day7p2: in
	| input | 
	
	input := in lines collect: [ :l | (l splitOn: '\:|\s' asRegex) reject: #isEmpty thenCollect: #asInteger ].
	
	^ (input select: [ :line |
		(#(1 2 3) permutationsWithRepetitionsOfSize: line size - 2) 
			anySatisfy: [ :num | (self d7addmulcat: line ops: num) = (line at: 1)]
	]) sum: #first.

d7addmulcat: nums ops: ops
	| final |
	
	final := nums at: 2.
	ops withIndexDo: [ :op :i |
		op = 1 ifTrue: [ final := final * (nums at: i + 2) ].
		op = 2 ifTrue: [ final := final + (nums at: i + 2) ].
		op = 3 ifTrue: [ final := (final asString, (nums at: i+2) asString) asInteger ]
	].

	^ final
top 11 comments
sorted by: hot top controversial new old
[–] [email protected] 3 points 2 months ago* (last edited 2 months ago) (1 children)

I am not sure how much the formal complexity changes, but the pruning that occurs when working from right to left and bailing early when inverse multiplication or concatenation fails seriously cuts down on the number of combinations that you need to explore. With this pruning, the average fraction of the times (relative to the average 3^(n-1) / 2 times necessary for a naive brute force) that my code actually ended up checking whether the full inverted equation was equal to the target, was only 2.0% for equations that did not have solutions. Interestingly, the figure rose for equations that did have solutions to 6.6%.

[–] [email protected] 1 points 2 months ago (1 children)

How about the overall number of checks you did? String cat is heavy, but addition and multiplication are absurdly fast, probably faster than the branches needed for early escape.

[–] [email protected] 1 points 2 months ago* (last edited 2 months ago) (1 children)

Inverse concat isn't too heavy if you implement with logs and such. Certainly still heavier than integer add/mul (or sub/div in my case), but arithmetic is usually faster than memory allocation. However, predicting the performance hit due to branching a priori is tricky on modern hardware, which implements sophisticated branch prediction and speculative execution. Furthermore, branching happens anyway between terms to select the right operation, though a misprediction there is likely less significant unless you are doing string manipulation.

"Overall number of checks" is a bit ambiguous; if taken to mean the number of times I check against the target for early escape, plus the final check on success, the figure is 15% relative to the average 3^(n-1)^ / 2 checks required by brute force (n = number of terms in the equation, giving n-1 operators). That's still almost a 7-fold decrease. If we instead look at the number of operator evaluations relative to the (n-1)/2 * 3^(n-1)^ evaluations expected from an average brute force search (3^(n-1)^ / 2 combinations with (n-1) operations conducted per combination), the figure is only 7.0%. In both cases, there is a significant amount of work not being done.

[–] [email protected] 1 points 2 months ago (1 children)

Interesting. I'm doing naive string cat; it would probably be way faster with just math.

Now that I think about it more carefully, you can effectively prune whole trees of options with checking, especially for cat.

I wonder, did you get to benchmark both approaches?

[–] [email protected] 1 points 2 months ago

That pruning is indeed goal. As for benchmarking, I did not implement a brute force solution; I might try it if I finish one of the next few days quickly (lol fat chance). I did bench math vs string cat but did not record numbers. IIRC it made no measurable difference in Clojure, where input parsing with my crappy parser/combinator lib dominated, but math was something like a factor of three faster than string cat for Chez Scheme.

[–] [email protected] 3 points 2 months ago (2 children)

Probably the easiest optimization (which admittedly I didn't think of myself) is to work backwards: you can eliminate multiplication and concatenation early if you start with the answer and check terms from the right.

[–] [email protected] 1 points 2 months ago (1 children)

I don't entirely see how, you still need every possible combination of the left side to see what they would become. Plus addition and multiplication are order independent anyway

[–] [email protected] 1 points 2 months ago (1 children)

The point is to prune away search space as early as possible. If the rightmost operand is 5, say, and the answer ends in a 7, then the rightmost operator cannot be anything other than plus. This is a deduction you can't make going left to right. Remember that in this problem the usual order of operations does not apply.

[–] [email protected] 2 points 2 months ago (1 children)

I actually did this. It did not end up being any faster than the brute-force solution since it seems to only catch the easy cases

[–] [email protected] 1 points 2 months ago* (last edited 2 months ago)

Perhaps your implementation continues the search longer than necessary? I got curious and tried it myself. Runtime went from 0.599s (brute force) to 0.017s.

[–] [email protected] 1 points 1 week ago

Call it optimization and people will assume it is magic. Instead I call this a simple algebra challenge.(With part two having that quirky concatenation operation)

It is like solving for x. Let's take an example:

3267: 81 40 27

If you change it to equations:

81 (+ or *) 40 (+ or *) 27 = 3267
Which effectively is:
81 (+ or *) 40 = x (+ or *) 27 = 3267

So what is the x that either add or multiply would need to create 3267? Or solve for x for only two equations.
x + 27 = 3267 -> x = 3267 - 27 = 3240
x * 27 = 3267 -> x = 3267 / 27 = 121

(Special note since multiplying and adding will never make a float then a division that will have a remainder(or float) is impossible for x, we can easily remove multiplying as a possible choice)

Now with our example we go plug in x:
81 (+ or *) 40 = (3240 or 121) (+ or *) 27 = 3267

So now we see if either 40 or 81 can divide or subtract from x to get the other number. Since it is easier to just program to use the next number in the list, we will use 40.

81 + 40 = 3240 -> x = 3240 - 40 = 3200 != 81
81 * 40 = 3240 -> x = 3240 / 40 = 81
81 + 40 = 121 -> x = 121 - 40 = 81
81 * 40 = 121 -> x = 121 / 40 = 3.025 != 81

This particular example from the website has two solutions.

For the concatenation operation, you simply check if the number ends with the number in the list. If not then a concatenation cannot occur, and if true remove the number from the end and continue in the list.

Call it pruning tree paths but it is simply algebraic.