Live data from Hacker News

Adventures in Advent of Code

davedelong.com

51–60 of 71 posts

Re: Adventures in Advent of Code

#51
post #48
post #5

Earlier quoted context omitted.

What if you used a map and stored the value as a key? Then get all keys? Could work as a simple alternative and you could check if values are in it. Requires thinking if you want to implement set difference or intersection. I just figured depending on needs using existing built-in types may be fun.

Intersections are the reason you'd want a set, as the original post indicates. See the problem here: https://adventofcode.com/2022/day/3 (sets are even more of a fit for part 2, which is hidden for an anonymous viewer).

Sure, but intersections are straightforward to write with Go maps:

  for key, _ := range first {
      if _, found2 := second[key]; found2 {
        if _, found3 := third[key]; found3 {
          // This is the intersection of 3 sets
        }
      }
    }

Re: Adventures in Advent of Code

#52
post #48

Earlier quoted context omitted.

Intersections are the reason you'd want a set, as the original post indicates. See the problem here: https://adventofcode.com/2022/day/3 (sets are even more of a fit for part 2, which is hidden for an anonymous viewer).

Sure, but intersections are straightforward to write with Go maps: for key, _ := range first { if _, found2 := second[key]; found2 { if _, found3 := third[key]; found3 { // This is the intersection of 3 sets } } }

[deleted]

Re: Adventures in Advent of Code

#53

No I won't be participating in Advent of Code, and no, it is not one of the highlights of my holiday season. The highlights of my holiday season are stepping away from the keyboard and spending time with friends and family. The highlights of my holiday season do not include doing leetcode exercises, much as a I realize the need for leetcode exercises. So, no. I will not be participating in your Advent of Code.

Is this relevant to the post/discussion though?

Re: Adventures in Advent of Code

#54
post #20

Earlier quoted context omitted.

Turns out the fix is only on Ventura. I was also on Monterey. I updated the blog post to include this.

But that's my question. Similar to the other comment at https://news.ycombinator.com/item?id=33848354 , I have 5.7.1 on Monterey. 5.7 isn't restricted to Ventura. Is the problem that the fix in 5.7/5.7.1 didn't actually fix it?

The 5.7 compiler runs on Monterey, but the runtime is still 5.6, AIUI.

Re: Adventures in Advent of Code

#55
post #5

I picked go for my language this year, which doesn't have good support for sets. May end up writing my own buggy implementation of this.

What if you used a map and stored the value as a key? Then get all keys? Could work as a simple alternative and you could check if values are in it. Requires thinking if you want to implement set difference or intersection. I just figured depending on needs using existing built-in types may be fun.

That's pretty much how every one emulates them, with a `map[{TYPE}]struct{}` or possibly `map[{TYPE}]bool` if the space isn't a problem, and you find it easier to read (or if you want to be able to check for membership by indexing instead of using the comma ok idiom).

Re: Adventures in Advent of Code

#56

Having to update your entire OS to get bug fixes in a programming language is... not ideal.

It’s the way it works with libc too, right?

That depends on if you consider libc to be a part of the OS. Only the BSDs (including MacOS) do.

Re: Adventures in Advent of Code

#57
post #36

Related: It's possible to simplify things using bitmaps: https://github.com/antirez/adventofcode2022/blob/main/day-3/...

Hey, just noticed our impls. for Day 2 look very similar. If you’re curious, Day 2 can be further improved by using modulo + 2 (or 1 if compiler is smart enough) branches instead of lookup table: https://github.com/neon-sunset/AOC2022/blob/main/Day2/Progra...

Re: Adventures in Advent of Code

#58

When your code fails it's never the fault of the language. It's always ones own fault, a typo, some error in the logic, or something. Debugging always reveals that with a stone face. Always. Except > "It turns out, there was a bug in Set.intersection(_:), but it had only been discovered this past June, and the fix hasn’t made it into a public version of Swift yet. "

(Hi, I'm the author of the post) It turns out the bug fix has been released publicly, but only on newer OS versions.

Or if you compile in release mode, in which case the fixed version is (maybe only sometimes?) inlined into your executable.

I ran into the same bug, but since I'd included a `precondition` to verify that each elf-group had only one common item type, I discovered the bug immediately. I then needed about 5-10 minutes to convince myself that it really was a Swift bug and not a mayoff bug.

Re: Adventures in Advent of Code

#59

No I won't be participating in Advent of Code, and no, it is not one of the highlights of my holiday season. The highlights of my holiday season are stepping away from the keyboard and spending time with friends and family. The highlights of my holiday season do not include doing leetcode exercises, much as a I realize the need for leetcode exercises. So, no. I will not be participating in your Advent of Code.

Me neither, though it's a great exercise for learning a new language. I'm planning to do it in Haskell some time next year, but certainly not now, as the end-of-year period is already stressful enough.

Re: Adventures in Advent of Code

#60
post #21

Earlier quoted context omitted.

As someone who worked on C compilers for DSPs for a few years, I was conditioned for a while to think "compilers are broken, libraries are broken - you have no hope" for a while, when all I dealt with was our software. Obviously that's heavily influenced by what I was actually dealing with day to day and not by normal software development, but still :) One of the guys in my team handled a frantic support request from…

From your description of the bug, I think even know which compiler you worked on. I worked on a competitors compiler. The state of embedded tools in the lates 90s and early 2000s was deplorable. I'm surprised we got anything working. (I went to work for the compiler team because I was so pissed off at how poorly they worked.)

I should maybe have just said, it's not like it's sensitive information. It was @ Analog Devices, and given the engineer who was assigned to this bug I think it would have been for their TigerSHARC DSP. Trying to think who you might have worked for - Green Hills maybe?

The compiler itself felt well-written and there were some very smart people involved in developing it. And now that I think about it the bug wasn't different code being output but some value elsewhere in the generated binary itself - maybe some ELF header? I wish I could remember

Post reply on HN