問題描述
我對 c++11 隨機庫有點困惑.
我的理解:我們需要兩個獨立的概念:
- 隨機引擎(可以是偽(需要種子)或真實的)
- 分布:它使用特定分布將從引擎獲得的數字映射到特定區間.
我不明白為什么不直接使用這個:
std::random_device rd;std::uniform_int_distribution分布(1, 5)；//獲取隨機數:區(rd)； 據我所知這很有效.
相反，這是我在大多數示例/網站/文章中發現的:
std::random_device rd;std::mt19937 e{rd()};//或 std::default_random_engine e{rd()};std::uniform_int_distribution距離{1, 5};//獲取隨機數:分布(e)； 我不是在談論特殊用途，例如密碼學，只是您的基本入門文章.
我的懷疑是因為 std::mt19937(或 std::default_random_engine)接受種子，通過在調試期間提供相同的種子可以更容易地調試會話.
另外，為什么不只是:
std::mt19937 e{std::random_device{}()};另外，為什么不只是:
std::mt19937 e{std::random_device{}()};
如果你只做一次可能沒問題，但如果你會做很多次，最好跟蹤你的 std::random_device 并且不要不必要地創建/銷毀它.
查看 std::random_device 實現的 libc++ 源代碼可能會有所幫助，它非常簡單.它只是對 std::fopen("/dev/urandom") 的一個薄包裝.因此，每次創建 std::random_device 時，您都會獲得另一個文件系統句柄，并支付所有相關費用.
據我所知，在 Windows 上，std::random_device 代表對微軟加密 API 的一些調用，因此每次執行此操作時，您都將初始化和銷毀??一些加密庫接口.>
這取決于您的應用程序，但出于一般目的，我不會認為這種開銷總是可以忽略不計.有時是這樣，然后這很棒.
我想這與您的第一個問題有關:
<塊引用>相反，這是我在大多數示例/網站/文章中發現的:
std::random_device rd;std::mt19937 e{rd()};//或 std::default_random_engine e{rd()};std::uniform_int_distribution距離{1, 5}; 至少我是這么認為的:
std::mt19937是一個非常簡單可靠的隨機生成器.它是獨立的，將完全存在于您的進程中，不會調用操作系統或其他任何東西.該實現由標準強制，至少在 boost 中，它在任何地方都使用相同的代碼，源自原始的mt19937論文.這段代碼非常穩定，而且是跨平臺的.您可以非常確信，初始化、查詢等將在您編譯它的任何平臺上編譯為類似的代碼，并且您將獲得類似的性能.std::random_device相比之下，它是相當不透明的.你并不真正知道它是什么，它會做什么，或者它的效率如何.你甚至不知道它是否真的可以被獲取——當你嘗試創建它時它可能會拋出異常.你知道它不需要種子.您通常不應該從中提取大量數據，只需使用它來生成種子即可.有時，它充當加密 API 的一個很好的接口，但實際上并不需要這樣做，遺憾的是有時也不需要.它可能對應于 unix 上的/dev/random，也可能對應于/dev/urandom/.它可能對應于某些 MSVC 加密 API(visual studio)，或者它可能只是一個固定常量(mingw).如果您為某些手機進行交叉編譯，誰知道它會做什么.(即使您確實獲得了/dev/random，您仍然會遇到性能可能不一致 的問題——它可能看起來工作得很好，直到熵池用完，然后像狗一樣慢.)
我的想法是，std::random_device 應該是 time(NULL) 播種的改進版本——這是一個低標準，因為 time(NULL) 是一個非常糟糕的種子.我通常在我會使用 time(NULL) 生成種子的地方使用它，回到當天.除此之外，我真的不認為它有什么用處.
I am a bit confused about the c++11 random library.
What I understand: we need two separate concepts:
- random engine (which can be pseudo (need seed) or real)
- distribution: it maps the numbers obtained from the engine to a specific interval, using a specific distribution.
What I don't understand is why not just use this:
std::random_device rd;
std::uniform_int_distribution<int> dist(1, 5);
// get random numbers with:
dist(rd);
As far as I can tell this works well.
Instead, this is what I found on most examples/sites/articles:
std::random_device rd;
std::mt19937 e{rd()}; // or std::default_random_engine e{rd()};
std::uniform_int_distribution<int> dist{1, 5};
// get random numbers with:
dist(e);
I am not talking about special use, e.g. cryptography, just your basic getting started articles.
My suspicion is because std::mt19937 (or std::default_random_engine) accepts a seed, it can be easier to debug by providing the same seed during a debug session.
Also, why not just:
std::mt19937 e{std::random_device{}()};
Also, why not just:
std::mt19937 e{std::random_device{}()};
It might be fine if you only will do this once, but if you will do it many times, it's better to keep track of your std::random_device and not create / destroy it unnecessarily.
It may be helpful to look at the libc++ source code for implementation of std::random_device, which is quite simple. It's just a thin wrapper over std::fopen("/dev/urandom"). So each time you create a std::random_device you are getting another filesystem handle, and pay all associated costs.
On windows, as I understand, std::random_device represents some call to a microsoft crypto API, so you are going to be initializing and destroying some crypto library interface everytime you do this.
It depends on your application, but for general purposes I wouldn't think of this overhead as always negligible. Sometimes it is, and then this is great.
I guess this ties back into your first question:
Instead, this is what I found on most examples/sites/articles:
std::random_device rd;
std::mt19937 e{rd()}; // or std::default_random_engine e{rd()};
std::uniform_int_distribution<int> dist{1, 5};
At least the way I think about it is:
std::mt19937is a very simple and reliable random generator. It is self-contained and will live entirely in your process, not calling out to the OS or anything else. The implementation is mandated by the standard, and at least in boost, it used the same code everywhere, derived from the originalmt19937paper. This code is very stable and it's cross-platform. You can be pretty confident that initializing it, querying from it, etc. is going to compile to similar code on any platform that you compile it on, and that you will get similar performance.std::random_deviceby contrast is pretty opaque. You don't really know exactly what it is, what it's going to do, or how efficient it will be. You don't even know if it can actually be acquired -- it might throw an exception when you attempt to create it. You know that it doesn't require a seed. You're not usually supposed to pull tons and tons of data from it, just use it to generate seeds. Sometimes, it acts as a nice interface to cryptographic APIs, but it's not actually required to do that and sadly sometimes it doesn't. It might correspond to/dev/randomon unix, it might correspond to/dev/urandom/. It might correspond to some MSVC crypto API (visual studio), or it might just be a fixed constant (mingw). If you cross-compile for some phone, who knows what it will do. (And even when you do get/dev/random, you still have the problem that performance may not be consistent -- it may appear to work great, until the entropy pool runs out, and then it runs slow as a dog.)
The way I think about it is, std::random_device is supposed to be like an improved version of seeding with time(NULL) -- that's a low bar, because time(NULL) is a pretty crappy seed all things considered. I usually use it where I would have used time(NULL) to generate a seed, back in the day. I don't really consider it all that useful outside of that.
這篇關于為什么不直接使用random_device?的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！