You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Another idea to shuffle an array
Another idea to shuffle an array
I am VERY HAPPY about your 15lines of CODES which is very EXACT of what I need. I give you two thumbs up for sharing this ideas and knowledge. attached file are sample print-out. happy coding.
The Fisher-Yates algorithm is also a well-know method to shuffle an array:
Edit:
https://www.mql5.com/en/forum/58547
I am VERY HAPPY about your 15lines of CODES which is very EXACT of what I need. I give you two thumbs up for sharing this ideas and knowledge. attached file are sample print-out. happy coding.
Hi Dominik
I have tested it before and I can confirm, that modulo bias does not affect the shuffle algorithm much. The unbiasness of the RNG used is not as important as unbiasness of the shuffle algorithm itself.
Here is a nice website to compare several shuffle algorithms using matrix diagrams. https://bost.ocks.org/mike/shuffle/compare.html
No matter the randomnes given, as its underlying data input, you will have a significant effect, I would say we all agree, MathRand() is the input to control the behaviour of the "algorithm" (here a for loop).
Then, no matter what you do, the arising behaviour is given by the input. So here we will use the next higher 0x02 to the power of 0d04 resulting in 0d00 to 0d15 in decimal (Base10). So when using modulo on this input will wrap around at 16. Since we need to wrap 0d10 numbers around to cover 0d16 numbers in "space" you get exactly 4 overlapping, therefore the numbers from 0d00 to 0d05 will significantly more often selected. As you can see, this will lead to the fact, that higher elements in the array, (Here the length of the generated password) will not be selected as often for a candidate as the numbers, or elements in the array, between 0d00 and 0d05.
Concerning the quality of the algorithm.
No matter the randomnes given, as its underlying data input, you will have a significant effect, I would say we all agree, MathRand() is the input to control the behaviour of the "algorithm" (here a for loop).
Then, no matter what you do, the arising behaviour is given by the input. So here we will use the next higher 0x02 to the power of 0d04 resulting in 0d00 to 0d15 in decimal (Base10). So when using modulo on this input will wrap around at 16. Since we need to wrap 0d10 numbers around to cover 0d16 numbers in "space" you get exactly 4 overlapping, therefore the numbers from 0d00 to 0d05 will significantly more often selected. As you can see, this will lead to the fact, that higher elements in the array, (Here the length of the generated password) will not be selected as often for a candidate as the numbers, or elements in the array, between 0d00 and 0d05.
Concerning the quality of the algorithm.
The real issue with MathRand() is its limited range, it cannot shuffle arrays > 32768 elements effectively.
You can use my implementation for pcg32 generator to shuffle larger arrays. https://www.mql5.com/en/code/25843
Edit: A really good article on wikipedia https://www.wikiwand.com/en/Fisher%E2%80%93Yates_shuffle
As the Wikipedia Article points out how random numbers are selected in the algorithm, this is not reflected in the upper function. The here shown code always uses 10.
But independent of this issue, in fact, yes only 2^15 is possible. This is a quite poor granularity.
To remove the bias from the upper code, I suggest doing it following:
(10.0 / MathRand())
As your index calculation.
You would use it like: ArrayShuffle( {0,1,2,3,4,5,6,7,8,9} ). BTW, granularity is not a technical term. Period means the range of RNG, and precision of floating-point number.