Boost logo

Boost :

From: degski (degski_at_[hidden])
Date: 2020-06-25 11:31:10


On Thu, 25 Jun 2020 at 03:24, <pbristow_at_[hidden]> wrote:

>
>
>
>
> *From:* degski <degski_at_[hidden]>
> *Sent:* 24 June 2020 15:25
> *To:* boost <boost_at_[hidden]>
> *Cc:* Paul A. Bristow <pbristow_at_[hidden]>
> *Subject:* Re: [boost] Boost.Random
>
>
>
>
>
> On Mon, 22 Jun 2020 at 06:59, Paul A Bristow via Boost <
> boost_at_[hidden]> wrote:
>
> Using
>
>
> std::mt19937::result_type(std::chrono::system_clock::now().time_since_epoch().count());
>
> as seed looks nice and 'portable', assuming C++11.
>
> No need to build Boost.Chrono library - the disadvantage that I was trying
> to avoid.
>
> But using random_device looks even simpler, again assuming Standard C++11.
>
> using std::random_device;
> random_device seeder;
> static std::mt19937 generator(seeder());
>
>
>
> This can be better, you should seed the generator with a std::seed_seq,
> which you would seed with the std::random_device.
>
>
>
> If you use sax::aes_random_device non of the above is needed, the seeder
> (can) serve as a CPRNG, with a speed comparable (but faster) than
> std::mt19937_64 (on Windows).
>
>
>
>
> Random zealots seem to have reservations about random_device - and pretty
> much anything?
>
>
>
> As I said before about random zealots!
>
>
>
> I am only testing round tripping of iostream, so true randomness is
> entirely unimportant.
>
> And since the tests take many hours, any time for a randomish seed is also
> of zero concern
>
>
>
>
>
> ps:
>
>
>
> All seem to work at C++11 with latest MSVC, Clang and GCC.
>
>
>
> We almost 2021, C++11 is almost complete on all compilers.
>
>
>
> But not necessarily standard libraries – GCC and Clang fail
> roundtrip/loopback binary > decimal > binary using std::hexfloat ☹
>

C++17 has introduced <charconv>, this does what the old stuff does, but
much better (faster, better (C-) API).

Here your caveat applies, I'm not sure this is in every standard library.
STL has done most of the heavy lifting, as IIRC the MSVC implementation
will be ported to GCC/Clang, when deemed 'finished'. I have not seen any
announcement anywhere, so I guess it's on-going. I think you'll get
std::hexfloat when the respective C++17-STL's have <charconv>.

>
> But Thanks
>
> Paul
>
>
> > -----Original Message-----
> > From: Boost <boost-bounces_at_[hidden]> On Behalf Of Christopher
> Kormanyos via Boost
> > Sent: 20 June 2020 11:41
> > To: Paul A Bristow via Boost <boost_at_[hidden]>
> > Cc: Christopher Kormanyos <e_float_at_[hidden]>
> > Subject: Re: [boost] Boost.Random
> >
> >
> > > So would following the crowd and using time(0)> be simplest?
> > I never liked time(0) for that particular use casebecause in the old
> days it had multiple
> > millisecondresolution and lacked the seed resolution sometimes.
> > I do not know it the code below is best practice,but I usually use some
> kind of variation of below.You
> > can switch system_clock for high_resolution_clock.
> > All this is straight off-the-rack C++11.
> >
> >
> > #include <chrono>
> > #include <iostream>
> > #include <random>
> >
> > // Use time point now seed to get a different set of values each time.
> > const std::mt19937::result_type seed =
> >
> std::mt19937::result_type(std::chrono::system_clock::now().time_since_epoch().count());
> >
> > // uint32_t
> > static std::mt19937 gen(seed);
> >
> > int main()
> > {
> > std::cout << gen() << std::endl;
> > }
> >
> >
> >
> > On Thursday, June 18, 2020, 10:27:27 AM GMT+2, Paul A Bristow via
> Boost <boost_at_[hidden]>
> > wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Boost <boost-bounces_at_[hidden]> On Behalf Of John Maddock
> > > via Boost
> > > Sent: 17 June 2020 18:48
> > > To: Paul A Bristow via Boost <boost_at_[hidden]>
> > > Cc: John Maddock <jz.maddock_at_[hidden]>
> > > Subject: Re: [boost] Boost.Random
> > >
> > >
> > > On 17/06/2020 15:53, Paul A Bristow via Boost wrote:
> > > > I have wanted to use boost::random::random_device; as a seeder for
> my generator.
> > > >
> > > > #include <boost/random/random_device.hpp> // For
> > > > boost::random::random_device; seeder
> > > >
> > > > But using this requires that I link to a library file // LINK :
> > > > fatal error LNK1104: cannot open file
> 'libboost_random-vc142-mt-gd-x64-1_73.lib'
> > > >
> > > > So I have instead used C++ std random device successfully
> > > >
> > > > using std::random_device;
> > > > random_device seeder;
> > > > // Use seeder to get a different set of values each time.
> > > > static boost::random::mt19937 gen(seeder()); // uint32_t
> > > >
> > > > But is there any way I can stick to the Boost version (I imagine
> > > > that it might prove more
> > portable?
> > > > Or is this a delusion?)
> > >
> > > What do you mean by portable? random_device is inherently
> > > non-portable because it's.... random ;)
> >
> > By portable I mean 'works on as many platforms and C++ standard versions
> as possible'.
> >
> > > In many ways this is something that the std:: version does best as the
> > > system implementer knows
> > best
> > > how to implement on their OS. Or you could just link to Boost.Random
> > > of course which would work nearly everywhere too I'm sure.
> >
> > I was just puzzled why Boost.Random needed to *link* when
> std:random_device doesn't appear to. Is
> > it quietly linking to a standard library?
> >
> > Paul
> >
> > PS Thanks for the even-more-random suggestions but I really, really
> don't care how randomly random it
> > is for my application.
> >
> > So would following the crowd and using time(0) be simplest?
> >
> >
> >
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk