-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Hi @javorszky !
I'm on a glorious quest to finally coerce someone into revisiting Day 02 Part B.
You wrote in your blog post:
Ho boy I was trying to be so clever, and ultimately the brute force solution worked.
The brute force only worked because each individual line contained very few numbers.
You should trust your original instinct: don't go through the breach
Let's say I bump the number count up a notch (6k numbers) in the input and exec time blows up:
Day 2 part 1: The number of safe reports is 0.
Day 2 part 2: The number of safe reports with the dampener is 0.
real 5m6.660s
user 0m0.030s
sys 0m0.186s
You were already on the complete right track when you wrote:
First I thought if I encounter a number that would cause the list to break the safety of the list,
I'll just set a fuse variable to blown, and if it does it again, then I'll mark the list as unsafe.
Can these sentences be rephrased a little bit to be:
- less about the 'how' ('I encounter a number that would cause the list to break')
- but more about the 'what' ('Definition: A safe list is a list such that ...')?
Maybe if we explicitly state first what we want to achieve, akkor implementációkor a definíció talán segíteni fog hogy ne tévedjünk el az if-ek között?
Maybe, maybe not, but imo it is worth a try!
Also, instead of solving the increasing/decreasing test in one go, why not just begin by doing one ordering at a time?
Keep it easy, cozy and relaxed. No need to rush.
Who knows... maybe we can learn some insights from the more simple subproblem?
Or... when the simpler is working fine, then maybe it will be transformable from (Boolean, AND, OR) to (Integer, min, max)?
bye,
rkeeves
P.S.: Sorry, feel free to close the issue if I'm being a nuisance. I just want to persuade someone into doing it, because the O(N) solutions are quite funny and entertaining.