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-04-08 13:48:14

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

On 04/07/2010 05:04 PM, Joachim Faulhaber wrote:

>> 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?
> 
> Hi Chad,
> 
> as an author of a library of intervals and interval containers, I have
> encountered places in my library design, where infinity values not
> only seemed to be useful but also appeared to be a "natural" solution.
> [...]

That makes sense. Thank you for the information.

> While these use cases seem to provide good reasons to introduce
> infinity values for integral numbers, I never had any use for "not a
> number" values. Contrary to infinities that are a part both of natural
> and mathematical language, not-a-number values appear pretty bizarr to
> me ... Their meaning is a contradiction in itself and their properties
> are non-intuitive.
> 
> Meanwhile I doubt the usefulness of both of them, NaN and Infinity, on
> fundamental numeric types. Since there is the IEEE 754 for floating
> point numbers that proposes them, there is probably a vast amount of
> mathematical and numerical expert knowledge that this standard is
> based on. But my gut feeling is different.

Coming from the background of a pretty good developer, but only a
mediocre mathematician, it seems to me that the NaN value was added to
floating-point types for basically the same reason that it's now used in
XInt: to avoid throwing an exception. It's a lot more important for the
floating-point type than for XInt though, since floating-point numbers
are basic types that have to work in any language.

> I think, the values of a numeric types should be
> (1) closed under their fundamental operations e.g. +.
> (2) Their values should be reachable from the initial value 0 or T()
> applying (fundamental) operations.

I'm not sure what your first point means, but I think I agree, for the
most part.

> Where operations are not defined like y/0, instead of introducing NaN,
> the undefined case should be guarded against by
> (1) program logic (asserts) or
> (2) denominator checks, if the condition can not be determined from
> the program logic otherwise.

Which is exactly what the library does, under normal circumstances (i.e.
when exceptions aren't blocked).

> Neither NaN nor +/-Inf can be computed from 0 using fundamental
> operations like ++, +, -- and -. But the user can assign them to
> variables
> 
> integer myNaN = integer(not_a_number());
> 
> and pass them to any operation that is provided by your type. So you
> have to check for NaN in every single function you implement. IIUC you
> provide NaN as emergency result for 3 functions only. Neither of these
> is fundamental to integral types. I don't think these functions
> justify to spoil the whole type with NaNs.

As a matter of fact, those functions no longer use the Not-a-Number
value in the current code. They now return zero as a failure value,
since I was shown that zero isn't a valid response for either of them.

> My be it would be more interesting to provide the minimal and "pure"
> numeric type

Already done, in the version currently in the sandbox. There are now two
separate types; the one in the core namespace is the pure one.

> and provide a NaN and Infinity closure as template
> 
> template<class IntegralT, class ClosureTraits=...> closed { ... }
> 
> because the way in which NaNs, Infinities (and maybe more special
> values) are handled should be the same for all the different
> implementations of integral numeric types.

I'm not sure what you mean by "a NaN and Infinity closure". I understand
templates, and I think I understand closures (at least as provided by
languages like Lisp), but I can't make out what you're trying to say
there. Is that a C++0x (or C++1x, now) thing?

(I used to think that I knew C++ pretty well. <sigh>) :-)

> Concerning my own yearning for infinity, I had the insight, that I can
> provide infinitely open interval borders myself as a property of my
> interval type. So I can be independent of the properties of my
> parameter types in case of example (1: complement). For example (2:
> size) I can provide an is_infinite() function instead, with a little
> loss of simplicity though.
> 
> Generally I think we should avoid special values for integral
> numeric types.

As much as I hate to say it, I'm starting to agree with you. I don't
want to give up the exception-blocking system entirely though, so I'm
still looking for some solution that would allow for it, without the
problems.

> Thank you for submitting your library. If I find time, I might try
> to use it with my ITL library of interval containers.

If you do, I'd highly recommend the version in the Sandbox. The
interface isn't locked down yet, but it fixes several problems that are
still in the version in the Vault, and has a superior design.
- -- 
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/

iEYEARECAAYFAku+FtcACgkQp9x9jeZ9/wS6bQCgzDISkhQCN/dYg7wi3E9g1iUe
/vAAoJOMxejhawYbI81feIUkqOZp9WIL
=1SK4
-----END PGP SIGNATURE-----