I'm still not over this. In addition to UB the Verilog $random C code also relies on some IDB. 1/https://twitter.com/oe1cxw/status/870972176421330945 …
-
-
Replying to @oe1cxw
Namely it assumes that "long" is 32 bits wide and that "float" is using the IEEE binary32 format.
2 replies 0 retweets 1 like -
Replying to @oe1cxw
The latter is ridiculous considering that this is a function that has only integers as in- and outputs! (old seed, new seed, rand val)
1 reply 0 retweets 0 likes -
Replying to @oe1cxw
But internally it first creates a uniformly distributed float random value in range (INT_MIN INT_MAX) and then converts that one to an int.
2 replies 0 retweets 0 likes -
Replying to @oe1cxw
But (of course!) that random float value is in turn generated from the "true" rng value, which is the new 32 bit seed.
1 reply 0 retweets 0 likes -
Replying to @oe1cxw
I completely fail to understand how anyone could ever under any circumstances have thought that any of that is a good idea.
1 reply 0 retweets 1 like -
Replying to @oe1cxw
Here is the code directly from IEEE Std. 1364-2001. Because I probably wouldn't believe it if someone just told me how bad it is.pic.twitter.com/1kZnzksyMg
3 replies 4 retweets 5 likes -
Replying to @oe1cxw
Of course this also has horrible properties as a RNG. For example, the following property holds when using a std conforming implementation:pic.twitter.com/s3vg1jxnRb
2 replies 2 retweets 4 likes
Of course no formal Verilog tool would model the brokenness of $random. But here is a CBMC proof for that claim: http://svn.clifford.at/handicraft/2014/vlogrnd/vlogrnd.c …
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.