The bell has tolled for rand()
cpp.indi.frih.net
The bell has tolled for rand()
1–10 of 44 posts
Re: The bell has tolled for rand()
#2Not to focus on a question unrelated to this blog post's point, but
* "auto main() -> int" could be just "int main()".
* "auto v = vector(20);" could be just "vector v(20)".
* "auto print_value = [](auto&& v)" could be (I'd argue should be) "auto print_value = [](const auto& v)".
"auto" is useful, "auto" is great. But "auto" is not an end in and of itself.
(Bring on the C++(11) haters, blah blah.)
Re: The bell has tolled for rand()
#3[deleted]
Re: The bell has tolled for rand()
#4"(not to be confused with std::mem_fn() – not the dropped ‘u’)" -- note the dropped 'e'.
Re: The bell has tolled for rand()
#5"The C random library has always been… to put it politely… less than ideal. Okay, it’s pretty fucking horrible. It’s so bad that the C standard itself suggests you’d be better off not using it."
Back in the days 4.2 BSD or so, the BUGS section of the manual entry for rand understatedly mansplained that it had "bad spectral characteristics". In fact, it was so bad that the lower bit alternated between 0 and 1 every time you called it. Hard to miss that bright line on a spectrogram.
If you couldn't figure out what to expect from such a forthright disclosure in the manual, then you were in for quite a shock when you did the obvious thing and tried to use "rand() & 1" to simulate flipping a coin!
Re: The bell has tolled for rand()
#6"The C random library has always been… to put it politely… less than ideal. Okay, it’s pretty fucking horrible. It’s so bad that the C standard itself suggests you’d be better off not using it." Back in the days 4.2 BSD or so, the BUGS section of the manual entry for rand understatedly mansplained that it had "bad spectral characteristics". In fact, it was so bad that the lower bit alternated between 0 and 1 every ti…
> manual entry for rand understatedly mansplained
Heh, I see what you did there, but the downvotes imply others didn't.
Re: The bell has tolled for rand()
#7Not to focus on a question unrelated to this blog post's point, but * "auto main() -> int" could be just "int main()". * "auto v = vector (20);" could be just "vector v(20)". * "auto print_value = [](auto&& v)" could be (I'd argue should be) "auto print_value = [](const auto& v)". "auto" is useful, "auto" is great. But "auto" is not an end in and of itself. (Bring on the C++(11) haters, blah blah.)
I'm not convinced auto should ever be used for anything other than iterators and anonymous types. There are other instances where it's relatively fine to use. Perhaps a few where it's even slightly better to use. But in C++11 I think it's by far best to limit it to there be explicit cases I mentioned.
In C++14 I'll extend support to lambdas in some cases but will need to experiment to say for sure.
Re: The bell has tolled for rand()
#8"The C random library has always been… to put it politely… less than ideal. Okay, it’s pretty fucking horrible. It’s so bad that the C standard itself suggests you’d be better off not using it." Back in the days 4.2 BSD or so, the BUGS section of the manual entry for rand understatedly mansplained that it had "bad spectral characteristics". In fact, it was so bad that the lower bit alternated between 0 and 1 every ti…
> manual entry for rand understatedly mansplained Heh, I see what you did there, but the downvotes imply others didn't.
Presumably "man" for "manpages".
Re: The bell has tolled for rand()
#9"The C random library has always been… to put it politely… less than ideal. Okay, it’s pretty fucking horrible. It’s so bad that the C standard itself suggests you’d be better off not using it." Back in the days 4.2 BSD or so, the BUGS section of the manual entry for rand understatedly mansplained that it had "bad spectral characteristics". In fact, it was so bad that the lower bit alternated between 0 and 1 every ti…
If I were to use C, what should I be using instead of rand(3)?
A cursory look at rand(3) SEE ALSO hints at candidates but random(3) seems to hardly fare better†, arc4random(3) isn't available on glibc.
† A few notes about rand as the parent suggests, but nothing regarding mod bias, srandom initial state, or threads:
> It returns successive pseudo-random numbers in the range from 0 to (231)-1. The period of this random number generator is very large, approximately 16((2*31)-1).
> All of the bits generated by random() are usable. For example, `random()&01' will produce a random binary value.
Re: The bell has tolled for rand()
#10Earlier quoted context omitted.
> manual entry for rand understatedly mansplained Heh, I see what you did there, but the downvotes imply others didn't.
Presumably "man" for "manpages".
Probably part that, part joking reference to the term as used outside computing (see http://www.urbandictionary.com/define.php?term=Mansplain).
I guess the idea is that manual pages can sometimes seem to be intentionally obscure, and kind of proud of it. I don't have an example handy, nor am I even sure I agree, but I think I got the joke, at least. :)