www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 8784] New: std.bigint.BigInt.infinity

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8784

           Summary: std.bigint.BigInt.infinity
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Phobos
        AssignedTo: nobody puremagic.com
        ReportedBy: bearophile_hugs eml.cc



Algorithms that use integers or floating point values sometimes need to use
int.max or double.infinity. BigInt.max is not available, because the size of a
BigInt is unbounded. So I suggest to add std.bigint.BigInt.infinity, also
usable as -BigInt.infinity, as negative.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 08 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8784


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |clugdbug yahoo.com.au
         Resolution|                            |INVALID



For floating point numbers of limited size, you need infinity for overflow, and
you can possibly also follow IEEE in generating it for division by zero.
It's more a necessary evil than a desirable feature.

But for BigInt it is quite different. There is no BigInt operation which
results in an overflow, and division by zero is an error. And infinity is a
really, really annoying special case, both in terms of implementation (where it
has a performance penalty) and from the user's side. You have to sacrifice some
important guarantees, eg
    assert(x + 1 != x);
is not always true for any type which includes infinity.
That sacrifice doesn't happen for IEEE floating point, since already
   x + 1 == x
for any large number such as real.max / 2, due to reduced precision.
But for BigInt, it's a huge price to pay.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 09 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8784







 But for BigInt, it's a huge price to pay.


OK. I have templated code that works with integral types, and uses T.max (or
T.infinty if T is a floating point). To make it work with bigints I have to use
a huge_bigint_val or to change the code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 09 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8784







 

 But for BigInt, it's a huge price to pay.


 
 OK. I have templated code that works with integral types, and uses T.max (or
 T.infinty if T is a floating point). To make it work with bigints I have to use
 a huge_bigint_val or to change the code.


I think it's reasonable to have to change the code. Whenever you use T.max, you
are explicitly using a type with finite representation size. Floating point has
both a T.max and a T.infinity, both of which have different semantics to
integer.max.

Actually I find it difficult to think of non-trivial algorithms which work
correctly even just for built-in integers and built-in floating point. There
isn't much common semantics.

Eg, even sum() needs special treatment. 
sum([real.max, real.max, -real.max, -real.max, 7.0]) == 7.0, not infinity or
NaN.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 09 2012