Re: [Bug-gnubg] gnubg bug? change to getLuckRating() (gnubg-source-SNAPSHOT-20110729)

[Michael Petch]

On 29/07/2011 8:15 AM, pck wrote:

I noticed that LUCK_VERYGOOD, etc. are defined in gnubg.c as 0.6 and 0.3, while the old hardcoded levels used by getLuckRating () were 0.06 and 0.02. So I changed (MainMenu)Settings->Analysis->(Form)Luck thresholds from their defaults 0.6 0.3 0.3 0.6 to 0.06 0.02 0.02 0.06. This at first seemed to fix the problem ("Luck Rating" now came back with proper reports of "Good dice, man" etc.), but after playing/analysing for a while I noticed gnubg reporting too many "very lucky" rolls in the movelist (see attachment for an example). The power of ten discrepancy between the old hardcoded levels and the user defined settings is obvious, but being unfamiliar with the gnubg src, I haven't been able to trace the movelist problem.

Thanks for the bug report. I have fixed it and will appear in a new build of code this weekend. I am a bit perplexed at how the original codes hard coded values were derived. Although a factor of 10  makes it more in line than it use to be its not the same (.02 != .03) so now the output differs a bit to previously releases. Hard coded value use to be .02 and now based on the defaults of .3 we went from a factor 15 change to factor 10 for BAD/GOOD/NONE.

The old code was:
 if ( rLuck < -0.06 )            
         return LUCK_VERYBAD;     
       else if ( rLuck < -0.02 )     
         return LUCK_BAD;     
       else if ( rLuck < +0.02 )     
         return LUCK_NONE;     
       else if ( rLuck < +0.06 )     
         return LUCK_GOOD;     
       else     
         return LUCK_VERYGOOD;
We have 2 choices long term. Stick with a factor 10 difference for all values (As the new code is with the fix). Or go back to the original code as it is above where hard coded values are used and are independent of the thresholds set in the GUI

-- 
Michael Petch 
CApp::Sysware Consulting Ltd. 
OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304