You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)?
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.
The text was updated successfully, but these errors were encountered:
Hi! No, this is awesome, thank you! I read what you wrote, but have no time to actually do it just yet, but I added this to my floating todo list that stares at me, unblinking, so when I have time, I'll sit down and actually take it in.
I appreciate this. Part of why I open sourced the code and wrote the narration the way I did was to foster / allow others to nudge me towards better solutions and hopefully others would find that useful too!
In my opinion, you were already right there with the 'fuse'.
Simply te was thrown off a különböző edge esetek miatt, which összekuszálta the solution és you were forced to átugrani due to határidő.
Another insanely hard thing imo, is that you have to both:
solve the problem,
I/O,
deal with statefulness,
babysit the borrow-checker,
check out-of-bounds and other nonsense,
pass type checks
at the same time.
I am personally insanely bad at multi-tasking, so... I wanted to find a general magic trick. A kind of software development snake oil, which actually works.
Imo the magic trick exists, but it requires a lot of practice, and I am still quite bad at it, but sometimes it kind of works.
The magic trick is described by an anecdote about a student in Chapter 4, page 35 in the Book of the Dead.
I still derp up a LOT (I am basically the student from the story 24/7), but at least this way, I might have some guard rail, or stepping stone I can fallback onto.
Sometimes the magic trick simply cannot even work. In those cases, we just have to compute Day 14 Part B.
Hi @javorszky !
I'm on a glorious quest to finally coerce someone into revisiting Day 02 Part B.
You wrote in your blog post:
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:
You were already on the complete right track when you wrote:
Can these sentences be rephrased a little bit to be:
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)?
Good luck!
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.
The text was updated successfully, but these errors were encountered: