Pen and paper roleplaying games filled many of my hours and were responsible for many pizza orders hours after the sun had set. It also helped me understand a bit about the nature of random numbers. In my sessions of DnD, a critical hit was scored when a twenty-sided die rolled exactly twenty. Assuming a perfect die, there is a five-percent chance of this. Conversely, there is the same chance of rolling a natural one and suffering a critical failure. This is good for theatrics since one in ten rolls results in something radical happening. A troll may fall on its own sword, or a hero may cut out the heart-stone of a golem.
In reality, such feats are exceedingly rare, and this can be accounted for by rolling two ten-sided dice instead. The odds of rolling exactly twenty are now one percent instead of five. Chances are, most rolls will end up closer to ten. Ten is a safe number if you want to keep a vorpal blade from slicing off the heads of your comrades but less likely to cleave your enemies. Good or bad, this insight into random numbers has come back around.
Enough background.
----------
After listening to prandom notes for hours, it seemed like a good idea to control how much they would deviate from one note to the next. There was no need to put a hard limit, but changing by a full octave should occur less frequently than changing by a couple of notes. Theoretically, the current code has an even distribution of changes which has been producing pleasing but erratic sounds. That can be tempered.
Instead of relying on a single prandom number of zero to twelve, a series of smaller values numbers can be generated and added. The full range will still be intact, but the results will cluster around an average value. Generating more small numbers will cluster around the middle than generating a couple medium numbers. This can be seen in the spreadsheet below.
While making the graph, it helped to think of the prandom numbers as dice with different numbers of sides. Unlike the dice these numbers were based on, zero was also a possible "roll" which meant that zero was a possible outcome after all the numbers were generated. Ten-thousand iterations seemed to be the point at which it was likely to get at least instance of zero and twelve after generating a dozen either/or fields.
A day was spent making these graphs to understand the intricacies of the math involved and to make a nifty graph for this blog. I hope it helps understand why this method was used. Another method would have been to use weighting like Peter Kelly describes.
The rest of the posts for this project have been arranged by date.
First time here?
Completed projects from year 1
Completed projects from year 2
Completed projects from year 3
Completed projects from year 4
Completed projects from year 5
Disclaimer for http://24hourengineer.blogspot.com and 24HourEngineer.com
This disclaimer must be intact and whole. This disclaimer must be included if a project is distributed.
All information in this blog, or linked by this blog, is not to be taken as advice or solicitation. Anyone attempting to replicate, in whole or in part, is responsible for the outcome and procedure. Any loss of functionality, money, property or similar, is the responsibility of those involved in the replication.
All digital communication regarding the email address 24hourengineer@gmail.com becomes the intellectual property of Brian McEvoy. Any information contained within these messages may be distributed or retained at the discretion of Brian McEvoy. Any email sent to this address, or any email account owned by Brian McEvoy, cannot be used to claim property or assets.
Comments to the blog may be utilized or erased at the discretion of the owner. No one posting may claim property or assets based on their post.
This blog, including pictures and text, is copyright to Brian McEvoy.
2019-03-02
In reality, such feats are exceedingly rare, and this can be accounted for by rolling two ten-sided dice instead. The odds of rolling exactly twenty are now one percent instead of five. Chances are, most rolls will end up closer to ten. Ten is a safe number if you want to keep a vorpal blade from slicing off the heads of your comrades but less likely to cleave your enemies. Good or bad, this insight into random numbers has come back around.
Enough background.
----------
After listening to prandom notes for hours, it seemed like a good idea to control how much they would deviate from one note to the next. There was no need to put a hard limit, but changing by a full octave should occur less frequently than changing by a couple of notes. Theoretically, the current code has an even distribution of changes which has been producing pleasing but erratic sounds. That can be tempered.
Instead of relying on a single prandom number of zero to twelve, a series of smaller values numbers can be generated and added. The full range will still be intact, but the results will cluster around an average value. Generating more small numbers will cluster around the middle than generating a couple medium numbers. This can be seen in the spreadsheet below.
Spreadsheet based on ten-thousand iterations of five different patterns
While making the graph, it helped to think of the prandom numbers as dice with different numbers of sides. Unlike the dice these numbers were based on, zero was also a possible "roll" which meant that zero was a possible outcome after all the numbers were generated. Ten-thousand iterations seemed to be the point at which it was likely to get at least instance of zero and twelve after generating a dozen either/or fields.
A day was spent making these graphs to understand the intricacies of the math involved and to make a nifty graph for this blog. I hope it helps understand why this method was used. Another method would have been to use weighting like Peter Kelly describes.
Distribution of prandom results
The rest of the posts for this project have been arranged by date.
First time here?
Completed projects from year 1
Completed projects from year 2
Completed projects from year 3
Completed projects from year 4
Completed projects from year 5
Disclaimer for http://24hourengineer.blogspot.com and 24HourEngineer.com
This disclaimer must be intact and whole. This disclaimer must be included if a project is distributed.
All information in this blog, or linked by this blog, is not to be taken as advice or solicitation. Anyone attempting to replicate, in whole or in part, is responsible for the outcome and procedure. Any loss of functionality, money, property or similar, is the responsibility of those involved in the replication.
All digital communication regarding the email address 24hourengineer@gmail.com becomes the intellectual property of Brian McEvoy. Any information contained within these messages may be distributed or retained at the discretion of Brian McEvoy. Any email sent to this address, or any email account owned by Brian McEvoy, cannot be used to claim property or assets.
Comments to the blog may be utilized or erased at the discretion of the owner. No one posting may claim property or assets based on their post.
This blog, including pictures and text, is copyright to Brian McEvoy.
2019-03-02
Comments
Post a Comment