[vishnu]

Hey guys, for all the old timers who remember me working on this simulation, I've added all the simulation code back in and it seems to be working as advertised. It's still pretty much a hack, and I'm working on that. For example if you compile it you'll notice that there's a blank menubar across the top, I still need to flesh that out. Also, if you move or cover then uncover the window while the simulation is running, the menubar and the bottom form with the control buttons don't redraw until the simulation ends. If you supply a number on the command line, that many simulations of 100,000 hands each will run, otherwise it defaults to running 40 simulations. No other command line options are available yet, not even -h or --help, I'm working on that. By default it will echo the number of simulations back to the terminal window you launch it from. If you open the file in your favorite text editor, there's some helpful information at the top of the file on how to compile it using g++. It's on my todo list to ifdef the STL calls to eventually get this code to run using MIPSPro, or an older GNU for example on my Sun Blade 2500. I haven't gotten started on that yet.

The interesting thing to me is that my code matches Braun's results everywhere except the player's hands of ace 8 and ace 10, so either I'm wrong or Braun was wrong, but if I'm wrong I can't for the life of me figure out where. There are some other trivial differences, for the case of a player's pairs, I match Braun exactly everywhere except for the dealer's 10, where Braun got 145 and I get 144. Also for the case of a player's 10, 10 vs. every dealer upcard, Braun got 724, I think the right number is 723.

When the simulation ends, any difference between Braun's numbers and mine are highlighted in red, my numbers keep the white background. Google books has Braun's numbers online, if you search for "chart b.21 how many times you will get each hand" you can see them.

As I mentioned before, I want to tackle Braun's other simulations as well, I decided to do this one first because I thought it would be the easiest. I ran earlier versions of the code on my 600 MHz Octane2 and it was horribly slow. So far the biggest run I've done was 12,700 loops (of 100,000 hands each), and it took half a day on my 64 bit 3.6 GHz Xeon E5-1650, so I think that makes it a supercomputer application. Isn't any code that takes half a day to complete a supercomputer application?

Anyway, thanks to anyone who's bored enough to try this out!

One other thing, John if you compile this, I left the call to sprintf because I want older compilers to be able to use this, I increased the character string size by integer 1, please let me know if that still smashes the stack on your workstation, so thanks if you do try it!

[jpstewart]

There's a typo in the g++ command line mentioned in the source file.  It should be -O3 (upper case letter O) where you have -o3 (lower case) if you want to optimize the code.  The lower case version sets the output filename to "3" (which just gets re-set again by a more sensible -o option later in the command line).

Also, the code comments at the top say the default is 400 simulations.  The forum post and the actual code use 40 as the default.

(Sorry.  I hate to seem nit-picky.  But these things just jump out at me.)

[jwhat]

Hi Vishnu,

this version as the same "stack smash" error as before.

Bugs are:

1. Not allocating enough mem for sprintf result
2. You have loop across array data[340] which is larger (360) than size of the array.

I did a little hacking to add some #defines around the problem code, so you can then handle the sprintf vs snprintf choice if you want:

Code:

< #define SPRINTF_BUF_SZ(INT_TYPE) (((sizeof(INT_TYPE) * 8) / 3) + 2)
< // #define SPRINTF_BUF_SZ(INT_TYPE) (32)
< #define SPRINTF(BUF, BUF_SZ, FORMAT, NUMBER) snprintf(BUF, (BUF_SZ), FORMAT, (NUMBER))
< #define INNER_LOOP_MAX 100000
< #define OUTER_LOOP_MAX 5
< #define SIM_RESULT_SZ 340
<  
128c121
< Widget simDataLabels[SIM_RESULT_SZ] = 
---
> Widget simDataLabels[340] = 
230c223
<         numsims = OUTER_LOOP_MAX; 
---
>         numsims = 40; 
233c226
<         if(numsims == 0 || numsims ==1) { numsims = OUTER_LOOP_MAX; }
---
>         if(numsims == 0 || numsims ==1) { numsims = 40; }
490c483
<     const char * sim_data_strings[SIM_RESULT_SZ] =
---
>     const char * sim_data_strings[340] =
529c522
<     const char * sim_data_names[SIM_RESULT_SZ] = 
---
>     const char * sim_data_names[340] = 
581c574
<     for(int i = 0; i < SIM_RESULT_SZ; i++)
---
>     for(int i = 0; i < 340; i++)
1095c1088
<     short unsigned int data[SIM_RESULT_SZ] = 
---
>     short unsigned int data[340] = 
1209c1202
<             for(k = 0; k < SIM_RESULT_SZ; k++) { data[k] = 0; }
---
>             for(k = 0; k < 360; k++) { data[k] = 0; }
1212c1205
<         for(j = 0; j < INNER_LOOP_MAX; j++) // Braun's published result was 100,000 hands
---
>         for(j = 0; j < 100000; j++) // Braun's published result was 100,000 hands
2874,2875c2867,2868
<             char temp[SPRINTF_BUF_SZ(short unsigned int)];
<             SPRINTF(temp, sizeof(temp), "%u", rightTotals[ii]);
---
>             char temp[(sizeof(short unsigned int) + 1)];
>             sprintf(temp, "%u", rightTotals[ii]);
2896,2897c2889,2890
<             char temp[SPRINTF_BUF_SZ(short unsigned int)];
<             SPRINTF(temp, sizeof(temp), "%u", bottomTotals[ii]);
---
>             char temp[(sizeof(short unsigned int) +1)];
>             sprintf(temp, "%u", bottomTotals[ii]);
4460c4453
<     for(i = 0; i < SIM_RESULT_SZ; i++) {
---
>     for(i = 0; i < 340; i++) {
4481,4482c4474,4475
<     char temp[SPRINTF_BUF_SZ(short unsigned int)];
<     SPRINTF(temp, sizeof(temp), "%u", data);
---
>     char temp[(sizeof(short unsigned int) + 1)];
>     sprintf(temp, "%u", data);

Cheers from Oz,

jwhat/John

[Raion]

sprintf is a bad call. You can include asprintf/vasprintf calls super easily....


I have a BSD lic implementation here: http://gitea.irixce.org/Raion/libxg/src/...asprintf.c

[vishnu]

Thanks for the input guys, sorry for the typos those are fixed now. I have a bad habit of interchanging zeros and  the letter "o".

And yes that 400 is a typo too, it defaults to 40 with no command line argument.

I'm pretty darn sure data[340] is right, the array has 34 lines with 10 elements in each line.

The thing about sprintf is I've read that a lot of older compilers don't support its modern replacements, apparently adding one to the sizeof call: (sizeof(short unsigned int) +1) is still too small for John's workstation, should I just add 8 maybe?

[Raion]

va_list is the big dependency for my asprintf implementation. GNULib may have one that isn't C99-ese, but I dunno.

[vishnu]

MIPSPro can't handle varargs of the three dot type...

---

John, can you kindly email me your version of the code? My email addy is at the top of the file...

---

Because I like your changes I just want to edit them to be consts; I don't really like defines in C++ code...

[Raion]

Actually it does just fine. I have used that exact asprintf for fixing dropbear and others.

[jwhat]

Hi Vishnu,

np I will zip and email.

The result arrays are all ok @ 340, but you have this loop as 360, so it will clobber stack:

for(k = 0; k < 360; k++) { data[k] = 0; }. <== where: data[340]

Most of other changes are just "nicities".

On "nicieties" if you are initialising your arrays, you don't need to explicity declare size and you can then use sizeof(ARRAY) to ensure loop is within bounds (as long as you are in scope of where the array was declared).

Cheers from Oz,

jwhat/John

[vishnu]

Oh wow, okay so that is a typo, thanks! And yeah I know I could just let the compiler size the arrays but I'm obsessive about that, for reasons I don't really understand. But you're absolutely right that typing in all those numbers everywhere, as opposed to defining them in one place, is ridiculously error prone, and thus I am constantly left with painful reminders of my own stupidity...