![]() ![]() The cookie is used to store the user consent for the cookies in the category "Performance". This cookie is set by GDPR Cookie Consent plugin. ![]() The cookie is used to store the user consent for the cookies in the category "Other. ![]() The cookies is used to store the user consent for the cookies in the category "Necessary". The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". ![]() The cookie is used to store the user consent for the cookies in the category "Analytics". These cookies ensure basic functionalities and security features of the website, anonymously. Necessary cookies are absolutely essential for the website to function properly. What we don't want to see is something that looks like the following, for example: What we would like to see would be an arbitrary distribution that is relatively evenly distributed across our 1000 x 1000 canvas. So, now that I have my 1,000 comma-separated X-Y pairs, what do I want to do with them? Well, the obvious first-pass option is to generate a scatter plot and observe the result. You can Click Here to access these values if you want to play with them yourself (see also the discussions below). I then copied my 1,000 comma-separated X-Y pairs out of the Arduino IDE's Serial Monitor window and saved them in a NotePad *.txt file. If you do, you might care to note that I'm trying to follow the guidelines espoused in the Embedded C Coding Standard by Michael Barr (or, at least, the guidelines I find to be most applicable to what I'm doing). You can Click Here to see the full code (such as it is). The core of this code is as follows: for (int i = 0 i < 1000 i++) In order to test this, I threw a simple program together that loops around creating 1000 X-Y pairs where each X and Y value is a randomly generated integer between 1 and 1,000. We'd all feel slightly silly if we ended up seeing only a tiny amount of yellow, and we subsequently discovered that the vast majority of our “random” (1 to 1,000) numbers actually resided predominantly in the 300 to 700 range. The idea being that (over time and using these values) each LED will spend 50% of its time red, 30% of its time orange, and 20% of its time yellow.īut this only works if the random() function is truly - or, at least, reasonably - random. One way to do this would be to generate a series of random numbers between say 1 and 1,000, and to then say that any number from 1 to 500 equates to red, any number from 501 to 800 equates to orange, and any number from 801 to 1000 equates to yellow. Let's further suppose that we want to weight things such that red is the predominant color, followed by orange, followed by yellow. Suppose, for example, that I wish the various NeoPixel elements forming my fire to randomly switch between red, orange, and yellow (we'll also want to vary their brightness and duration, but let's not get ahead of ourselves). Call me an old fuddy-duddy if you will, but this is the sort of thing that is easy to take for granted, only to be unpleasantly surprised somewhere down the line. Of course, the Arduino does come equipped with a handy-dandy random() function, which is just what I need… assuming that this little scamp does indeed generate random numbers. The HRNG/TRNG level of super-randomness is great for applications like cryptography, but it's probably overkill for what I'm doing, not the least that I don't want to spend the time building one. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |