[bee_rider]

Well, it tells us about the Go programmers on the forum. One possibility is that as Go has become more mainstream, Go programmers have become less competent on average.

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

[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.

[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.