Embarrassing bug in variation codes

[MtnViewJohn]

Have you ever noticed that sometimes when you download a cfdg file from the gallery and use the same variation that the author used when they uploaded you get a different image? But most of the time the variation looks the same. Or maybe you see this problem most of the time and only occasionally do you see a match between your rendered variation and the author's uploaded variation.

Well we did, but we just scratched out heads and assumed that the author had used an older version of Context Free. But it turns out that it is a little-endian dependence in the code that extracts entropy from the cfdg file to salt the random number seed. So the variations seen by PPC Mac users (big-endian) is different from the variations seen by Windows and Intel Mac users (little-endian).

So now I have to pick either big-endian or little-endian variations as the true variation. I think that most Context Free users are on little-endian machines. But I thought that I would check with a forum poll. Please vote for your endianness.

[dankna]

You know what someone ought to do, actually, is come up with a converter that takes the legacy big-endian variation codes and figures out what the corresponding little-endian one is. The archives are too big to justify going through and fixing them all, but that way people could at least fix things on their own.

[MtnViewJohn]

You know what someone ought to do, actually, is come up with a converter that takes the legacy big-endian variation codes and figures out what the corresponding little-endian one is. The archives are too big to justify going through and fixing them all, but that way people could at least fix things on their own.

I don't think that it is possible to convert a big-endian variation to a little-endian variation. Context Free uses a distributed random number generator system. Each replacement shape in a rule has a 48-bit hash code that gets exclusive-ORed into the 48-bit random number seed when a rule is being executed. The bug is that these 48-bit hash codes are not calculated correctly on big-endian (i.e. PowerPC) computers. There is no way to transform the variation code to compensate for the error in all of the hash codes. The next version of Context Free (version 2.2) will have a mode where it can recreate big-endian variations.

[zol]

Getting the entropy from the source strikes me as a deeper problem.
Consider a simple case,

Code: Select all

startshape foo
rule foo{
    SQUARE{}
    foo{x 1.1}
}
rule foo{}

Using variation "A" , CF 2.2beta , little-endian (Linux), the number of squares is:
1 for 'foo 1.1'
2 for 'foo 1.5'
2 for 'bar 1.1'
4 for 'bar 1.5'

If you make anything sufficiently complex, there are likely to be glitches that are very hard to find or reproduce.
As far as possible, you want to hold on to a known specimen in order to diagnose and test fixes quickly rather go hunting for new ones after every adjustment, not knowing whether the fix has eliminated them.

Actually, it doesn't even need to be that elusive; sometimes you just want to focus on one issue that a certain variation exemplifies nicely.

Obviously, changes in rule order, branches, and weighting must affect the decision path, but no-one expects the Spanish Inquistion.


The other problem is aesthetic: You find the variation you're looking for, just a bit off in some detail, but you can't tweak ANYTHING. Well, maybe you can, but who knows -- You just have to systematically try every possibility.

Rule names aren't entirely trivial either. The source evolves, and original names might be misleading or uninformative.
If you decide to share a variation, you might be tempted to make the source readable for others.

Fortunately, comments appear to be immune from my experiments so far, so some documentation might still be safe.

I don't see why cfdg files need their own personalised entropy anyway. They're not even very big ... one could include a modest sized text file with more noise and use it for all CFDGs.

[MtnViewJohn]

Hey, that's a great idea! Mark and I have not been very happy with the brittleness of the current entropy scheme. We were thinking of chucking it for something more robust in CF 3.0. Your idea of a fixed pool of entropy values would provide better randomness and allow people to edit rules without completely changing the resulting output.