2

I know that an int for example has a max value of 2,147,483,647 and is stored in 4 memory slots (each 8 bits and a total of 32 bits or simply a word).

Int can be loaded into a 32 bit Register just fine. If we are using smaller Register counts like an 8 bit Microcontrollers, the int will be divided into 4 registers.

Now the question is, since both RAM and Register allocations are dynamic (we are using 4 memory slots in this case), why do we even have limits for data types?

Instead of using 4 memory slots, why don't we use 5 or 6 or N (same with CPU Register). Why don't we allow data types with infinite bits as long as they can fill up the entire RAM/Register?

  • 3
  • Using more bits for a variable than needed to cover the range of possible values would be a waste of resources. Extending the number of bits when the value requires it would be really expensive and make things needlessly complicated.. – Martin Maat Sep 15 '18 at 20:37
  • 1
    As an aside, an int has a minimal maximum of 2 ** 15 - 1, and might fit into as little as one solitary memory slot, also known as byte. Some implementations have higher limits and/or different-sized bytes. – Deduplicator Sep 15 '18 at 22:11
11

You're right, it can sometimes (in rare cases, to be honest) be annoying to deal with fixed-size numbers. But don't worry: nowadays, most programming languages can deal with unlimited-size numbers one way or the other.

So why do we still have (and use in 99% of all cases) fixed-size numbers?

Mainly, it's because the basic CPU machine instructions work with fixed-size numbers, so fixed-size gives you the best performance. As the vast majority of numbers we typically represent in software fit well within the +/- 2-billion range of the 32-bit datatype, I rarely need a bigger or even variable-length datatype.

  • 7
    @gnat: In general, the same principles apply to most modern programming languages, especially those in the C family, including C itself, C++, C# and Java. – Robert Harvey Sep 15 '18 at 21:52
4

Having fixed-size integer types, typically corresponding to CPU instruction modes, is much simpler than providing variable-width integer types.

Adding two 32-bit integers is typically a single CPU instruction. Adding two arbitrary-width integers generally requires sophisticated software support, including dynamic memory allocation and deallocation. See the GMP GNU Multiple Precision Arithmetic Library for one example. (It's a C library, so in fact you can do multiple precision arithmetic in C.)

Some languages (Python, for example) do provide built-in arbitrary-width integers -- but the compiler, interpreter, or runtime library for such a language has to implement it.

And fixed-size integer arithmetic is used in the implementation of these multiple precision libraries.


Incidentally, C requires the range of int to be at least -32767 .. +32767 (16 bits), and a "byte" to be at least 8 bits, but it can be more. Most modern C implementations have 32-bit int, but it's not required by the language.

2

This answer builds on top of Ralf Kleberhoff's answer, and tries to address C specifically.

First, read about Arbitrary-precision arithmetic on Wikipedia. To put it simply, it is possible:

  • For a reusable software library to provide fixed size bignums, such as 64-bit integers, 128-bit integers, 256-bit integers, etc., and arbitrary size bignums, where the amount of memory needed to store the value is dynamically allocated based on how big the value is, from calculation result or copying.
  • For a programming language to provide the same, and integrated into the language syntax itself - so that the "+" "-" "*" "/" operators would work with bignums as well, for example.
  • For a programming language to specify a "standard library" that is standardized and which comes with the language. This standard library is sometimes called "the runtime library" of the programming language.

For some modern programming language, the typical choice is the third one - to include such bignum facilities as a standard library that comes with the language.

Some other (not-so-modern, but highly advanced and ahead-of-their-times) programming languages already implemented the second choice - in order to eliminate "integer overflow" as a source of "unexpectedness" (errors or exceptions) in programming.

However, for C, two mindsets work against the second and third choice:

  • The C language tries to keep the language itself to the minimum.
  • The C language also tries to keep its standard library to the minimum.

Thus, the committee that controls C refuses to rectify (standardize) a bignum library for the C programming language. Users of C must therefore look for a bignum library, or else implement their own.

The C language leaves out a lot of things. For example, most programming languages have a "Deflate" (compression/decompression) or "MD5" checksum implementation in their standard libraries. C doesn't.


Why is there a distinction between "fixed size bignums" versus "dynamically sized bignums"?

This is because fixed size bignums (where size is determined by the programmer and written into the source code) allows the memory size determination to be made at compile-time. The compiled machine code is both simpler and faster - it takes fewer instructions to perform each operation. Dynamically sized bignums require more machine instructions for each operation.

  • Probably, among "Some other (not-so-modern, but highly advanced and ahead-of-their-times) programming languages" you have Lisp in mind. – Ralf Kleberhoff Oct 7 '18 at 9:15
1

It's about controlling growth.

Save this 1 for me somewhere. I don't care where. Just save it.

So you get a bit of paper and write 1. Now I come back and say. Hey turn that 1 into a 5. So you erase 1 and put down 5. Oh make it 42. Wait you don't have room for 42. Well now you can throw an error or save this somewhere else. But if you save it somewhere else you have to update everything that remembers where it used to be.

You can do all that now. You just can't do it with int. Primitives weren't designed to grow without limit. That's what collections do.

At least in some languages. Others don't mind how doing all that for everything slows them down and takes up more space.

0

Why is there a limit on data types?

Its cheaper and faster to have power-of-2 ranges - even though that is not as flexible for arbitrary wide math.


Fundamentally 1000s of processor architectures have been realized in hardware and software with all sorts of data typing since 1940,50,60s. It is as if you and I and many other each year tried something and the favored designs survived to the next year. An integer with a few width choices - all at a power-of-2 somewhere about 8 to 256 has consistently found more adherents and support than variable length math or other bit widths. Variable width math cost time and memory management headaches.

There simply is not enough demand for OP's suggestion to commit to build such hardware. It is more flexible, but not fast because fixed width types are easier to realize in hardware and satisfy most needs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.