I need to replace numbers like 2530.30 with 2599 in PostgreSQL.
I tried using ROUND(2530.30)+0.99 but it only changes the numbers after the decimal point to 99. So it results in 2530.99, which I don't want.
I want to remove fractional digits and replace the last two decimal digits with 99. I know I can just use an integer, but my assignment at school says I need to do this.
There should no be negative numbers, the assignment says that I should have a product that is sold for, let's say, 3500.50 dollars, I then need to make this number go from 3500.50 to 3599. Not 3500.99.
Divide by 100, truncate, multiply by 100 again:
SELECT trunc(2530.30 / 100) * 100 + 99;
This replaces all numbers in the range [2500, 2600) with 2599.
Or, in more general terms, it replaces the last two decimal digits with 99 and discards fractional digits (which also transforms 0 or 12.50 to 99).
Negative numbers cannot occur, as you say, so ignored.
Related
I was testing a operation like this:
[input] 3.9/0.1 : 4.1/0.1
[output] 39 40
don't know why 4.1/0.1 is approximated to 40. If I add a round(), it will go as expected:
[input] 3.9/0.1 : round(4.1/0.1)
[output] 39 40 41
What's wrong with the first operation?
In this Q&A I go into detail on how the colon operator works in MATLAB to create a range. But the detail that causes the issue described in this question is not covered there.
That post includes the full code for a function that imitates exactly what the colon operator does. Let's follow that code. We start with start = 3.9/0.1, which is exactly 39, and stop = 4.1/0.1, which, due to rounding errors, is just slightly smaller than 41, and step = 1 (the default if it's not given).
It starts by computing a tolerance:
tol = 2.0*eps*max(abs(start),abs(stop));
This tolerance is intended to be used so that the stop value, if within tol of an exact number of steps, is still used, if the last step would step over it. Without a tolerance, it would be really difficult to build correct sequences using floating-point end points and step sizes.
However, then we get this test:
if start == floor(start) && step == 1
% Consecutive integers.
n = floor(stop) - start;
elseif ...
If the start value is an exact integer, and the step size is 1, then it forces the sequence to be an integer sequence. Unfortunately, it does so by taking the number of steps as the distance between floor(stop) and start. That is, it is not using the tolerance computed earlier in determining the right stop! If stop is slightly above an integer, that integer will be in the range. If stop is slightly below an integer (as in the case of the OP), that integer will not be part of the range.
It could be debated whether MATLAB should round the stop number up in this case or not. MATLAB chose not to. All of the sequences produced by the colon operator use the start and stop values exactly as given by the user. It leaves it up to the user to ensure the bounds of the sequence are as required.
However, if the colon operator hadn't special-cased the sequence of integers, the result would have been less surprising in this case. Let's add a very small number to the start value, so it's not an integer:
>> a = 3.9/0.1 : 4.1/0.1
a =
39 40
>> b = 3.9/0.1 + eps(39) : 4.1/0.1
b =
39.0000 40.0000 41.0000
Floating-point numbers suffer from loss of precision when represented with a fixed number of bits (64-bit in MATLAB by default). This is because there are infinite number of real numbers (even within a small range of say 0.0 to 0.1). On the other hand, a n-bit binary pattern can represent a finite 2^n distinct numbers. Hence, not all the real numbers can be represented. The nearest approximation will be used instead, resulted in loss of accuracy.
The closest representable value for 4.1/0.1 in the computer as a 64-bit double precision floating point number is actually,
4.1/0.1 ≈ 40.9999999999999941713291207...
So, in essence, 4.1/0.1 < 41.0 and that's what you get from the range. If you subtract, for example, 41 - 4.1/0.1 = 7.105427357601002e-15. But when you round, you get the closest value of 41.0 as expected.
The representation scheme for 64-bit double-precision according to the IEEE-754 standard:
The most significant bit is the sign bit (S), with 0 for positive numbers and 1 for negative numbers.
The following 11 bits represent exponent (E).
The remaining 52 bits represents fraction (F).
Apparently I am misunderstanding the printf man page. (Or else it's a bug in exiftool 10.55 and 10.77)
I am trying to get GPS coordinates from image files with exiftool. I would like to make them the same width and without unnecessary spaces.
The format string I tried, and one of the results:
-coordFormat "%03d°%02d′%0d%02.5f″"
042°37′280.00000″ N, 002°05′510.00000″ W
(I don't need five decimal places—I just put that in temporarily to see whether any of the cameras wer being dishonest about the precision.) The three unnecessary spaces can't be helped; they are outside the format string’s control, but I did get rid of others that were in the default. The leading zero for latitude isn't needed, but it is there because longitude uses the same format string. One problem is the bogus zero inserted between floor(seconds) and its decimal point. The other problem is the false fractional part. The default format for that file is 42 deg 37' 28.39" N, 2 deg 5' 51.96" W
Someone's "cheat sheet" said that my second digit should be the total width, including the decimal point, so I changed the seconds to "%08.5f" but all that did was add another bogus zero in front of the decimal point, e.g., 510.00000→5100.00000 (width of ten, not eight!).
A few years ago, I did something similar, and got the correct results. But I didn't bother to save the script "for future reference."
(Several other SO answers agree with that "cheat sheet.")
It looks like the issue is with the seconds field, for which you have the format specifier %0d%02.5f. I'm not sure what you intended, but there can be only one % for each value to be rendered
If you're formatting longitude then you are dealing with values between -180 and 180. If you want five decimal points then the total width will be
One character for the sign + or -
Three characters for the integer part
One character for the decimal point .
Five fractional digits
giving a total field width of ten. Your full specifier will be %0+10.5f, giving output between «-180.00000» and «+180.00000»
You may use a space flag instead of the +, as in %0 10.5f, which will use a space instead of a + to indicate a positive number, rendering 180 as « 180.00000». The leading zero is there so that zeroes are use to fill the full ten character field with
When dealing with latitude, you will need a total width one character smaller. %0+9.5f will result in a range of «-90.00000» to «+90.00000». Of course you may use the same format specifier as for longitude, which will produce «-090.00000» to «+090.00000». This way the latitude and longitude seconds will have the same number of characters
The %0d is throwing you off. That part of the template is consuming the "51.0" seconds component of the coordinate, leaving nothing for the %02.5d part of the template.
printf "%0d", 51 ===> "51"
printf "%02.5f"; ===> "0.00000"
printf "%0d%02.5f", 51 ===> "510.00000"
So lose the %0d.
The 2 in %02.5f also doesn't do you any good. The number before the decimal place is the minimum length of the field, and the number after the decimal place is the number of decimal places to use. Since 5 decimal places will be printed, the output will be at least 7 characters, and the 2 value will be ignored.
First number is the width, second number is the number of decimal points so what you have currently (%2.5f) appears to be backwards. %5.2f would give you a number that occupies 5 characters and has 2 decimal places. For a number as big as 510, you probably want to make it %6.2f
The eps routine in MATLAB essentially returns the positive distance between floating point numbers. It can take an optional argument, too.
My question: How does MATLAB calculate this value? (Does it use a lookup table, or does it use some algorithm to calculate it at runtime, or something else...?)
Related: how could it be calculated in any language providing bit access, given a floating point number?
WIkipedia has quite the page on it
Specifically for MATLAB it's 2^(-53), as MATLAB uses double precision by default. Here's the graph:
It's one bit for the sign, 11 for the exponent and the rest for the fraction.
The MATLAB documentation on floating point numbers also show this.
d = eps(x), where x has data type single or double, returns the positive distance from abs(x) to the next larger floating-point number of the same precision as x.
As not all fractions are equally closely spaced on the number line, different fractions will show different distances to the next floating-point within the same precision. Their bit representations are:
1.0 = 0 01111111111 0000000000000000000000000000000000000000000000000000
0.9 = 0 01111111110 1100110011001100110011001100110011001100110011001101
the sign for both is positive (0), the exponent is not equal and of course their fraction is vastly different. This means that the next floating point numbers would be:
dec2bin(typecast(eps(1.0), 'uint64'), 64) = 0 01111001011 0000000000000000000000000000000000000000000000000000
dec2bin(typecast(eps(0.9), 'uint64'), 64) = 0 01111001010 0000000000000000000000000000000000000000000000000000
which are not the same, hence eps(0.9)~=eps(1.0).
Here is some insight into eps which will help you to write an algorithm.
See that eps(1) = 2^(-52). Now, say you want to compute the eps of 17179869183.9. Note that, I have chosen a number which is 0.1 less than 2^34 (in other words, something like 2^(33.9999...)). To compute eps of this, you can compute log2 of the number, which would be ~ 33.99999... as mentioned before. Take a floor() of this number and add it to -52, since eps(1) = 2^(-52) and the given number 2^(33.999...). Therefore, eps(17179869183.9) = -52+33 = -19.
If you take a number which is fractionally more than 2^34, e.g., 17179869184.1, then the log2(eps(17179869184.1)) = -18. This also shows that the eps value will change for the numbers that are integer powers of your base (or radix), in this case 2. Since eps value only changes at those numbers which are integer powers of 2, we take floor of the power. You will be able to get the perfect value of eps for any number using this. I hope it is clear.
MATLAB uses (along with other languages) the IEEE754 standard for representing real floating point numbers.
In this format the bits allocated for approximating the actual1 real number, usually 32 - for single or 64 - for double precision, are grouped into: 3 groups
1 bit for determining the sign, s.
8 (or 11) bits for exponent, e.
23 (or 52) bits for the fraction, f.
Then a real number, n, is approximated by the following three - term - relation:
n = (-1)s * 2(e - bias) * (1 + fraction)
where the bias offsets negatively2 the values of the exponent so that they describe numbers between 0 and 1 / (1 and 2) .
Now, the gap reflects the fact that real numbers does not map perfectly to their finite, 32 - or 64 - bit, representations, moreover, a range of real numbers that differ by abs value < eps maps to a single value in computer memory, i.e: if you assign a values val to a variable var_i
var_1 = val - offset
...
var_i = val;
...
val_n = val + offset
where
offset < eps(val) / 2
Then:
var_1 = var_2 = ... = var_i = ... = var_n.
The gap is determined from the second term containing the exponent (or characteristic):
2(e - bias)
in the above relation3, which determines the "scale" of the "line" on which the approximated numbers are located, the larger the numbers, the larger the distance between them, the less precise they are and vice versa: the smaller the numbers, the more densely located their representations are, consequently, more accurate.
In practice, to determine the gap of a specific number, eps(number), you can start by adding / subtracting a gradually increasing small number until the initial value of the number of interest changes - this will give you the gap in that (positive or negative) direction, i.e. eps(number) / 2.
To check possible implementations of MATLAB's eps (or ULP - unit of last place , as it is called in other languages), you could search for ULP implementations either in C, C++ or Java, which are the languages MATLAB is written in.
1. Real numbers are infinitely preciser i.e. they could be written with arbitrary precision, i.e. with any number of digits after the decimal point.
2. Usually around the half: in single precision 8 bits mean decimal values from 1 to 2^8 = 256, around the half in our case is: 127, i.e. 2(e - 127)
2. It can be thought that: 2(e - bias), is representing the most significant digits of the number, i.e. the digits that contribute to describe how big the number is, as opposed to the least significant digits that contribute to describe its precise location. Then the larger the term containing the exponent, the smaller the significance of the 23 bits of the fraction.
I am summing numbers between two indices in a matrix, like this: ans = sum(my_matrix1x500(100:300));
The ans then is a number like: 351267300.4473 and so on. How do I prevent it from printing the decimals? Instead of 351267300.4473 it could print 3512673004473 or simply remove the decimal, is this possible?
Use fprintf('%.0f',X) to print X with '0' significant digits, or round(X) to remove the decimal altogether.
If you have an arbitrary number of decimal places this is not gonna work easily, since the number usually has many more decimal places than it shows. Read the discussion here.
But if you know how many decimal places you want to keep, you simply write:
p = 4 % number of decimal places to keep
ans = floor(ans * 10 ^ p);
This gives you the desired numerical value.
I'm aware that double is the default data-type in MATLAB.
When you compare two double numbers that have no floating part, MATLAB is accurate upto the 17th digit place in my testing.
a=12345678901234567 ; b=12345678901234567; isequal(a,b) --> TRUE
a=123456789012345671; b=123456789012345672; isequal(a,b) --> printed as TRUE
I have found a conservative estimate to be use numbers (non-floating) upto only 13th digit as other functions can become unreliable after it (such as ismember, or the MEX functions ismembc etc).
Is there a similar cutoff for floating values? E.g., if I use shares-outstanding for a company which can be very very large with decimal places, when do I start losing decimal accuracy?
a = 1234567.89012345678 ; b = 1234567.89012345679 ; isequal(a,b) --> printed as TRUE
a = 123456789012345.678 ; b = 123456789012345.677 ; isequal(a,b) --> printed as TRUE
isequal may not be right tool to use for comparing such numbers. I'm more concerned about up to how many places should I trust my decimal values once the integer part of a number starts growing?
It's usually not a good idea to test the equality of floating-point numbers. The behavior of binary floating-point numbers can differ drastically from what you may expect from base-10 decimals. Consider the example:
>> isequal(0.1, 0.3/3)
ans =
0
Ultimately, you have 53 bits of precision. This means that integers can be represented exactly (with no loss in accuracy) up to the number 253 (which is a little over 9 x 1015). After that, well:
>> (2^53 + 1) - 2^53
ans =
0
>> 2^53 + (1 - 2^53)
ans =
1
For non-integers, you are almost never going to be representing them exactly, even for simple-looking decimals such as 0.1 (as shown in that first example). However, it still guarantees you at least 15 significant figures of precision.
This means that if you take any number and round it to the nearest number representable as a double-precision floating point, then this new number will match your original number at least up to the first 15 digits (regardless of where these digits are with respect to the decimal point).
You might want to use variable precision arithmetics (VPA) in matlab. It computes expressions exactly up to a given digit count, which may be quite large. See here.
Check out the MATLAB function flintmax which tells you the maximum consecutive integers that can be stored in either double or single precision. From that page:
flintmax returns the largest consecutive integer in IEEE® double
precision, which is 2^53. Above this value, double-precision format
does not have integer precision, and not all integers can be
represented exactly.