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 02:32:51

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