Progressively distributed RGB colors.

    public int getColor(int index) {
        int[] p = getPattern(index,0);
        return getElement(p[0]) << 16 | getElement(p[1]) << 8 | getElement(p[2]);
    }

Fetching routine.

    public int getElement(int index) {
        int value = index - 1;
        int v = 0;
        for (int i = 0; i < 8; i++) {
                v = v | (value & 1);
                v <<= 1;
                value >>= 1;
        }
        v>>=1;
        return v & 0xFF;
    }

    It turns out to make numbers that go 255, 0, 128, 192, 64, ... it's just counting upwards and then flipping the order of the bits to being a big endian things rather than a small endian order. Starting from -1 rather than zero.


The only thing left is to pattern these numbers progressively. So everything with 0, then all permutations with 1, then all permutations with 2, then all permutations with 3 ect. There's bound to be a more elegant way to this than the way I did it but:

  
    public int[] getPattern(int index, int n) {
        int[] p = new int[3];
        if (index - 1 < 0) {
            Arrays.fill(p,n);
            return p;
        }
        index -= 1;
        for (int q = 0; q < 3; q++) {
            if (index - n < 0) {
                Arrays.fill(p,n);
                p[q] = index;
                return p;
            }
            index -= n;
        }
        for (int q = 0; q < 3; q++) {
            if (index - (n*n) < 0) {
                boolean d = true;
                for (int m = 0; m < 3; m++) {
                    if (m == q) p[m] = n;
                    else if (d) {
                        d = false;
                        p[m] = index / n;
                    }
                    else {
                        p[m] = index % n;
                    }
                }
                return p;
            }
            index -= (n * n);
        }
        return getPattern(index,n+1);
    }

    Which then cycles through producing first black then, every color 256 bits from black (namely white), then all the colors patterns with these bits, then adding in 128 and all the color patterns with that in the mix. Etc. Calling it recursively because apparently I'm a balla (an inelegant one at that).

It might be better to just normalize the values there and feed them into something like LAB skipping imaginary colors etc.

Update:
If you are going to use this code, for whatever reason:
see the improved getPattern routine.

http://godsnotwheregodsnot.blogspot.com/2012/09/color-distribution-sans-recursion.html

anti-gray code fragment.

Given some index,

        int antigray;
        int vp = index >> 1;
        antigray = vp ^ (vp >> 1);
        antigray <<= 1;
        if ((index & 1) == 1) antigray ^= -1;

Produces a unique antigray code. There's likely going to be a simpler solution somewhere. Rather than shifting right, gray coding, shifting left, and inverting due to the original bit. But, it's the code solution to my Anti-Gray Codes and a pretty easy couple lines. And having found out that I needed something else for the question I was answering, I cut this bit, and didn't really want to lose it.

There are other gray codes than index ^ (index >> 1) but that's a really good derivation. My solution works for any gray codes. So this shouldn't be taken as the only optimally distant code. Also, there might be more distance possible between step-2 codes. It's maximally distant hamming distance is only for the very next and just previous code. But, the code after the next code, may end up being very similar to the current code. Solving for a code giving the maximally distant hamming distance beyond absolutely adjacent codes might not even be derivable through my method. Though, assuming one doesn't weight the code requirements such that step-2 codes being very maximally different could trump some slightly closer step-1 codes. The hamming distance pattern would be N, N-1, N, N-1 ... to which the anti-code would have to be a gray code.

The most distant step-2 code segments would require that with a hamming distance of 1, the same bit not be modified until all other bits are modified.

So the gray code to derive this would be something like:
0000
0001 -- bit 1.
0011 -- bit 2.
0111 -- bit 3
1111 -- bit 4
1110 -- bit 1 - 4 distance.
1100 -- bit 2 - 4 distance.
1000 -- bit 3 - 4 distance.
1001 -- bit 1 - 3 distance.
1011 -- bit 2 - 3 distance.
1010 -- bit 1 - 2 distance (this might be an error).
0010 -- bit 4 - 7 distance.
0110 -- bit 3 - 5 distance.
0100 -- bit 2 - 4 distance.
0101 -- bit 1 - 4 distance.
1101 -- bit 4 - 4 distance.

Which would then derive to several different gray codes which should still have 1 hamming distance between step-2 codes, but hamming distances of 2 for step-4 codes. Though, it would have less hamming distance at step-3 codes, which may defeat the entire purpose and depending on how much more you value step codes from one another. But, maximizing step-4 and step-6 codes may well minimize step-3 and step-5 codes.  But,  should at the very least it should maintain a hamming distance above 2 for step-2, and step-3 and potentially step-4 codes, and maximally distant codes at step-1.

Is there a God? Can poor arguments convince you?

http://www.everystudent.com/features/isthere.html?gclid=CNOh74Wc-LECFWjhQgodoSgA_A

Is there a God? Here's six terrible and mostly wrong arguments that can be easily dissected and shown wrong.

1) Does God exist? We aren't dead.
2) Does God exist? Science has a gap. *not really a gap
3) Does God exist? Science has a gap. *not really a gap
4) Does God exist? I don't understand evolution.
5) Does God exist? You're reading this and must be interested therefore God wants you to come to him.
6) Does God exist? The Bible.

Anti-gray codes. How to derive them.

Do you need a series such that the next item in the series has the maximum amount of bits different from the previous one. You need an anti-gray code. Gray codes are codes like that where the next digit only varies by 1. To make an anti gray code:


Take any gray code. Shift all the bits to the left by 1. Double the list. And alternate XOR flips. Done. You have an anti-gray code.

Take gray code.
0
1

Shift all the bits to the left by 1.
00
10

Double the list.
00
00
10
10

Alternate XOR flips.
00
11
10
01

The reason this works is because gray codes by definition have the minimal amount of distance. Xor flips have the maximum (they flip every bit). If you interweave them you will have maximum, maximum -1, maximum, maximum -1, maximum, maximum -1... which is an optimal anti-gray code. Also note, you don't really *need* to shift the bits to the left. You can introduce a zero *anywhere*, so long as you do it consistently. Watch, I'll do it with the middle digit.



     00,01,11,10
-> 000,001,101,100
-> 000,000,001,001,101,101,100,100
-> 000,111,001,110,101,010,100,011 (perfect anti-grey code).

Update:
Source fragment if you just want blackbox code.

I'm not blogging that much.

This is news that must be put on my blog post haste.