I've learned PHP, Java, and C. Now I'm curious as to why there are so many types of numerical data types like bit, int, float, double, and long. Why not make only one type for numericals?
Is there any benefit to this? Maybe if we use integers to hold such small numbers we can save memory?
There are two reasons why you should be concerned with the different numerical data types.
for(long k=0;k<=10;k++) { //stuff } Why use a long when it could just as easily be an integer, or even a byte? You would indeed save several bytes of memory by doing so.
Suppose we have the number 22 stored in an integer. The computer stores this number in memory in binary as:
0000 0000 0000 0000 0000 0000 0001 0110 If you're not familiar with the binary number system this can be represented in scientific notation as: 2^0*0+2^1*1+2^2*1+2^3*0+2^4*1+2^5*0+...+2^30*0. The last bit may or may not be used to indicate if the number is negative (depending if the data type is signed or unsigned).
Essentially, it's just a summation of 2^(bit place)*value.
This changes when you are referring to values involving a decimal point. Suppose you have the number 3.75 in decimal. This is referred to as 11.11 in binary. We can represent this as a scientific notation as 2^1*1+2^0*1+2^-1*1+2^-2*1 or, normalized, as 1.111*2^2
The computer can't store that however: it has no explicit method of expressing that binary point (the binary number system version of the decimal point). The computer can only stores 1's and 0's. This is where the floating point data type comes in.
Assuming the sizeof(float) is 4 bytes, then you have a total of 32 bits. The first bit is assigned the "sign bit". There are no unsigned floats or doubles. The next 8 bits are used for the "exponent" and the final 23 bits are used as the "significand" (or sometimes referred to as the mantissa). Using our 3.75 example, our exponent would be 2^1 and our significand would be 1.111.
If the first bit is 1, the number is negative. If not, positive. The exponent is modified by something called "the bias", so we can't simply store "0000 0010" as the exponent. The bias for a single precision floating point number is 127, and the bias for a double precision (this is where the double datatype gets its name) is 1023. The final 23 bits are reserved for the significand. The significand is simply the values to the RIGHT of our binary point.
Our exponent would be the bias (127) + exponent (1) or represented in binary
1000 0000 Our significand would be:
111 0000 0000 0000 0000 0000 Therefore, 3.75 is represented as:
0100 0000 0111 0000 0000 0000 0000 0000 Now, let's look at the number 8 represented as a floating point number and as an integer number:
0100 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1000 How in the world is the computer going to add 8.0 and 8? Or even multiply them!? The computer (more specifically, x86 computers) have different portions of the CPU that add floating point numbers and integer numbers.
Back before we had gigabyte systems (or on modern embedded systems like Arduino), memory was at a premium and so shorthand methods were implemented to specify how much memory a particular number would take up - BIT is straightforward - it would originally occupy only 1 bit of memory.
The other data sizes and names vary between systems. On a 32-bit system, INT (or MEDIUMINT) would generally be 2 bytes, LONGINT would be 4 bytes, and SMALLINT would be a single byte. 64-bit systems can have LONGINT set at 8-bytes.
Even now - especially in databases applications, or programs that have multiple instances running on servers (like server side scripts on websites) - you should be careful about what you choose. Picking a 2, 4, or 8-byte wide integer to store values between 0 and 100 (which can fit in one byte) is incredibly wasteful if you have a database table with millions of records.
More information: https://en.wikipedia.org/wiki/Integer_(computer_science)
Perhaps the most important thing is that there are really three different basic number types.
integer, fixed decimal and floating point.
They all behave differently.
A simple operation like 7/2 could give answers of 3, 3.50 and 3.499 depending on the data type used.
"fixed decimal" is the Cinderella type, it is only supported natively in a few languages like COBOL and VisualBasic. It is of little interest to computer scientists but is vital to anyone submitting a set of accounts or calculating sales tax on an invoice.
int, float, and unsigned int, respectively. Fixed-point types are a subcategory of discrete types, but algebraic rings are fundamentally different from numbers [must of the confusion regarding unsigned types in C stems from the fact that they mostly behave like rings rather than numbers, but aren't quite consistent].Is there any benefit they make it?
Of course. There are benefits. In the world of computers memory is one of the most important thing to consider. What is the use of having a memory of 2kb when the data can fit in less than 1kb?. Optimizations should be there. If you use more memory it obviously kills your computers speed at a point. Do you really like to have it? No right...?
int - 2 bytes (16 bits) long - 4 bytes (32 bits) long long - 8 bytes (64 bits) float - 4 bytes Not only the memory but there are organization of type of numbers as well. for an instance floating point. The precision matters a lot and obviously we should have one type which can give us more precision.
If we consider olden days, we had a very less memory as you might know. To save it and use it wisely we had these differences. And much more if you just go ahead and give some try on searching with google.. Hope this helps.
In addition to cpmjr123's excellent points about memory scarcity and precision and range trade offs, thers is also potentially a CPU trade off.
Most modern machines have special hardware for performing floating point operations called an FPU. There are also systems that do not have FPU's (nowadays these are typically small embeded devices), consequently, depending on your target hardware, you would either have to not use floating point types at all or use a software floating point library. Even if your machine has an FPU there were historically differences in what functions it could provide. Any functions not done in hardware would have to be done in software (or avoided)
Doing floating point calculations in software is done by performing many simpler operations the hardware does support. You therefore get a potential speed trade off as well.
integers and real (float,double) numbers are conceptually different types with different sets of operations and intrinsic properties.
Integers are enumerable but floats are not, etc.
In fact Float/double number is a structure that combines two integer fields: mantissa and exponent. Complex numbers (that you excluded from consideration) are even more, well, complex.
Any practical language should have at least integers and floats as distinct types - too different operations on them.
a (real part) and b (imaginary part). CPU typically do not implement native support for operations on complex numbers, although CPU may implement accelerated multiply-add instructions for operations on pairs of values, such as (ab+cd) and (ab-cd).uint16_t holds 65535, incrementing it will make it hold 0). Ideally, languages would have cleanly-separate types for representing wrapping algebraic rings and numbers (allowing numbers that overflow to be trapped, while allowing code to easily perform operations on things that are expected to wrap).Additionally to the fact that floating-point types behave completely different from integer types, I want to give a more extreme example why size per number really matters.
Imagine you want to sort a (long) array. For example in C:
int numbers[100000000]; So here we have 100 Million numbers.
If each number is only one byte long (so using unsigned char instead of int), then this needs 100 Million bytes of space.
If you use double, then this usually are 8 bytes per number, so 800 Million bytes of space.
So each time you operate with a lot of objects (numbers in this example), size per object (size per number in this example) really does matter.
