-----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-----