I'm programming in C++ for a while now, but I still ask myself what seed does the compiler use...

I'm programming in C++ for a while now, but I still ask myself what seed does the compiler use, when you call rand() without declaring time(NULL)?

Attached: 9ae90277d44a719f5ee795b2738838e5--anime-wolf-girl-anime-cat.jpg (434x423, 33K)

Other urls found in this thread:

en.cppreference.com/w/cpp/numeric/random
cplusplus.com/reference/cstdlib/srand/
pcg-random.org
twitter.com/SFWRedditVideos

google

I couldn't even find this on Stackoverflow.

not your personlel armie

:v)

You shouldn't use rand() if you're using C++, that's a C function.

>i am autistic

C++ has an RNG library that isn't subject to this bullshit. Use it.

1

2

3

It selects from a precomputed table of values. In other words, no seed.

> If rand() is used before any calls to srand(), rand() behaves as if it was seeded with srand(1).

en.cppreference.com/w/cpp/numeric/random

read it.

I was sloppy so it took longer than a minute.
cplusplus.com/reference/cstdlib/srand/
>Ifseedis set to1, the generator is reinitialized to its initial value and produces the same values as before any call torandorsrand.
That means 1 represents the initial seed.
A better source would be the C standard. Page 312
>The srand function uses the argument as a seed for a new sequence of pseudo-random numbers to be returned by subsequent calls to rand. If srand is then called with the same seed value, the sequence of pseudo-random numbers shall be repeated. If rand is called before any calls to srand have been made, the same sequence shall be generated as when srand is first called with a seed value of 1.

If we're gonna be pedantic you asked 'what seed does the compiler use'. The answer would be we can't know because you haven't given us the implementation. The srand function doesn't guarantee that the seed you pass is what rand uses internally in any way. You could imagine it being implemented

void srand(unsigned int seed)
{
internal_seed = seed+5;
}

Then the answer would be 6. That's unlikely. But you shouldn't rely on library implementation details as a principle.

Better yet. Use pcg-random.org
Because they're not slow, not predictable and don't score poorly on randomness tests while remaining very easy to include in your project.
They're not huge and slow to initialize like the std::mt19937 from the standard library.
std::mt19937 has other problems aswell.
For a person who just wants a random number it's the wrong tool for the job.

Thank you!

Tranny

No.

rand() is an inherently broken function family because the language definition doesn't provide any guarantee of actual randomness.

Use a source of actual randomness, like arc4random() or /dev/urandom.

Also I don't mean to mislead. If you're using rand right now and think that's OK it's probably OK.
pcg or other better random number generators is when you have things like random samples to do and you need something fast and very random (biasing can become very obvious in something like raytracing).

rand sucks, if you want random numbers you don't get them, and if you want a deterministic seeded pseudorandom sequence you don't get that across implementations either. It's not worth using in any situation and a real shame that it's part of the C standard library.

wtf does that even mean?

>it's not worth using in any situation
Obviously wrong.
You're just ascribing standards to general programs that aren't there.
>deterministic across implementations
That's very rare to care for might happen in tests and it makes itself obvious there. I would gauge it as far more common to want a fast (in dev time and runtime) seeded generator interface without specific platform suffering.