Re: [boost] New Boost.XInt Library, request preliminary review

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2010-04-03 07:49:49

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On Behalf Of Chad Nelson
> Sent: Friday, April 02, 2010 8:10 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] New Boost.XInt Library, request preliminary review
> 
> - ----------------8<----------------
> Forgive any mathematical terminology errors, I'm only an armchair
> mathematician. But in the domain of natural numbers, zero, by
> definition, has no sign. It's neither positive nor negative (or if you
> prefer, it's both). Signed zero seems to be an invention of computer
> science, where it represents a fraction that's so small that the inexact
> computer representation is indistinguishable from zero, but where the
> number itself isn't necessarily true zero.
> - ----------------8<----------------
> 
> As such, there's no real need for it in XInt.
> 
> > Is it possible to simply be agnostic to the sign bit when the
> > mantissa is 0?
> 
> Isn't that the same as saying that -0 is identical to +0?

IMO this is computing - whatever mathematicians feel about it.

1  There *really is a sign bit*, so either we should ensure that it is never set with zero (which *might* involve some
runtime cost -  if we negate a value, so we have to check for zero?) or just accept acknowledge that it is there ?

2  Is it relevant that that floating point types have sign and copysign functions that might be applied by some generic
code to this 'user-defined' type?  Would be simplest for these to be provided and to do the obvious thing?  Or are we
saying that this can't be used in this way?

3  Likewise there *really is a limit to the size of this infinite sized integer*, and many users will want to place an
arbitrary limit on its size (and to know that that is).  "Calculate Fib numbers, but don't use more than 1 Mbyte for
it".

4  Some users may also want to limit the size to some chosen fixed arbitrary maximum number that is much smaller in
order to mimic some of the fixed big integers about (128 bit, 256 bit, 100 decimal digits like NTL ZZ type etc).  Would
it be logical to provide the std::numeric_limits<integer>::max() function for this?  And what about the
std::numeric_limits  digits and digits10()?

All these decisions seem to me arbitrary and pragmatic.  Perhaps we should leave the author to make a full proposal with
some use case and provide a rationale and pros and cons.

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal, UK   LA8 8AB
[phone], mobile [phone]
pbristow_at_[hidden]