[bugfix-66]

Go is very close to C.

A C programmer who understands a for loop should be able to fix this, despite the fact it's Go:

  // We are generating n-1, n-2, ..., 1, 0

  func below(n uint64, to chan uint64) {
      for n--; n >= 0; n-- {
          to <- n
      }
      close(to)
  }

Maybe you're right: It could be that C programmers don't understand Go syntax and Go programmers tend to be less experienced.

[dekhn]

EDIT: the version I pasted below is not what I originally typed into the site. I made several errors while copy/pasting and modifying the code to run locally without a channel.

It told me I have an error ("what happens at zero") when i do:

  func below(n uint64, to chan uint64) {
        for n; n > 0; n-- {
            to <- n-1
            n--
        }
        close(to)
    }

but running that function with several test inputs produces what I expected. Note, I removed the channel (replaced with println) as that doesn't add anything to the problem.

Note: I've been programming (including C and C++) for 3+ decades. I make mistakes all the time, but.... what exactly are you looking for here if my solution is not ruight?

EDIT: the pasted code is also incorrect, because I didn't complete converting the for loop into a while.

[Jtsummers]

Why did you choose to decrement n twice on each iteration? What happens when n is odd vs even now?

[dekhn]

Oh, sorry, I didn't paste the right code.

On my machine I used this code:

  package main
  import "fmt"
  func below(n uint64 ) {
      for n>0 {
      fmt.Println(n-1)
          n--
      }
  }


  func main() {
      below(10);
      below(0);
  }

The actual code I put into the bugfix site was:

  func below(n uint64, to chan uint64) {
          for n>0 {
              to <- n-1
              n--
          }
          close(to)
      }

but when writing this comment I went back and didn't modify the for loop to be a while.

[bugfix-66]

The above code is correct, and of course it is accepted.

[dekhn]

Why does it say "What happens at 0" when you omit the decrement?

[bugfix-66]

When your code is wrong, the server gives you a clue hinting at what's wrong in the original code.

It doesn't know what's wrong in the code you submitted... it is not understanding deeply what's wrong with your code. It's not some huge multi-terabyte language model analyzing arbitrary code, or whatever.

It just knows your code is wrong and gives you a clue so you can try again.

[all2]

I also came to a solution very similar to the sibling comment here. I'd love to see why this doesn't work server-side but does work on my machine. What other tests are you running aside from checking each decrement is correct?

[bugfix-66]

Show me your code, that you think is correct, and the server rejects.

I'll tell you what's wrong with your code.

[all2]

Might I recommend appropriate debugging output? It would save the mystery and back and forth. Not everyone who uses your site has access to you on HN. :)

    func below(n uint64, to chan uint64) {
        for ; n >= 0; n-- {
            var t = n - 1
            to <- n
        }
        close(to)
    }

I've run this locally with to <- n replaced with a print statement and it works with unsigned integers.

[Jtsummers]

Did you make other changes besides `to <- n` becoming print? Because as it stands, that will still produce an infinite loop.

[all2]

I don't program C or Go. I ran the logic and it works; I verified by running a modified version of this method on my computer.

    func below(n int) {
        for n--; n >= 0; n-- {
            fmt.Println(n)
        }
    }

I modified the type so I could punch in some sane integer, like 4. And this works.

    C:\git\bugfix66> go run .\bugfix66-2.go
    3
    2
    1
    0

Am I to assume that the bug is actually a type issue? Something to do with unsigned integers?

Wait. Oh. Ok. I get it. It does have to do with the type signature.

[dekhn]

What happens if you start at n=0 for uint64?

(my real comment after I get some clarification from the bugfix site author is that I never, ever modify a variable in the initialization condition of a for loop, and i see that in the wild, I elide it.

[bugfix-66]

You're using a signed integer.

[bee_rider]

While it is of course possible for people from other languages to do your puzzles, I'd expect most of the players to be Go programmers.