Re: [boost] New Boost.XInt Library, request preliminary review

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-03-29 01:40:08

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/29/2010 12:57 AM, Scott McMurray wrote:

> You advocate Signalling NaNs.  That means that you haven't actually
> made your checking any easier by blocking exceptions, because if you
> pass a result to anything else, it still needs to be checked. 

When it's possible that you've gotten a Not-a-Number value. As I've said
before, those can only be returned by a small number of functions, even
if you're blocking exceptions.

> Since you said earlier that the most complicated 
> look-before-you-leap[1] check required to avoid an exception is "x <
> 0", I fail to see the advantage, since there's just as much code 
> required and no speed advantage.  In fact, there may well be a speed 
> disadvantage, since now every single function that takes in an XInt 
> has to check "x.isNaN()" before doing anything.

An unavoidable consequence of having a Not-a-Number value. Fortunately,
the check is extremely fast.

> In fact, the only place where couple-leaping-with-looking[2] is
> advantageous is the overflow exception, so that's the only one where
> being able to block it could make a substantial readability
> improvement in my code.

It might improve individual checks, but there would have to be a lot
more of them. And the overflow exception should be extremely rare on
modern systems, unless you're using a staggering number of unbelievably
large numbers.

> (Quiet NaNs may as well, since I could check once at the end instead
> of before every function call that throws when given a signalling
> NaN.)

Now that's a valid argument, and it might be strong enough to outweigh
my logical-return-values complaint. I don't have a strong objection to
making the not_a_number exception blockable -- give me a reasonably
non-contrived example where having it would make code more readable, and
I'll find a way to make it happen.

>> There's no other logical response if there's no cryptographically-secure
>> random number generator, and the user asks the library to instantiate
>> one. (That's not in the version that was uploaded to the Boost Vault
>> yet.) And it's debatable whether there's any other consistent and
>> mathematically logical way to handle passing Not-a-Number values to
>> functions that return anything but xint::integers.
> 
> There are at least 2 other possibilities:
> 1) Prevent it from compiling in the first place

Not acceptable. I want it to be easily portable, which means it has to
compile even if the machine doesn't support any cryptographically-secure
random number generator that the library recognizes. The developer using
it can always plug in a generator that gets entropy from something the
library doesn't know about, like an Internet site dedicated to that,
after all -- they do exist.

> 2) Block until you have the required entropy

XInt isn't in the business of providing random numbers, the random
number system in it is there solely for the random prime number
generation facility. Gathering entropy isn't part of its job
description. That may not be obvious from the version in the Boost Vault
at present, but it will be with the next iteration.

> Or the I'm-not-even-counting-it option of having the function default
> to an insecure RNG like Mersenne Twister...

Which is exactly what the library did in the current Vault version. The
as-yet-unreleased version throws an exception, because that is an
exceptional circumstance, and one that the developer must not ignore.
- -- 
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/

iEYEARECAAYFAkuwPTUACgkQp9x9jeZ9/wQk1gCfecl2Gwv0clT9hDf6kBnNALBQ
1hwAoNnZdaDgUWp7alOMI/CBvAb5lyaj
=icpx
-----END PGP SIGNATURE-----