Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Un-rip clever day 2 implementation #1

Open
rkeeves opened this issue Feb 11, 2025 · 2 comments
Open

Un-rip clever day 2 implementation #1

rkeeves opened this issue Feb 11, 2025 · 2 comments

Comments

@rkeeves
Copy link

rkeeves commented Feb 11, 2025

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)?

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.

@javorszky
Copy link
Owner

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!

@rkeeves
Copy link
Author

rkeeves commented Feb 12, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants