Re: [boost] [xint] Boost.XInt formal review
This is not a review, simply a question with regard to the default_random_generator constructor. If I'm reading random.hpp correctly, there is no way for a user to provide the seed value - a useful feature for folks like myself that use PRNGs to model stochastic processes. We frequently need to repeat a particular sequence of 'random numbers'. Any chance the seed could be passed as a parameter defaulted to the existing hard coded time/clock? As long as I'm asking, perhaps the ability to provide a special-purpose generator of our own design? I'd also like to express my appreciation for the effort you've obviously expended on this project. Thank you. Dick Bridges Western Digital Technologies, Inc. The opinions and data in this missive are my own and do not necessarily represent Western Digital positions, strategies, or opinions.
On Thu, 3 Mar 2011 10:14:49 -0800 "Dick Bridges" <Dick.Bridges@wdc.com> wrote:
This is not a review, simply a question with regard to the default_random_generator constructor.
If I'm reading random.hpp correctly, there is no way for a user to provide the seed value - a useful feature for folks like myself that use PRNGs to model stochastic processes. We frequently need to repeat a particular sequence of 'random numbers'. Any chance the seed could be passed as a parameter defaulted to the existing hard coded time/clock?
You're reading it correctly, but those classes are only part of the story -- read on.
As long as I'm asking, perhaps the ability to provide a special-purpose generator of our own design?
You already can. :-) The random.hpp classes are there only for convenience. In all of the few functions that use a random generator, you can substitute any Boost.Random generator class, or any other class that has a similar interface. If you've got specialized random-number-generating hardware, the code will happily work with it, with nothing extra but a simple interface class.
I'd also like to express my appreciation for the effort you've obviously expended on this project.
Thank you.
And thank you as well, the appreciation is greatly appreciated. -- Chad Nelson Oak Circle Software, Inc. * * *
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost- bounces@lists.boost.org] On Behalf Of Chad Nelson Sent: Thursday, March 03, 2011 10:23 PM To: boost@lists.boost.org Subject: Re: [boost] [xint] Boost.XInt formal review
<snip>
As long as I'm asking, perhaps the ability to provide a special-purpose generator of our own design?
You already can. :-) The random.hpp classes are there only for convenience. In all of the few functions that use a random generator, you can substitute any Boost.Random generator class, or any other class that has a similar interface. If you've got specialized random-number- generating hardware, the code will happily work with it, with nothing extra but a simple interface class. </snip>
If I might make a suggestion, the XInt library interface could be simplified by removing all notions of RNG quality (strong, random, etc.) and become more in line with the goal of providing a POD-like data type. On an abstract [carefully avoiding 'generic'] level, an RNG is an RNG is an RNG. One of the problems I see with syntactic candy like 'strong_random_generator' is that it implies the generated values are both cryptographically acceptable and actually random (and verified by the library). IIUC, there is nothing in the library that attempts to verify either. IMHO, the XInt library should make no pretense wrt RNG quality - let the user specify the RNG or use the default (as is now provided by default_random_generator). Dick Bridges Western Digital The opinions and data in this missive are my own and do not necessarily represent the positions, strategies, or opinions of Western Digital.
On Fri, 4 Mar 2011 09:36:03 -0800 "Dick Bridges" <Dick.Bridges@wdc.com> wrote:
As long as I'm asking, perhaps the ability to provide a special-purpose generator of our own design?
You already can. :-) The random.hpp classes are there only for convenience. In all of the few functions that use a random generator, you can substitute any Boost.Random generator class, or any other class that has a similar interface. If you've got specialized random-number- generating hardware, the code will happily work with it, with nothing extra but a simple interface class. </snip>
If I might make a suggestion, the XInt library interface could be simplified by removing all notions of RNG quality (strong, random, etc.) and become more in line with the goal of providing a POD-like data type.
Yes, but it would require pulling Boost.Random into the example code, which would complicate it.
On an abstract [carefully avoiding 'generic'] level, an RNG is an RNG is an RNG. One of the problems I see with syntactic candy like 'strong_random_generator' is that it implies the generated values are both cryptographically acceptable and actually random (and verified by the library). IIUC, there is nothing in the library that attempts to verify either.
The Windows implementation uses the formerly-undocumented RtlGenRandom function, which is what Microsoft's own cryptography library relies on for random numbers. The POSIX implementation uses /dev/urandom, which has well-known strengths and limitations. As an amateur cryptographer, I consider the silence of professional cryptographers on their strengths to be proof enough that they're sufficiently cryptographically strong for most uses. Especially considering the uproar from them a few years ago when a coding mistake made the Debian distribution's generator much weaker for a while.
IMHO, the XInt library should make no pretense wrt RNG quality - let the user specify the RNG or use the default (as is now provided by default_random_generator).
The user can, and in fact must. The default_random_generator was truly a default in earlier iterations of the library, but neither of those classes are used for anything except the example code now. -- Chad Nelson Oak Circle Software, Inc. * * *
Chad Nelson wrote:
"Dick Bridges" <Dick.Bridges@wdc.com> wrote:
If I might make a suggestion, the XInt library interface could be simplified by removing all notions of RNG quality (strong, random, etc.) and become more in line with the goal of providing a POD-like data type.
Yes, but it would require pulling Boost.Random into the example code, which would complicate it.
I don't think that's an unwarranted burden. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Sat, 5 Mar 2011 14:24:18 -0500 "Stewart, Robert" <Robert.Stewart@sig.com> wrote:
Chad Nelson wrote:
If I might make a suggestion, the XInt library interface could be simplified by removing all notions of RNG quality (strong, random, etc.) and become more in line with the goal of providing a POD-like data type.
Yes, but it would require pulling Boost.Random into the example code, which would complicate it.
I don't think that's an unwarranted burden.
Except that extraneous code in examples dilutes their effectiveness, by forcing the person reading them to deal with more code. The extra burden might be small, but it's definitely there. And using Boost.Random properly requires more than the single line of code that those generators do. I've got those classes anyway, from an earlier iteration. No reason to get rid of them if they could still be useful to people using the library. -- Chad Nelson Oak Circle Software, Inc. * * *
Chad Nelson wrote:
"Stewart, Robert" <Robert.Stewart@sig.com> wrote:
Chad Nelson wrote:
If I might make a suggestion, the XInt library interface could be simplified by removing all notions of RNG quality (strong, random, etc.) and become more in line with the goal of providing a POD-like data type.
Yes, but it would require pulling Boost.Random into the example code, which would complicate it.
I don't think that's an unwarranted burden.
Except that extraneous code in examples dilutes their effectiveness, by forcing the person reading them to deal with more code.
That's certainly true, but it applies to your classes, too, only now you must document and maintain them.
The extra burden might be small, but it's definitely there. And using Boost.Random properly requires more than the single line of code that those generators do.
That's a legitimate reason, but then you can make yours part of the example code and document them as helpers that simplify the rest of the example code. That would make the example bigger, but if that code was still factored out into separate, nicely commented files and was merely referenced with a brief explanatory comment in the example, it would permit you to keep the main part of the example simple without making the random code part of the library proper. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Mon, 7 Mar 2011 09:51:43 -0500 "Stewart, Robert" <Robert.Stewart@sig.com> wrote:
Yes, but it would require pulling Boost.Random into the example code, which would complicate it.
I don't think that's an unwarranted burden.
Except that extraneous code in examples dilutes their effectiveness, by forcing the person reading them to deal with more code.
That's certainly true, but it applies to your classes, too, only now you must document and maintain them.
That moves the burden to me. I'm willing to accept that, if it makes the learning curve easier on the person trying to use the library.
The extra burden might be small, but it's definitely there. And using Boost.Random properly requires more than the single line of code that those generators do.
That's a legitimate reason, but then you can make yours part of the example code and document them as helpers that simplify the rest of the example code. That would make the example bigger, but if that code was still factored out into separate, nicely commented files and was merely referenced with a brief explanatory comment in the example, it would permit you to keep the main part of the example simple without making the random code part of the library proper.
And if the random code is separated from the rest of the library and segregated to its own headers, which it almost is already, it can be pulled in with a single #include in both the examples and any client use that deems it sufficient. That's what I'm aiming for right now. -- Chad Nelson Oak Circle Software, Inc. * * *
participants (3)
-
Chad Nelson -
Dick Bridges -
Stewart, Robert