Hi guys here is my question:
Can the stack overflow error affects the result of a random number generator? 
In the example the 2 number boxes in loop produce a result which is different to the one which is well connected. Therefore, is it possible randomize results taking advantage of a stack overflow? Also, how this error could affect negatively the system?
Thanks in advance,
Matteo
-
Can the stack overflow error affect the result of a random number generator?
-
@deframmentazione-geometrica Stack overflow is basically an error message that tells you there is an endless loop in the patch (in your case, it comes from the two atom boxes at the bottom). The way these atom boxes are patched together is weird and the reason you're getting different values is most likely due to the order in which you have made the connections. I wouldn't rely on this method at all. What are you trying to achieve? It's very possible that there are other solutions.
-
I intentionally patched the number boxes in that way in order to make the overflow happen. I'm wondering if I can get random results due to the malfuntioning of the stack, doesn't matter if is not healthy to the system.
-
@deframmentazione-geometrica Perhaps so, but I wouldn't know how or why it behaves the way it does.
-
The stack overflow is still going to be triggered deterministically, so I don't think that's going to work.
-
@deframmentazione-geometrica And then it depends whether you are looking for the correct distribution (chance for each and every value) in which case a PRNG is the way to go. What meaning are you giving to the word "random"?
A PRNG is seeded, and deterministic, and like the uncertainty principle......... you know that every value will occur.... but not when it will occur (well... you do, but you will not remember!).I messed around with this a bit........ true random.zip
[truish-random] sets the seed for [random] as the patch is loaded..... according to the computer time.
This avoids the "problem" that [random] gives the same sequence at every new start because it is "seeded" by $0 (probably). [random] is a series, "played" according to the seed.[true-random] uses the [noise~] object. This is still deterministic, probably preserves the distribution, but it will be hard for a human to spot any pattern.
You could mix in some background noise from your computer microphone. That would be considerably less deterministic (lets not discuss the universe) but ruin "equal chance" in the human time frame.David.
-
Thank you all for your time, it helped clear things up for me.
-
@jancsika said:
The stack overflow is still going to be triggered deterministically, so I don't think that's going to work.
Sure it is triggered deterministically, but I would like to know the underline reason why the result of the 2 number box in loop is different to the single one? Can anyone explain me why? Thanks
-
@deframmentazione-geometrica It looks like your select box is trying to prevent repeat values from getting through, so when random outputs the same value as it did previously, select will keep telling random to produce another value until it's different, then it'll assign that to the single number box on the right. The two number boxes at the bottom will retain the duplicate value and continue to reassign the value to each other until it's caught by the stack overflow error.
Then again, how everything plays out will depend on whether you create the select box before or after creating the looped number boxes at the bottom, because that'll determine what gets triggered first. If you create the select box last, then the number boxes at the bottom will change and it may never even get to the number box on the right.
-
Can anyone explain me why?
The stack overflow detector counts the number of outlets that are triggered by a message. If the first outlet ends up immediately triggering another outlet further down the chain, that counts as 2, and so on until the bottom of the object chain is reached. When it hits the bottom of the object chain each outlet that forwarded on the message finishes up and subtracts from the total to get back to zero.
If the total count exceeds a hard-coded limit, then Pd sends the stack overflow message. One easy way to hit the limit is to feed an outlet at the bottom of the chain back into the top. Pd uses the limit to keep the operating system's stack from overflowing and crashing the program.
Quite simply-- you get a different behavior because you're adding an object to your recursive object chain. If you start a recursive loop with a different number of objects, you'll get different behavior as to where exactly the loop stops when you hit the limit.
