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 15:48:59

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

>>> An xint::integer which is +infinity or -infinity is more meaningful than
>>> one which is NaN. 
>>
>> Agreed -- but only slightly. It carries one additional bit's worth of
>> meaning, the sign.
> 
> Even if you identify +infinity and -infinity as a single infinity, it
> should *still* mean something different from an NaN.  You might group
> infinity into the class of NaNs, but that doesn't mean that every
> operation which results in an NaN may as well result in an infinity
> (signed or unsigned).  0/0 and sqrt(-1) should evaluate to an NaN (or
> throw); it would be unsettling to evaluate these as infinity.

I guess I'm not explaining myself very well. I was suggesting using the
NaN value as infinity only where you need an infinity value. The only
viable use I've seen suggested for infinity, in this library, is for
unbounded intervals (which I'll address below).

>>> At the very least, you can make more refined calculations and
>>> comparisons with +/-infinity (compared to NaN),
>>
>> Do you have an example where this would make any noticeable difference
>> in XInt?
> 
> Noticeable in what sense?  1/NaN is NaN; 1/+infinity is +0 (or
> 1/infinity is 0 if you don't want signed infinities and zeros).
> Assuming, of course, you allow calculations with NaNs.

Noticeable in the sense that it would make any difference to people
using the library.

>> An interval consists of two points. Setting the lower point to
>> Not-a-Number would work exactly the same as setting it to -infinity.
>> Same with the higher point and +infinity. It wouldn't make any sense to
>> set the lower point to +infinity, or the higher one to -infinity, so the
>> sign doesn't convey any useful information in that case.
> 
> Since NaN compares false to anything else, good luck getting your
> intervals with NaN endpoints to work in any kind of generic setting ;)

Now that's a decent argument for infinity values. Though I'm still not
sure whether they'd ever be used... is there a scientific or
mathematical use of intervals that you can foresee this library being
used for?

>> Not completely. There *are* the two functions that return Not-a-Number
>> as part of their normal operation, not counting the string- and
>> stream-reading functions. As I said on the rationales page of the
>> documentation, I tried using Boost.Optional for those, but it made the
>> library harder for people not already familiar with Boost.Optional to
>> understand. An error code is an idiom that every C or C++ developer
>> already understands well and knows how to deal with.
> 
> Which 2 functions?  invmod and random_prime?  These hardly seem like
> fundamental operations that necessitate this "invasion" into an
> otherwise pure big-integer interface ;) 

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.

> Returning optional values is precisely the raison d'etre of
> Boost.Optional, and you're ending up just building its functionality
> directly into the xint::integer class, so instead of xint::integer,
> we really have a boost::optional< xint::integer >.  I don't like that
> :/  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.

>> Keep going, one more valid argument might be enough to change my mind.
>> :-)
> 
> 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.

>>> Also, why does invmod always return an NaN on an invalid inverse, and
>>> not throw a blockable exception?
>>
>> Because exceptions should, to my mind, be reserved for exceptional
>> behavior -- things that should never happen under normal circumstances,
>> and which demand special handling. Unless the specified modulus is
>> prime, which cannot be trivially determined, invmod is *expected* to
>> discover that some numbers have no inverse for it. That's neither
>> unexpected nor exceptional, and depending on the application, doesn't
>> automatically require special handling.
> 
> I sympathize with this reasoning.  Generally speaking, if the user
> cannot trivially check the preconditions, it could make sense to return
> some kind of error condition rather than throwing.

We finally have agreement, at least on a small part of the problem. :-)
- -- 
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/

iEYEARECAAYFAkuxBCoACgkQp9x9jeZ9/wQReQCeKDNOZgtgk2bquSXc3/9PzkgZ
VfYAoNX7FCbhD8QdT9YCrHI7CnFJaOqB
=LEjB
-----END PGP SIGNATURE-----