If, for example I want to have 5 colour values.
0xFF0000, 0xFF00, 0xFF, 0x0,0xFFFFFF
but I’m not fussy on their exact value (+/-50 per colour channel), nor am I fussy about the order they appear.
Then I use a simple random number generator that exposes the seed.
static long seed;
static int nextInt() {
seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1);
return (int)(seed >>> 16);
}
I find that the seed: 60792109829226
Gives the order, and approximations:
1st) ff0000~=f80407
2nd) ff00~=ed11f
3rd) 0~=81622
4th) ffffff~=e8f9fd
5th) ff~=1b21e3
Obviously finding the desired seed is a computationally expensive operation, and the likelyhood of finding a match rapidly degrades the longer the sequence of values it is that you’re looking for.
You’d also have to make quite good use of it, to recoup the cost of the extra method. (though that mostly pays for itself if you were using the Random class anyway).
It avoids array declarations (new int[]{0xFF0000, 0xFF00, 0xFF, 0x0,0xFFFFFF}), which are obviously costly in terms of bytecode.
Alternatively, it avoids the need for code to unpack said data from Strings/a class file attribute.
What do people think to this technique of lossy compression?
Would it interfere with the zip/pack200 compression enough to negate any gains?