On 2015-01-14 7:43 AM, Ian Shaw wrote: > How about simplifying life and offering only Mersenne Twister, manual and, > possibly, file dice? >
In principle I do agree with you on reducing/eliminating code. Random.org is something that I end up referring people to most when they don't trust PRNG's. If this was just me personally, then I'd say that Mersenne, Manual, File would be all that is needed. If you want one of the other PRNGS you could generate a file. The problem with generating a file is that many novices may not be tech savvy enough to create afile from a source like Random.org . I answer a lot of hate mail regarding the dice and the Random.org is at least a fall back for me to provide an answer for those who are unwilling to enter the dice manually but don't want a PRNG. > GnuBg and other bots are now mature programmes, and think we need to go to > the same lengths to convince people that the dice are fair. Sure, there will > always be some doubters, but such people won't be convinced by anything. No > established player has qualms. We do agree here. The people who think the bots cheat will likely not be convinced no matter what the source of randomness. If you came up with a solution for the randomness they'd find some other way to claim the bot cheats. I think that most (not all) established players do understand the issues. > > Multiple dice algorithms just feels like feature bloat to me, to no benefit. > For example, rollouts always use MT, and, when posted on the forums I read, > there has never been a query raised. > If I were to eliminate one feature altogether it would be "Dice Manipulation". To me this gives very poor optics and has been the source of some criticism. The argument goes "if there is a dice manipulation feature then it follows that the bots know how to manipulate the dice, so they are probably already doing so during normal play." . > Getting rid of the other algorithms would simplify the code, the UI and the > rollout export data, not to mention the https issues you've been debating. > I haven't looked at the rollout export data so can't comment. As for 'https' the real issue here is that since I took over building the official MS Windows releases (quit a few years now) I have only upgraded the build environment once. That was when I first took on the task and migrated to MSYS/MinGW. I didn't alter it after because I believe in the adage "If it's not broke don't fix it". The `https` issue only really highlighted the fact that the MSYS/MinGW development environment I had (and it was quite the hack still) was long in the tooth. One of the reasons I hadn't migrated to something else was that there was no pressing need to. After the whole Random.org saga I decided to see what options I had that create a more maintainable build environment. I've now settled on MinGW-w64/MSYS2 . In theory one can build 32 and 64 bit variants(although I'll stick with 32 bits as a common denominator). I have managed to build a feature complete version of GNUbg including Language&Translation processing;Documentation generation;3D boards;Long RNG seeds;Python2(2.7.9);Sound;Multi Threading(using GLIB Threads); External interface and SIMD(AVX/SSE/SSE2/None);Uses libcurl/gnutls to access Random.org (less code as well). It also successfully compiles as the command line variant. Some other benefits of spending all this time on a new build environment based on MinGW-w64/MSYS2 is that Python3 also becomes available to us (And as of last year we do have Python3 support). We also get more up to date libraries (especially GTK/Cairo/Pango/GLIB); the speed of builds is vastly quicker; doesn't suffer from a serious memory leak when compiling; should be cross compilable from a Linux distribution as build host; ability to build a lot more libraries natively given that MSYS2 uses pacman as a package manager and the number of applications/libraries that are supported are pretty reasonable; we no longer rely on MSVC runtimes. Although I can build GNUbg it requires some code changes. There are some macros/function redefinition problems, missing prototype that I manually tweaked, but the best solution is to modify the configure.ac to properly detect these conditions and provide #define's in config.h to deal with them. The INNO installer requires some modifications. So although `https` was a pain in the ass (and mor work than it should have been), I think the end result is positive for the project from an MS Windows development perspective. -- Michael Petch GNU Backgammon Maintainer / Developer 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
