I have a column with numeric values that differ drastically:
123.072
2
0.00012
851
1234
0.1
12
0.531211
etc.
I've tried using float and decimal but when I enter 0.023 for example, it just rounds the value as 0. I can't afford to round these numbers.
What structure type and length should I be using?
Try defining the range(length) of your decimal:
decimal(number,number)
Related
For example, if n=9, then how many different values can be represented in 9 binary digits (bits)?
My thinking is that if I set each of those 9 bits to 1, I will make the highest number possible that those 9 digits are able to represent. Therefore, the highest value is 1 1111 1111 which equals 511 in decimal. I conclude that, therefore, 9 digits of binary can represent 511 different values.
Is my thought process correct? If not, could someone kindly explain what I'm missing? How can I generalize it to n bits?
29 = 512 values, because that's how many combinations of zeroes and ones you can have.
What those values represent however will depend on the system you are using. If it's an unsigned integer, you will have:
000000000 = 0 (min)
000000001 = 1
...
111111110 = 510
111111111 = 511 (max)
In two's complement, which is commonly used to represent integers in binary, you'll have:
000000000 = 0
000000001 = 1
...
011111110 = 254
011111111 = 255 (max)
100000000 = -256 (min) <- yay integer overflow
100000001 = -255
...
111111110 = -2
111111111 = -1
In general, with k bits you can represent 2k values. Their range will depend on the system you are using:
Unsigned: 0 to 2k-1
Signed: -2k-1 to 2k-1-1
What you're missing: Zero is a value
A better way to solve it is to start small.
Let's start with 1 bit. Which can either be 1 or 0. That's 2 values, or 10 in binary.
Now 2 bits, which can either be 00, 01, 10 or 11 That's 4 values, or 100 in binary... See the pattern?
Okay, since it already "leaked": You're missing zero, so the correct answer is 512 (511 is the greatest one, but it's 0 to 511, not 1 to 511).
By the way, an good followup exercise would be to generalize this:
How many different values can be represented in n binary digits (bits)?
Without wanting to give you the answer here is the logic.
You have 2 possible values in each digit. you have 9 of them.
like in base 10 where you have 10 different values by digit say you have 2 of them (which makes from 0 to 99) : 0 to 99 makes 100 numbers. if you do the calcul you have an exponential function
base^numberOfDigits:
10^2 = 100 ;
2^9 = 512
There's an easier way to think about this. Start with 1 bit. This can obviously represent 2 values (0 or 1). What happens when we add a bit? We can now represent twice as many values: the values we could represent before with a 0 appended and the values we could represent before with a 1 appended.
So the the number of values we can represent with n bits is just 2^n (2 to the power n)
The thing you are missing is which encoding scheme is being used. There are different ways to encode binary numbers. Look into signed number representations. For 9 bits, the ranges and the amount of numbers that can be represented will differ depending on the system used.
I have a column with the data type decimal setup as so..
`cost` decimal(4,2) NOT NULL DEFAULT '0.00',
However when I input a price, say 100.00, next time I look at it it says 99.99.
Why is this? I thought 4,2 allowed 4 chars before the decimal & 2 after?
4 is the precision (total number of digits), 2 is the scale (decimal places).
In your case you want 6,2.
A DECIMAL(M,D) column permits at most M - D digits to the left of the decimal point.
M is the maximum number of digits (the precision).
decimal [ (p[ ,s] )] and numeric[ (p[ ,s] )]
Fixed precision and scale numbers. When maximum precision is used, valid values are from - 10^38 +1 through 10^38 - 1. The ISO synonyms for decimal are dec and dec(p, s). numeric is functionally equivalent to decimal.
BOTTOM LINE:
you should try and make it 6,2.
6 as in total 6 digits, 2 as in 2 digits after the point.
In a DECIMAL(M, D) column MySQL gives the option for the range of D to be 0 to 30.
Is there a subtle reason that I'm missing for the option of 0? Isn't a decimal with nothing after the decimal point an integer?
When and why would I want to specify a DECIMAL that has no decimal places?
The number range of the DECIMAL type is much greater than for an INTEGER or BIGINT. The greatest number you are able to store in a DECIMAL(65, 0) is 65 nines. The largest number in a BIGINT is 18446744073709551615.
DECIMAL(x, 0) is often a little more expensive for small numbers. Consider using a defined INTEGER type if your numbers are in the range for one of those.
The storage requirement in bytes for a DECIMAL(x, 0) field depends on the x according to this formula:
Storage = x / 9 + Leftover
Leftover = round_up((x % 9) / 2) (i.e., about half of the leftover digits)
You can read more about storage requirements for numeric types in the MySQL manual and compare for yourself.
Besides allowing to store values bigger than BIGINT, you can use DECIMAL(x,0) if you want to:
allow values in the range -9, ... , +9: use DECIMAL(1,0) (uses 1 byte)
allow values in the range -99, ... , +99: use DECIMAL(2,0) (uses 1 byte)
allow values in the range -999, ... , +999: use DECIMAL(3,0) (uses 2 bytes)
allow values in the range -9999, ... , +9999: use DECIMAL(4,0) (uses 2 bytes)
...
allow values in the range -999999999, ... , +999999999: use DECIMAL(9,0) (uses 4 bytes)
... etc (up to DECIMAL(65,0) which uses 29 bytes)
In Mysql,
Decimal(3,2) means total 3 digits and 2 digits after decimal point like 3.42
Decimal(3,0) means in total 3 digits and no digit after decimal point like 345
Even if you write something beyond the given range in brackets of decimal Mysql will automatically update them to 000 or 999.
In a biging you can only store a digit which is no larger than 18 446 744 073 709 551 615. This is 20 digits, but in a DECIMAL you can specify even a 65 digits to store. Also with int you can't constrait directly the number of digits to a low number (e.g. to one). So it is more flexible, and if you need to expand it on an existing database, it is easier.
Can anybody, given example below, make to me an explanation how FLOAT works in mySQL? I know that float is approximative, but really, such a difference? And there is only 9 digits, so it is not overflow problem, isn't it?
mysql> create table t(f FLOAT(15,2), db DOUBLE);
mysql> insert into t(f,db) VALUES (512659663, 512659663);
mysql> select * from t;
+--------------+-----------+
| f | db |
+--------------+-----------+
| 512659648.00 | 512659663 |
+--------------+-----------+
(mysql Ver 14.14 Distrib 5.1.44, for Win32 (ia32) on Windows XP)
FLOAT is a 32-bit type with, as the name suggests, floating point. The higher is the value, the less is the absolute precision.
512659648 is large enough to introduce errors in tens.
Update:
In IEEE-754 (that's what FLOAT is), the data are stored in 32 bits: 1-bit sign, 8-bit binary exponent and 23-bit significand.
The exponent shows you the closest least power of 2 (28 in your case, or 268435456).
The significand is a binary fraction. It can store numbers from 1 to 2 with precision up to 2^-23. In your case, it's 1.11101000111010010000110, or ~ 1.9098060 in decimal notation.
The number is calculated as a product of the exponent and the significand.
Given all this, precision is 2 ^ (28 - 23) = 2 ^ 5 = 32 for the numbers of that order (2^28 to 2^29).
Actually, in MySQL, FLOAT and DOUBLE are both approximate floating-point numbers. MySQL uses four bytes for single-precision values and eight bytes for double-precision values.
So, both columns are approximate - it's just that your FLOAT column only gets 4 bytes to try to approximate your number.
The mantissa of a single precision floating point number is 22 bits in length. It therefore cannot accurately store an integer number greater than 2^22, 4194304.
It is most important that it be accurate, but also it should take the least disk space possible.
You would need a DECIMAL(6,5) to store a number from 0 to 1 with 5 decimal places.
The declaration syntax for a DECIMAL column is DECIMAL(M,D). The ranges of values for the arguments in MySQL 5.1 are as follows:
M is the maximum number of digits (the precision). It has a range of 1 to 65.
D is the number of digits to the right of the decimal point (the scale). It has a range of 0 to 30 and must be no larger than M.
According to this, in MySQL 5.0.3
DECIMAL(5,5) or DECIMAL (6,6) should take 3 bytes.
DECIMAL(4,4) 2 bytes.
If you need to store values from 0 to 1 inclusive, you might be tempted to use DECIMAL(6,5). But that occupies 4 bytes as integer and float parts are stored separately and you need one byte for integer and three for 5 decimal digits. And if you have 4 bytes you might as well use FLOAT.
Before MySql 5 DECIMALs were stored as strings and the most efficient way was to store SMALLINT or MEDIUMINT (2 or 3 bytes) and manually divide it by 10000 or 1000000 respectively.