peterarmitage

I got such a good reception from my post yesterday [0] on Go's range clause that I thought I'd hurry up and publish this article today.

This post is a lot more subjective - I personally think the algorithm is neat and elegant. If you agree I also recommend the paper as a good read.

I remember thinking about the Sieve when I first learnt programming, and being annoyed that I couldn't just let it generate all the primes without limit. Especially as running out of memory was an issue. I like the idea that I can come back and redo one of my earliest problems from a new angle.

[0] https://news.ycombinator.com/item?id=5924082

Sorry, I misread your comment, this isn't relevant.

This catches people out, and is something that some people on the Go team have expressed regret over - unfortunately it is too late to change due to backwards compatibility promises.

http://youtu.be/p9VUCp98ay4?t=22m18s

http://golang.org/doc/go1compat.html

Thank you.

"modify an object" means "change the number of elements", since you obviously want to be able to manipulate the individual elements of a container as you iterate over them. The object here is the container, not the elements themselves.

I can't comment on other languages, but I'd say that guideline is a little too strict for Go.

The classic implementation of Breadth First Search involves iterating over a queue as you fill it.

"don't modify the RHS while in a range clause" would be a more suitable guideline for Go. Note that it's subtley different from "iterating over" - indeed, the answer to my bug was to iterate without using the range clause:

    for i := 0; i < len(input); i++{
        if newValue := test(input); newValue != nil {
            input = append(input, newValue)
        }
    }

I now appreciate the difference between this and the range clause - the length is evaluated every iteration this way. The range clause evaluates it once, at the beginning - rule (1).

I wrote this after finding a bug in some of my code. Basically, I was iterating over a slice of inputs, processing each one. On occasion this processing would reveal new inputs to test, so I appended them to the slice.

    for i := range input {
        if newValue := test(input); newValue != nil {
            input = append(input, newValue)
        }
    }

Of course, this doesn't work, and I figured out (and appreciated) why by reading Go's spec.

Hopefully this brief guide will be of use to someone.

Thanks. I'm not a physicist, I was merely drawing pretty pictures based on real physicists' work. The examples in the paper are all planar (and have zero angular momentum), but it would be easy to simulate arbitrary orbits if any are published.

A few weeks ago some new solutions to the three-body problem were discovered: https://news.ycombinator.com/item?id=5347412

I made some simulations of them using three.js: http://www.funcmain.com/three_body_problem

Mine are pretty much the same kind of examples as those posted here, except specifically for the case N=3.