Link to home
Start Free TrialLog in
Avatar of StevenMiles
StevenMiles

asked on

Which version of C should I use when Perl is too slow?

Sorry if this question sounds particularly naive.

I'm getting ready to write code to analyze a poker game variant. I expect that the computations will require a computer to run for, literally, months, to complete the analysis. (I've become certain that the analysis for this game has not been done before, so I can't just find the analysis online.)

The program will need to look at every possible player hand, and for each hand evaluate what to do against every possible dealer hand; there will be over a quadrillion iterations happening.

There'll be simple math, lots and lots of comparisons, array lookups, loops and loops and loops, hopefully not that much sorting.

I am not a professional programmer, and I do 99% of my programming in Perl, which is easy for me. It'd be (fairly) straightforward for me to write the necessary code in Perl, but I'm afraid it would take forever to run. Or longer.

I have programmed a couple of medium-complicated iPhone/iPad apps, which use Objective C. So, I do have some foundation in C, although it's been a couple of years since I did any Objective C programming.

My questions are: Is this likely to be a disaster if I do it in Perl? Then, I understand there are different "versions" of C  --  straight C, C#, C+, etc. If I'm to start as a not-quite-beginner learning some C to use for this project, is it clear which C I should be using?

Thanks for any insight.

--Steve
SOLUTION
Avatar of AndyAinscow
AndyAinscow
Flag of Switzerland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hi Steve,

That kind of analysis is beyond the ability of a mere mortal to process.  

There are approximately 37 million poker hands from a 52-deck pack.  Multiply that by the number of possible hands per dealt hand and the numbers are staggering.  Managing the volume of results is beyond the ability of most desktop computers.

I suggest that you base your analysis on patterns and pattern matching.  The programming might seem a bit more complex, but you'll get a quantity of answers that you can manage.  And an heuristic algorithm can adjust to its findings in real-time whereas the brute force approach never can.

Any C compiler should be just fine.  gcc is as good as any of them.



Good Luck!
Kent
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Rank the possible hands by general type

- straight flush
- 4 of a kind
- full house
- straight
- 3 of a kind
- 2 pair
- 1 pair
- high card

Then determine what you want to solve.  i.e. what are the odds of this hand winning.

Are you playing straight poker?  (deal 5)
Are you playing 5 card draw?  (deal 5, draw up to 3)
Are you playing the popular Texas Holdem?  (with common cards)

The analysis is quite a bit different between them.  But the goal is the same.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Further to my first comment, some crude approximations.
5 card hand for player from 52 cards means
52*51*50*49*48 possible combinations, call it 50 to the power 5 which is then a bit more than 300,000,000.  Call it the same for the dealer so combinations are 90,000,000,000,000,000.
Say the PC can handle 1 million hands per second (WOW, some PC) that means it will take 90,000,000,000 seconds.
One year is 365*24*60*60 seconds which is a bit over 30,000,000.
So this will take about 3,000 years on this extremely fast PC.

So I'll make a correction to my first comment:

I expect that the computations will require a computer to run for, literally, months, to complete the analysis.
I've not done the maths but you might want to substitute millenia for months in that sentence.

replaced centuries with millenia
> 52*51*50*49*48
If you pick up all 5 cards at once, rather than betting after each hand, you could divide this by 5*4*3*2*1
dividing again for the dealer might reduce millennia to months.
You might also rename all the suits without changing the value of hands, which could let you reduce another factor of 24
It might also behoove you to use any other combinatorial shortcuts you can find.
But depending on the exact problem you are solving, it still may not be enough, and you may have to use some approximations instead of an exact count.
If you can specify the exact problem, we may be able to suggest some short cuts, but then it might be more mathematics suggestions than programming language suggestions.
Avatar of StevenMiles
StevenMiles

ASKER

Thank you everyone for responding.

Andy, I was actually also worried that I would run out of time, because even the proton has a half-life of only about 10^40 years.

Kdo, I appreciate your input, but I was intentionally vague about exactly the game that is to be processed: a poker *variant*, not exactly poker. My thinking is that my project is possible, with attention to optimization, as you recommend. I was more interested in  generally whether I should leave Perl for C and which C I should go to.

Wilcoxon, it's a great idea to do a benchmark, although from what people comment, it'd probably be just to confirm for me that C is better.

Tommy, your comment about C vs C++ is about what I've been reading elsewhere. I've used inheritance, etc., in Objective C, but I don't think I'll need it for this.
Hi Steven,

If you'll program to the logic, perl, C, C++, FORTRAN, COBOL, or most any other language will be just fine.  You won't need lifetimes to complete the analysis (completely disregarding storage of the results).

But if you choose a processor intensive solution, most of the C compilers will produce similar results.

Going forward, you'll get better answers if you'll frame the question to better align with your needs.  :)


Good Luck!
Kent
Kent, I appreciate the feedback. I don't post that often, and I can see now the importance of an exact definition of the question!
>>Andy, I was actually also worried that I would run out of time, because even the proton has a half-life of only about 10^40 years.

It ought to have finished processing by then.  ;-)  

I was pointing out a brute force approach wouldn't work.  Even optimising things the time scale is still likely to be unrealistic - as soon as one card is dealt a lot of the symmetry is broken.  (eg.  Without a trump suit all 4 suits are equal, so the first card has 'only' 13 possibles but once that is drawn then the chance of another of that suit drops marginally compared to the other 3 suits).  I don't know what you wanted to achieve but a more specific target may be do-able.