Why not play a wonderful language known as INTERCAL (specifically the C-INTERCAL dialect)? You can learn to be more polite in your coding, the wonders of non-standard operators such as unary XOR and Mingle, and flow control via COME FROM.
Put "Advent of Code 2023 day 4" into your title at least. That what was i was searching for when I found your video, but it wasn't close to the top suggestions. Great content, keep it up!
When is assembly coming onto the wheel? Or maybe to make it cross platform it could even be LLVM IR. That should be fun to write with single static assignment.
Haskell is not nearly as bad as you think. It took me just a week to learn the syntax properly. I did take me however, 1.5 years to become comfortable programming in this functional style. Haskell shares many features of Rust, particularly the enums and pattern matching which is a huge part of FP. I do find F# to be a much more practical and enjoyable language to code in though.
Better to get the haskell done sooner rather than later, before the problems get really hard and you've gotta really implement a lot to solve the problem.
for part 2 I just had an array of integers, and I just incremented the index of the cards by the value for the current card, and in the end just summed them up. (I made sure that each card started at 1 instead of 0 by incrementing the current card by one at the start of the loop). O(n) solution.
I went down the same road as you for part 2 except I didn't have chat to reel me in and I got to the end of that recursive road. Saw some guys 5 line JavaScript solution afterwards and felt like a real dummy for creating such a "smart" answer.
I fell into the same recursion trap that you did with my solution. I even tried giving a tonne of memory and letting it run (that didn't work either! Don't hate, I'm a hardware engineer!) I ended up doing the same as you!
I did this at first too and got part of the way through the video before I saw your comment and it inspired me to rethink the recursive nature of my "surprisingly" slow recursive solution (was surprised because it was a naive algorithm, but computers are fast and it's Rust). It went from ~10s to 0.8ms haha
My algo for this question just used a lookup table to count how many copies of each card I had, rather than running the code multiple times you can just multiply how many subsequent copies of other cards you make. I also had an amazing off by one error that would cause my answer to balloon over the u128 max int limit for the full problem ;)
My original solution used a stack, evaluating every copy & the stack just GREW and GREW. Then i changed & looped from last game toward first & cached the # of cards produced by any given card, so then each card only got evaluated once. Later, i made stack work by looping over the games in the reverse order. That way the stack size never grew by more than a few, so all that memory work didn't slow it to a halt.
Why the fear for Haskell? IME it is a more elegant simple version of Rust. The big issue is that each function has to be a single expression but that is hardly an issue.
I can't wait for Haskell. The syntax really isn't that strange -- the weirdest part is the where and do. Once you learn haskell, it changes the way you think about code. Not just monads, but stuff like GADTs, DataKinds, and lenses.
I used a stack & added copied cards to it, and evaluated every card. Stack was GROWING and slowing. So i then went in reverse & cached solutions, so each card would only be evaluated once. So for card 37, i would have cached how many cards 38 & 39 produced, but I wouldn't know 36 yet.
Interesting, I actually ended up doing the recursive solution which wasn't that bad either. You do that same iteration over the vector at first for the original cards, then the copies you just check three conditions: if we run out of cards return 0, if we don't have any matching numbers return 1 (we have to add the current card), else we iterate over the slice from the current index + 1 to the number of matching numbers and recurse. Definitely not the fastest solution, but it was pretty interesting.
This is fp disease for ya! Gotta be complicated; gotta recurse; gotta wrap shit in monads; gotta bend over backwards for the OCaml nerds' rusted minds. Embrace the state, tame the state! Using for loops, structs, classes and AbstractFactoryProxyBuilders
i relate to this so hard. Whenever the problem is easy brain says do fp. But when things get hard, i slip back into imperative lol. Today i got the first part in pure fp. Second part was an abomination of both styles.
@@SVVV97 I mean I thought that since recursion is the natural solution to this problem, I would build up the number of cards from the bottom. Basically what came to my mind first when I saw this question
@@chongyihyang616 Oh fair point - I didn't consider that solution / it doesn't feel like the most natural one to me. But that still feels overkill to me: you can simply fold the cards down the stack in constant space and linear time.
Could you please make your videos longer? You cut away so much that I don’t understand where you’re at. At one point there was a cut and you had the whole recursive function
The haskell can't hurt you.
But it can make a copy of you that is hurt.
@@Pylo904🏆
@@Pylo904 🤣
Fail fast is a valid strategy 😉
@@Finkelfunk actually a monad is just a monoid in the category of endofuntor. What's the problem 😃
Why not play a wonderful language known as INTERCAL (specifically the C-INTERCAL dialect)? You can learn to be more polite in your coding, the wonders of non-standard operators such as unary XOR and Mingle, and flow control via COME FROM.
Yeah, since assembly is just easy this seems just about right
It'd be cool if you put some numeric label into the title of the video indicating which one comes first, something like "#1", "#2" and so on.
+1
don’t do that; that reduces how many new viewers will watch. a lot of people won’t click on the video if it’s a “part 4”
Are Day 1 to Day 4 new additions to the titles?
Put "Advent of Code 2023 day 4" into your title at least. That what was i was searching for when I found your video, but it wasn't close to the top suggestions. Great content, keep it up!
y'all realise he put day # in the title. It's at the end so most people don't see it, but it's there
When is assembly coming onto the wheel? Or maybe to make it cross platform it could even be LLVM IR. That should be fun to write with single static assignment.
Haskell is not nearly as bad as you think. It took me just a week to learn the syntax properly. I did take me however, 1.5 years to become comfortable programming in this functional style. Haskell shares many features of Rust, particularly the enums and pattern matching which is a huge part of FP. I do find F# to be a much more practical and enjoyable language to code in though.
Coding is cool and fun, but can we get more of the dog?
How do you know Santa is a Linux user? He has a lot of elfs.
Better to get the haskell done sooner rather than later, before the problems get really hard and you've gotta really implement a lot to solve the problem.
This series is the best. I’ve been doing my best to get through the challenges each day so far
for part 2 I just had an array of integers, and I just incremented the index of the cards by the value for the current card, and in the end just summed them up.
(I made sure that each card started at 1 instead of 0 by incrementing the current card by one at the start of the loop).
O(n) solution.
Cool, I came up with the same solution! Simple and elegant.
I went down the same road as you for part 2 except I didn't have chat to reel me in and I got to the end of that recursive road. Saw some guys 5 line JavaScript solution afterwards and felt like a real dummy for creating such a "smart" answer.
Did an iterative python solution today it took over ten seconds to finish running. Would be fun to see assembly on the wheel
I did an iterative solution for day 4 in Python and it runs in 0.00267 sec to calculate both answers. ASM would be fun.
10:11 Don't feel so bad. The Reddit thread is full of people still waiting for their recursive solutions to halt.
I fell into the same recursion trap that you did with my solution. I even tried giving a tonne of memory and letting it run (that didn't work either! Don't hate, I'm a hardware engineer!) I ended up doing the same as you!
I did this at first too and got part of the way through the video before I saw your comment and it inspired me to rethink the recursive nature of my "surprisingly" slow recursive solution (was surprised because it was a naive algorithm, but computers are fast and it's Rust). It went from ~10s to 0.8ms haha
My algo for this question just used a lookup table to count how many copies of each card I had, rather than running the code multiple times you can just multiply how many subsequent copies of other cards you make.
I also had an amazing off by one error that would cause my answer to balloon over the u128 max int limit for the full problem ;)
My original solution used a stack, evaluating every copy & the stack just GREW and GREW.
Then i changed & looped from last game toward first & cached the # of cards produced by any given card, so then each card only got evaluated once.
Later, i made stack work by looping over the games in the reverse order. That way the stack size never grew by more than a few, so all that memory work didn't slow it to a halt.
that's a classic dynamic programming solution, pretty cool
The elf in the story is probably a junior. Dude is doing everything by himself.
Why the fear for Haskell? IME it is a more elegant simple version of Rust. The big issue is that each function has to be a single expression but that is hardly an issue.
Chat please get AWK on the list tomorrow
I can't wait for Haskell. The syntax really isn't that strange -- the weirdest part is the where and do. Once you learn haskell, it changes the way you think about code. Not just monads, but stuff like GADTs, DataKinds, and lenses.
I used a stack & added copied cards to it, and evaluated every card. Stack was GROWING and slowing. So i then went in reverse & cached solutions, so each card would only be evaluated once.
So for card 37, i would have cached how many cards 38 & 39 produced, but I wouldn't know 36 yet.
Interesting, I actually ended up doing the recursive solution which wasn't that bad either. You do that same iteration over the vector at first for the original cards, then the copies you just check three conditions: if we run out of cards return 0, if we don't have any matching numbers return 1 (we have to add the current card), else we iterate over the slice from the current index + 1 to the number of matching numbers and recurse.
Definitely not the fastest solution, but it was pretty interesting.
Ye i also used a recursive solution and tbh im proud of it lol
The hardest part of this puzzle was by far figuring out what the hell was going on in part 2 😆
I wanna see C# on the wheel.
What the actual fuck. I was stuck on part 2 of this problem for well over an hour, and my solution took 58 seconds to run
When I did it myself and read the "Island Island" part I think my brain just gave up. So I had to take a quick break and re-read it.
Python came out today for me... I can say it was insanely easy
At these fast solution moments, abstract factory proxy instance and monadic endo-functorial category will all perish into def solve(): # just solve it
For every other challenge I felt like my code was disgusting, I quite enjoyed it!
yesterdays challenge was so much tougher than todays, today is actually free
Just a suggestion, could you cover embedded frame works like NASA VML and NASA F'Prime?
I did the recursive solution 💀. Not a fun time lol. Good practice though!
14 slots, 21 days, 78.7% of getting Haskel. That is, not considering the probably you fail again, and twitch gives you Haskel, again.
I wound up trying a recursive solution as well before realizing I made a huge mistake using recursion and it ran way too slow, lol.
Hey, having done AoC so far with C++ and seeing how beautifully concise Rust can be, are there any good resources for learning Rust?
I made the exact same mistake.. for some reason my brain said "yes, the union!" but indeed it is the intersection...
Got Uiua on day 4, it was, rather unique.
I literally fucking love these
someone please suggest smalltalk next!
Somebody put Assembly on the wheel if he fails again.
chill series, like it so far
Guys propmpt him to add Malbolge❤❤❤
me just throwing regex against day 4 (fix spacings & convert winning numbers to regex pattern)
Hi which IDE you are using?
Add prolog if you fail one
Why excel is not in the list?
Brain.exe stopped working for me when reading the instructions for part 2
Waiting for Prolog 😂
This is fp disease for ya! Gotta be complicated; gotta recurse; gotta wrap shit in monads; gotta bend over backwards for the OCaml nerds' rusted minds.
Embrace the state, tame the state! Using for loops, structs, classes and AbstractFactoryProxyBuilders
what is fp ?
@@aaronstark171 Functional Programming, which is not just programming with functions
i relate to this so hard. Whenever the problem is easy brain says do fp. But when things get hard, i slip back into imperative lol. Today i got the first part in pure fp. Second part was an abomination of both styles.
@@_tsu_ Both. Both is tov!
@@_tsu_ That's the beauty of a language that can do both, not an abomination. Pick and choose which is best suited for the task.
I'll just say, I followed through with the recursion stuff and it took like 5 full seconds to run :/
still got the right answer tho
Haha! You almost lanternfished yourself! XD
Use a dynamic programming table for part 2
What would you even DP here? It's a simple fold
@@SVVV97 I mean I thought that since recursion is the natural solution to this problem, I would build up the number of cards from the bottom. Basically what came to my mind first when I saw this question
@@chongyihyang616 Oh fair point - I didn't consider that solution / it doesn't feel like the most natural one to me. But that still feels overkill to me: you can simply fold the cards down the stack in constant space and linear time.
i did this in x86 asm, rust looks so easy lmao
where do you go to suggest Befunge-98 ( a 2D esoteric language that is not unusable )
Can someone please put Perl and Raku on the wheel?
FreeBASIC please!!!!
Speedrun timer, please!
Html + css next time bro its turing complete
5:23 Can someone explain wtf is wrong with his line numbers?
Why does it go from 10 to 0 then back to 10???
Relative line numbers. So it's quick to go up 7 lines or down 9 lines.
Haskell isn't that bad... you just have to rewire your brain first.
why do you use solarized
Why are you using rust again?
MEMOIZE!!!
Add brainfudge
int seems like a waste of memory for a 2 digit number 😮
Regex!
Has anyone requested Nix yet? 😏
Could you please make your videos longer? You cut away so much that I don’t understand where you’re at. At one point there was a cut and you had the whole recursive function
1157th
today was so much reading 🤢
Instead of doing random crap in 25 languages why do something meaningful in one?
It's advent of code. It's not about doing something 'useful'.
@@StevenMartinGuitar I agree, it’s a corporate gimmick and not useful at all all