Comment #0 by bearophile_hugs — 2012-10-08T10:31:44Z
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.
Comment #1 by clugdbug — 2012-10-09T03:09:45Z
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.
Comment #2 by bearophile_hugs — 2012-10-09T04:00:17Z
(In reply to comment #1)
> 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.
Comment #3 by clugdbug — 2012-10-09T05:01:47Z
(In reply to comment #2)
> (In reply to comment #1)
>
> > 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.