[Issue 5765] ^^ and << with BigInts

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=5765



--- Comment #8 from bearophile_hugs at eml.cc 2011-03-23 16:40:37 PDT ---
(In reply to comment #7)

> They are not system languages. The comparison is irrelevant.

Well, Lisp was used plenty as a system language. D wants to be a multi-purpose
language, and it already has a multi-precision library, and I see no harm in
using this library for purposes not anticipated by the BigInt author.


> A type that you can be used as a drop-in replacement for integers but will warn
> of overflow, is 100 times simpler than BigInt. Why don't you just write it?

Often I don't just want to watch for overflows, I'd also like the program to
give a correct answer if for mistake one intermediate computation needs 70 bits
long integers (and I don't know it). In the Project Euler
(http://projecteuler.net/ ) there are usually ways to avoid multi-precision
numbers, but if you are not careful it's not hard to have larger intermediate
values. In this case 64 bit values give wrong results, while the small programs
in Python give the correct result.

ShedSkin is a Python-->C++ compiler, recently it has added support for 64 bit
integers too, this has allowed it to compile 131 out of 204 Python Euler
solutions:
http://shed-skin.blogspot.com/2010/05/shedskin-versus-psyco-for-131-project.html

Most of the solutions that can't be compiled with ShedSkin require
multi-precision numbers. Often the final result is a 32 bit number, but
intermediate values are larger than 64 bit, and ShedSkin gives a wrong result
on them. This is an example why multi-precision computations are useful, to
produce correct results. The point here is that overflow errors are not enough.

Thank you for your answers Don, and sorry for my insistent nature :-) Feel free
to close this bug report when you see it fit.

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