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
_______________________________________________
Bug-gnubg mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-gnubg
