-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/29/2010 01:11 AM, Jeffrey Lee Hellrung, Jr. wrote:
If that's the purpose of your NaN, why limit your set of "special" values to just { NaN }, when under some circumstances returning some representation of infinity (or +infinity or -infinity if you make such a distinction) would be more informative? For example, you can make n/0 for n != 0 result in infinity,
I could, but why? Who needs to know that n/0 is specifically infinity, rather than simply NaN? If you can point out a case where it would help someone more than returning a NaN would, I'll be happy to add it.
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.
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?
constructing intervals where either or both endpoints are +/-infinity, etc.
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.
You might feel that an infinity value belongs in a wrapper class around xint::integer, and I would tend to agree.
I don't see a need for an infinity value at all. It provides no value to any function presently in the library, or any function I can imagine, that isn't already provided by Not-a-Number.
But I would also put the NaN representation in this wrapper class as well, along with the entire exception blocking framework. It seems to me to be orthogonal to the rest of the interface, and if one never uses blocking exceptions, it seems like a waste.
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. I could move the Not-a-Number value and the exception-blocking system to a wrapper, and go back to using Boost.Optional for those two functions, neophyte users be damned. Or have them throw exceptions, though the idea is distasteful to me. But I'm not yet convinced that there's sufficient reason to do so... though I must admit, the idea is appealing from a design perspective, as it would make the interface noticeably more elegant. Scott McMurray's point about the existence of Not-a-Number forcing the library to check for it in all functions is an argument in its favor as well. Keep going, one more valid argument might be enough to change my mind. :-)
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. - -- 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/ iEYEARECAAYFAkuwSY8ACgkQp9x9jeZ9/wQVZwCgwWUcW9WyQOM0ciMSpKD3FZAw Jr4AoMansGdn95HXYaMTUHPkDJHMND/x =Z7xK -----END PGP SIGNATURE-----