Yes, they repeat, but the next time "347" repeats - "6739" won't be beside it, right?
Saving the number of times you call the PRNG wouldn't be smarter because it'd still generate new numbers the same way.
Yes, they repeat, but the next time "347" repeats - "6739" won't be beside it, right?
Saving the number of times you call the PRNG wouldn't be smarter because it'd still generate new numbers the same way.
Last edited by ADVANCESSSS; 01-05-2016 at 03:24 AM.
Your C++ "instructor" might know C++, but he/she apparently does not know or forgot that such PRNGs are periodic: eventually the sequence will repeat. In the case of your PRNG, the sequence will repeat after exactly 32768 calls to the PRNG function. So, you can indeed "infinitely" obtain numbers from the PRNG, but after some point they won't be "new".Originally Posted by ADVANCESSSS
After you have gone through the sequence that constitutes the period, then after "347" repeats, "6739" will indeed be beside it, if such a consecutive pair exists. In your case, it is actually 23070, 27857, 22756, ... (at least for me, since the range of unsigned int is implementation defined).Originally Posted by ADVANCESSSS
Last edited by laserlight; 01-05-2016 at 03:25 AM.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Well he didn't exactly say that, I assumed that by math done on the new numbers will always give new numbers.
And now, I tell you the Clock Date Time is exactly this 3rd way! Think about it, their using a computer to always increment the number and do math on it to always make new number!! So there really is two ways only - from time OR sensors, but REALLY only 1 way for randoms - particles affecting other particles.
Agree now ^?
Don't bet too much money on that assumptionCode:// Take the current seed and generate a new value from it // Due to our use of large constants and overflow, it would be // very hard for someone to predict what the next number is // going to be from the previous one.
I will prove these below ARE all ways to generate guesses (also note I said above that all 3 ways are just particles affecting other particles):
1. From sensors.
2. Increment the number up by 1, repeat. Underneath way 3 is a program that always makes a new number by adding 1 to it!
3. Do math with the incrementing number so instead of it get larger it changes a few things like the clock date does ex. 1970 01 1 12:00 & today is 2016 01 05 12:00.
Code:#include <iostream> #include <cstdlib> using namespace std; int main() { int outer = 1; while (outer <= 5) { int inner = 1; while (inner <= outer) { cout << inner++ << " "; ++outer; } } return 0; }
This reminds me!
Hodor Wears Shoes
But it's truuuuuuuue, sensors will always return a new input while it's moving around, incrementing a number up makes a NEW number on my screen each increment (program is above), and doing math on it makes a smaller compact new one like the clock date.
Guys.....^
Do you have a question or some point of discussion that merits you bumping the post with "Guys.....^"?
The only thing I see from you that might be worth discussing is the claim that "incrementing a number up makes a NEW number on my screen each increment (program is above), and doing math on it makes a smaller compact new one like the clock date", but if such a method serves your purposes, go for it. After all, depending on what you want to do a monotonically increasing integer could work, or a very lousy PRNG could work, or maybe you need a better PRNG, or maybe you need a cryptographically secure PRNG.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Yes, you/s said earlier that I'm wrong but I explained you can get new randoms (to make the robot receive always *new motor signals) by either:
Having a number keep incrementing up by 1.
Do math with it to keep its length down, like the clock time date does!
Or from sensors (while it moves from the first image's 0s&1s), always giving you new vision/ect's 0s&1s.
And that all 3 are the same way - particles affecting other particles giving "randoms" when really even they were "coming" as destiny to its sensors just like computers always execute the same program(without touching it/generating randoms). It's all particles working! Ah science.
Last edited by ADVANCESSSS; 01-07-2016 at 12:27 AM.
You were wrong in your assumption that you presented "a working 3rd way to get random numbers".Originally Posted by ADVANCESSSS
Now, you are basically saying: seed the PRNG with a new seed on each run unrelated to the pseudorandom numbers generated from previous runs. This still is not "a working 3rd way to get random numbers", but it is a valid approach, and it is why people often use a seed based on the current time: as long as the current time value is of sufficient granularity, it is reasonable to assume that the resulting seed will be different from those used in the previous couple of runs, so the results will probably appear random rather than a repeat of the previous runs. You might imagine this as having a long sequence of random numbers: as long as you start at a different point and do not use too many of the numbers per run, it will look like you are sourcing from a different sequence of random numbers on each run.
This may actually be your best bet, depending on the sensor data, if you want "real" random numbers. In practice, "real" random numbers are obtained by sensors, whether through observing radioactive decay, or more mundane things like observing random aspects of hardware, or even random keystrokes (though I think studies have shown that humans may not be quite as random as we like when it comes to random keystrokes).Originally Posted by ADVANCESSSS
Of course, instead of directly using this random source, you can seed a PRNG with it.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
I agree yes yes.
Ok I'm starting a new thread for a new problem~question and if I have anymore "my c++ progess" presentations or questions if such goes here then I'll ask/show them here, (probably leaving this thread).
Good but little confusing since its include hardware as well. Could be done in alternate way.
Let's say main() call's dbl(). dbl() does not necessarily have access to wherever main wants to use or store the return value. It is the job of return to move any value, computed immediately or stored somewhere in dbl(), to a location that main() can also read from.