-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/30/2010 07:13 AM, Stewart, Robert wrote:
I have to disagree, only because one of the main reasons people want to use a large-integer library is for cryptography, and those two functions *are* fundamental to that.
"One of the main reasons," not "the only" reason. Hence, cryptography functionality, which surely is more than those two functions, should be in a separate library.
I'm sure it should. But those two functions should not.
What did you find about Boost.Optional that was difficult for users to understand?
That it acts like a pointer but isn't one. Less experienced developers often find even pointer syntax hard to master, and unfortunately, they are the majority of programmers. I was trying to make it as easy as possible for anyone, no matter what their level of experience, to use.
This is being proposed as a Boost library. We can assume enough knowledge to use Boost.Optional, which isn't great.
Knowledge and patience are two things that I've learned never to assume that a would-be programmer has.
The interface to invmod and random_prime should be built around the interface of xint::integer, not the other way around.
Sorry, not good enough. They're an important part of the interface, and their requirements affect it too.
That's not a sufficient reason for their inclusion in a big integer library. Rather, the big integer library needs to be designed well to support those functions and many others.
invmod is a basic modular math function. random_prime is a basic requirement for the most common reason people would want the library. They belong there, and they stay. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuyAhIACgkQp9x9jeZ9/wQDpgCgwOXpAHKdTHqTcKF2HGJScJ8B HFYAoJtfsFU+tmdKRr3mykj7uSQyVdcY =Zd4D -----END PGP SIGNATURE-----