Embarrassing bug in variation codes

Here you can discuss and share functionality improvements and helper programs to make Context Free better.

Moderators: MtnViewJohn, chris, mtnviewmark

Post Reply

Are you a big-endian or a little-endian?

Poll ended at Tue Jan 22, 2008 5:37 pm

Big-endian (PPC Mac, 680x0 boxen)
0
No votes
Little-endian (Windows, Intel Mac, x86 Linux/BSD)
3
100%
 
Total votes: 3

User avatar
MtnViewJohn
Site Admin
Posts: 882
Joined: Fri May 06, 2005 2:26 pm
Location: Mountain View, California
Contact:

Embarrassing bug in variation codes

Post by 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
Posts: 4
Joined: Thu Jan 03, 2008 6:39 pm

Post by 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.

User avatar
MtnViewJohn
Site Admin
Posts: 882
Joined: Fri May 06, 2005 2:26 pm
Location: Mountain View, California
Contact:

Post by MtnViewJohn »

dankna wrote: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.

User avatar
zol
Posts: 40
Joined: Sun Mar 23, 2008 4:14 pm

Post by 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.
Last edited by zol on Tue Mar 25, 2008 10:45 pm, edited 1 time in total.

User avatar
MtnViewJohn
Site Admin
Posts: 882
Joined: Fri May 06, 2005 2:26 pm
Location: Mountain View, California
Contact:

Post by 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.

Post Reply