To simulate a game of cricket using a common scientific calculator.
A common scientific calculator (See Note), a sheet of paper (preferably ruled), a pencil or a pen, an eraser (incase a pencil is used).
This simulation uses a common calculator equipped with various scientific and statistical functions. The functions required for such a simulation are readily available as inbuilt functions in a common scientific calculator. The FX-100S model from Casio (my first ever calculator) was my choice during my early days in this game, which coincided with my first year at undergraduate college. Now I use the FX-115W (click here to download the user manual as a PDF file from the Casio website), which is just as fine a calculator as the FX-100S (which is retro now, I think). This does, however, not mean, that you need a scientific calculator per say to play this game. Since the random generator is the single function actually needed to play (with all other functions used mainly used to keep track of the overs used up), the scientific calculator can be dispensed with. However, I am describing the simulation using a scientific calculator (the FX-115W), as this simulation is mainly intended for the would-be engineer who wants to pass his time through a boring class. Students in other streams have, in my honest opinion, other methods to do the same. But in a silent class, as a engineering student almost always encounters, this is the BEST way to kill time without the instructor coming to know that you are up to mischief. Also, I expect the reader to be familiar with the working of his or her scientific calculator. So all technical information pertaining to the calculator is not given. Additionally, this is the way I started playing it. Users are welcome to make changes according to their own likes and dislikes.
To simulate a Test match
The first step is to change the mode of the calculator to the SD mode. Once this is done, the calculator is fully enabled to keep track of the number of overs consumed during the innings. How this has been done will be apparent as we go on. Now, press the ï¿½shiftï¿½ button followed by the ï¿½ACï¿½ button and then the ï¿½=ï¿½ key to clear the calculator memory of all previously stored data values. Before doing this however, it would be worthwhile to check if you have any data stored that would be of use. But if you were at least half as intelligent as me (I am stupid, believe me!), you would have made a paper copy of all stored data.
Now that the calculator has been primed for our use, we can proceed with the toss to decide which team gets to bat first. Lets take that India is playing Pakistan in a Test match. Lets assume India will bat first if they win the toss. Now, press the shift button and then the Ran# function. On the screen you will see a random number thatï¿½s generated. Write this number down against India. Then follow the above-mentioned steps to generate another random number. And note this number against Pakistan. The higher number (Note that it is always a real number between 0 and 1) points to the winner of the toss. Lets say that India won the toss. Since we have already assumed that India will bat first on the event of winning the toss, India gets to bat first.
Now make two wide columns on the piece of paper. Divide each column into two sub-columns, each representing one inning for that particular team.
Now that we are set up, we can get to the actual game. Press the shift key and then the Ran# function to start. Note the first digit after the decimal point on the random number that has been generated. This is the number of runs actually scored in that particular over. Keep this number in memory and add each additional digit (on subsequent generations) to the one in memory to keep track of the runs scored. If the first digit is ï¿½0ï¿½, it means a wicket has fallen in that particular over. In that case, note the next digit after the ï¿½0ï¿½, which indicates the runs scored in that over before or after the wicket fell. Add the noted digit to the sum already in memory and put it down to paper once a wicket falls. So we are keeping track of the runs scored in each partnership. In order to make the simulation more analogous to a real test match, all digits that are greater than 6 are to be noted as ï¿½1 runï¿½. This would change when we are simulating an ODI (which we will discuss later on). Though it would seem very unlikely that no one scores more than six runs in an over in a Test match, we have to however note that there are no maiden overs possible in this simulation and the effects of both these assumptions sort of negate each other.
Once you have the digit added to the sum in memory, press the ï¿½M+ï¿½ key to increment the number of data points (since we are working on the SD mode) by one and to generate the next random number (both happen at the same time). This would keep track of the number of overs. Remember, each digit that we add the sum that we are mentally keeping track, is the number of runs scored in that partnership in each over.
When ten wickets fall (or since this is a test match, you declare the innings), add up all the numbers in the particular column. This is obviously the total score of the team in that innings. Now to note down the overs consumed (which you might even observe from time to time during the course of the innings), all that you need to do, is press the ï¿½RCLï¿½ key and then the key marked C, which would give you the number random numbers generated. Note this number down under your total score, maybe in brackets. Proceed with the next innings. You have to remember that in a test match, usually there is a maximum of 90 overs each day, which makes it a total of 450 overs. So keep track of the overs from time to time, especially in the fourth innings. Another thing is that each time you check the number of overs (press ï¿½RCLï¿½ and then ï¿½Cï¿½), to get back to the random number mode, you have to start afresh from the ï¿½shiftï¿½ and then the ï¿½Ran #ï¿½ keys. However, this does not affect the count of overs and every press of the ï¿½M+ï¿½ key increments the number of overs by one and also generates the runs scored in that over. Continue till either all the wickets have fallen or all 450 overs are consumed or till a result is apparent (which ever comes first, as in case of the real test match). All other test match rules apply, including the draw and the tie scenarios and hence it is always critical to keep track of the target and the overs consumed when the fourth innings is on. Note down the overs consumed, cumulatively or otherwise always.
To simulate an ODI
The groundwork and the toss proceed as in the case of the Test match simulation. Even the random number generation works the same way, as would the counting of the overs. But, always do clear memory (ï¿½shiftï¿½, ï¿½M+ï¿½ and then at last ï¿½=ï¿½) at the start and end of each inning, so that the count starts afresh. And the paper used to keep track of scores only has the two main columns, each representing that teams inning. Due to various reasons that I have given below, I have in the past, used two or more methods (some of which I have totally forgotten) to simulate ODIs. I have given below three of them that I actually use or remember now. It is left to the user to choose between these three.
All the scoring methods and the counting methods work as in case of the test matches. However instead of counting ï¿½1ï¿½, when the first digit is greater than 6, we use the digit as is and stop innings when the memory shows that 50 random numbers have been generated. Again, if the first digit is zero, use the next digit to denote the runs scored in that particular over. This method however results in scores in the range of the early 200s more often than it results in scores of the 250s or beyond and so might not appeal to certain people. To get over this niggling fault, I came up with the second method.
Actually this method is very close to Test matches than the first ODI method given above, including the ï¿½1ï¿½ instead of numbers higher than 6. However we get to generate 150 random numbers instead of 50. We count every two 3 numbers as an over (i.e. one generated number standing for 2 balls of a over). But this gives us a lot of scores in the range of 300 and again this might not be desirable. So we get the third method.
Usually in a real life ODI match, the thumb rule is that any teamï¿½s total score doubles between the 30th and the 50th over. This method of simulation aims to duplicate that particular thumb rule. So we actually allow 60 random generations. Note that 60 is the 2 times 30 and hence any score at the end of 30 generations would double. However, we would put down the number of overs after 30 proportionate to 50. So 55 generations would amount to [(55-30)/20] additional overs after the 30 over mark, which results in a total of approximately 47 overs in this case. Incase this does not make sense, the actual formula is :
Number of total overs, O = P + [(P ï¿½ 30) / 20] where, P is the number of random numbers generated.
The third method seems to be the most complicated but it is the closest I have ever got to a real world cricket game.
Here I have presented a method of simulating a cricket Test and three different methods of simulating an ODI cricket match using a simple scientific calculator.
These methods given above are primitive in nature and only reflect the intense interest in the part of yours truly towards the game of cricket as it is played in both the hallowed turf at Lords and in the sandhus (which in colloquial Tamil means ï¿½side streetsï¿½) of Chennai. It is left to the readers to tailor these methods to suit their likes. As much as the author would like to say that he developed these methods (at least a part of that statement is true), he does not want to impose any intellectual copyrights over these methods and wants everyone to use (and distribute) these methods at will and discretion. He will not however mind if this methods are attributed to him, by anyone who wishes to use them or pass them on to others. Additionally the author would like to interact with anyone on any improvements that they choose to do to make these methods much more closer to the actual game.