ranges for int and double under 32-bit vs 64-bit systems

[JoeyS]

Hello, I'm working on a project for school in engineering and as part of it I've spent most of the summer learning c++. Though I'm just a beginner with no previous programming experience it was going well until I started getting incorrect results for certain integer calculations. At first I couldn't figure out why but after some digging around it turned out it was because of the limited range of the integer variable type. I would like to get around this because I require the program to consider calculations that exceed this range. I realize there are several other variable types to consider but they lose accuracy in the upper ranges due to rounding which is no good. I also gather there are something like 'large-number' classes that can be used but I haven't really looked into that too much and it's something I'd rather avoid for now if possible. Another possible solution I came across made reference to 64-bit systems but the source wasn't very explicit and so I am asking for a little clarification on this. The book I read this from did not say exactly but seemed to imply that the computable range for the int variable type and the accuracy of the double variable type are much wider under 64-bit systems than under 32-bit systems. Is this true and if so what are the ranges (negative and positive) over which the int and double variable types are accurate? Thanks for your help.

[jmc]

You can make 64- bit calculations even without a 64- bit system. Usually you can declare them by using "long long", also called double long variables.
If you wanted to make calculations without to loose accuracy with bigger nombers than you can store in 64 bits you have such a large number class or you write your own functions for you calulations and use your own type e.g.
typedef struct {
unsigned char byte[254];
unsigned char length;
} my_large_number;

[exception]

(a) Integer arethmetic is always exact, if there is neither an underflow nor an overflow.
(b) There is no such thing as a "long long" in the C++ standard:

(3.9.1.2) There are four signed integer types: "signed char", "short int", "int", and "long int."

(c) The size of these types is implementation-defined. The size increases in the given order, and "signed char" is the size of the machines character representation size. That's about all you are guaranteed.
(d) You can check ranges with the functions defined in <numeric_limits>. There you can also check if your floating point arithmetic is IEEE 754 compliant: static const bool is_iec559. If it is, you could use the arithmetic to perform exact integer calculations in certain ranges, but this is rather complicated (there is a paper by Clarkson: "Safe and effective determinant evaluation" which uses this technique (I think that's the first time doubles were used as ints), since back then (1992) 64 bit wasn't available and the FPU was faster than multiple CPU calculations. But really, it is rather complicated.)
(e) Have a look at gmpxx (http://gmplib.org/). It's a library providing the type mpz_class, which can be used exactly like an integer but has an "infinite" size (it grows as the number it holds grows, until you're out of ram).

Hope that helps.

[helios]

Yes, he could d. Or, he could just use long long or __int64 (which has the same size on any compiler that supports 64-bit integers). As long as the compiler doesn't complain and it's portable, standard-compliance isn't that important.

Use arbitrary precision arithmetic only if you're sure you really need it. Keep in mind that it's much slower than integer arithmetic, but that it's also practically impossible to overflow (the 44th Mersenne prime is almost 10M digits, which would be ~9.8 MB).

[exception]

GMP uses pretty advanced techniques which make it fast. Really fast. Of course it is slower than int, but still - e.g., multiplication is performed not wiht the "best" algorithm according to the upper bound, but depending on the size the "school method", Karatsuba, or Schönhage-Strassen is used.

With MP floating values, the thing is a bit different. Floatingpoint filters can help here to avoid unneeded exact computations and speed things up without sacrificing exactness.