Logical question to ask... how a person could have negative stats.
Simple answer.
Through some testing, and good-old-fashioned detective work, a problem was discovered in the dupe-checking
mechanism of the stats generator.
Stephen was gracious enough to work through it with us - and several of us submitted albiet huge - bogus results.
Evidently there was a compilation error that was allowing dupes through. Sometimes a new user will errantly
rename results.dat to results.txt - or combine the wrong files - or whatever mechanism results in submitting duplicates.
Our collective concern for the value of the project dictated that we work together with Stephen to "tweak" the
stats mechanism to assure a "level playing field" for all participants. Further - this recompilation and application of the
dupe-checker to the entire database ensures that only one of any given result (same parameters, same checksum, same result) resides in the database.
This work is good for ALL participants - and nipped any potential problems "in the bud" so to speak. We wanted to get
through the testing and validate the results before announcing any particular "problem" with the project.
The database revealed only about a 7% duplicate loss - so there was no mass loss of stats. Some will notice adjustments - some will not. It has only to do with how many duplicates were sent for whatever reason. Everyone will receive full credit for unique results - (as it should be) 😉
TeAm DPAD extends its warmest thanks to Stephen Brooks for quickly and carefully attending to this situation BEFORE it became a problem. It's really nice to work with someone with the class of Mr. Brooks.
DPAD is solid - and moving forward. 🙂
- we now resume our regular crunching program. -
oh... and btw - I'm STILL sandbagging. The results I submit Friday will all be REAL. 😉
Simple answer.
Through some testing, and good-old-fashioned detective work, a problem was discovered in the dupe-checking
mechanism of the stats generator.
Stephen was gracious enough to work through it with us - and several of us submitted albiet huge - bogus results.
Evidently there was a compilation error that was allowing dupes through. Sometimes a new user will errantly
rename results.dat to results.txt - or combine the wrong files - or whatever mechanism results in submitting duplicates.
Our collective concern for the value of the project dictated that we work together with Stephen to "tweak" the
stats mechanism to assure a "level playing field" for all participants. Further - this recompilation and application of the
dupe-checker to the entire database ensures that only one of any given result (same parameters, same checksum, same result) resides in the database.
This work is good for ALL participants - and nipped any potential problems "in the bud" so to speak. We wanted to get
through the testing and validate the results before announcing any particular "problem" with the project.
The database revealed only about a 7% duplicate loss - so there was no mass loss of stats. Some will notice adjustments - some will not. It has only to do with how many duplicates were sent for whatever reason. Everyone will receive full credit for unique results - (as it should be) 😉
TeAm DPAD extends its warmest thanks to Stephen Brooks for quickly and carefully attending to this situation BEFORE it became a problem. It's really nice to work with someone with the class of Mr. Brooks.
DPAD is solid - and moving forward. 🙂
- we now resume our regular crunching program. -
oh... and btw - I'm STILL sandbagging. The results I submit Friday will all be REAL. 😉
