[Issue 8784] std.bigint.BigInt.infinity
http://d.puremagic.com/issues/show_bug.cgi?id=8784 --- Comment #3 from Don 2012-10-09 05:01:47 PDT --- (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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8784] std.bigint.BigInt.infinity
http://d.puremagic.com/issues/show_bug.cgi?id=8784 --- Comment #2 from bearophile_h...@eml.cc 2012-10-09 04:00:17 PDT --- (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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8784] std.bigint.BigInt.infinity
http://d.puremagic.com/issues/show_bug.cgi?id=8784 Don changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||INVALID --- Comment #1 from Don 2012-10-09 03:09:45 PDT --- 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: ---
