Chad Nelson wrote:
On 04/03/2010 06:11 AM, DE wrote: [...]
assumption: it'll be convenient if a thing, upon which some another thing would be built, provide natively some features which would be useful only in the implementation of that other thing built on top of it
this looks like some kind of an inversion or degeneralization sure the prime thing shoud provied complete set of functionality with wich any other extension can be built but since the prime thing is not generally aware of other things which could be built around it it should not provide any feature which would *possibly* be useful
In general, I agree. But if XInt is accepted into Boost, there will *definitely* be an arbitrary-precision real type built onto it. I may do it myself, if no one else steps up, but I'm fairly certain that someone will -- it's a perfect GSoC project, for example. As such, planning for it isn't really degeneralization in this particular case.
Chad gave the practical reason. But perhaps more fundamentally, the information (the sign bit) is *there*, and I'd like it to be usable, even if the mantissa is zero. If you don't want to distinguish between -0 and +0 (and I don't see why you would when strictly in the domain of integers), then you won't ever notice there are 2 different representations.
assumption: there should be signed zeros like that of ieee floating point numbers [...] that's why you have no sound argument for this -- because it's not natural for ints
Exactly my thoughts. But if it does make life noticeably easier for whoever implements the real type, and doesn't cause any problems with the integer type, I'm willing to entertain the idea.
And it *is* natural for sign + magnitude (which I had been slightly mistakenly calling "sign + mantissa") representations. If builtin integers were based on a sign + magnitude or 1's complement representation, we'd already be used to dealing with signed zeros: http://en.wikipedia.org/wiki/Signed_number_representations I'm guessing it's simpler in hardware to use 2's complement, but we're pretty much stuck with sign + magnitude AFAICT for an unbounded integer library.
assumption: the presence of (signed) infinities would provide ultimate set of relationships of the domain entities as well as consistence of some operations' behavior
since there was no example of an application of infinities except interval arithmetics i see no reason to provide it [...]
The more I think about it, the less decided I am over it. I believe there are a few cases where it would be useful to have infinities, at least for comparisons, but I can't think of any concrete examples and no one else has provided any. And it does make for more work, both for me in writing it, and (slightly) for the computer when using it.
At the moment, I'm inclined to leave it out of the library for now, at least until someone can show an application where it would be more useful than the Not-a-Number value. But there's still at least a few days for people to make their cases before I have to make a decision. And we can always revisit the idea after the 1.0 release is stable.
True, infinities would have somewhat specialized applications, but it makes some sense (to me) to include it if you're already going to waste a byte on an NaN flag anyway. - Jeff