I have two pair of numbers (155.11 , 155.35) and (154.95 , 155.19), their differences are both 0.24. In matlab if I calculate
(155.11 - 155.35) - (154.95 - 155.19), the matlab will output 2.8422e-14,which is 2^(-45). I know this is an issue of machine resolution on floating number representation, but was curious on the detail, why it is this value? what is special on 45?
eps(155.11) is 2.8422e-14. The rounding already happens in the original numbers you enter.
Related
This question already has answers here:
Why is 24.0000 not equal to 24.0000 in MATLAB?
(6 answers)
Is floating point math broken?
(31 answers)
Closed 7 months ago.
While learning MATLAB, I came across a strange problem with my code. I am trying to receive a number as user input and determine whether the inputted number is in the desired range of 5.4±0.1. As you can see below, I took absolute value of the difference between input and 5.4 and checked if it is less than or equal to 0.1. By the code, any number between 5.3 and 5.5 should output "Part is good," but strangely, it doesn't work for the lower bound, 5.3. Every number between 5.3 and 5.5 works except for 5.3, and even 5.5 (the upper bound) works well. I am wondering if there is something with MATLAB that I am not aware of yet. Thank you!
part = input("Enter the length of a part"); %user input (height)
if (part<0) %if input is a negative number
error("Illegal input"); %error message
elseif (abs(part-5.4) <= 0.1) %if input is 5.4+-0.1
disp("Part is good"); %display 'part is good'
else % if not
disp("Part is not good"); %display 'part is bad'
end
First, none of the numbers you are dealing with except 5.5 can be represented exactly in IEEE double precision floating point binary. So you cannot rely on these edge cases to work out exactly as if they were represented exactly in floating point decimal because they aren't. To see this, here are the exact conversions of the underlying floating point binary bit patterns to decimal which show why one edge calculation works and the other doesn't. Bottom line is you need to use tolerances (e.g., something slightly bigger than 0.1) or do your calculations differently if you want your edge cases to work as expected in decimal. This isn't a MATLAB bug ... it is simply how floating point binary calculations work. Any language that uses IEEE floating point in the background will have the same issues that must be accounted for by the programmer when writing code.
A more detailed discussion can be found here: Why is 24.0000 not equal to 24.0000 in MATLAB?
I am converting a program from MATLAB 2012 to 2016. I've been getting some strange errors, which I believe some of are due to a lack of precision in MATLAB functions.
For instance, I have a timeseries oldTs as such:
Time Data
-----------------------------
1.00000000000000001 1.277032377439511
1.00000000000000002 1.277032378456123
1.00000000000000003 1.277032380112478
I have another timeseries newTs with similar data, but many more rows. oldTs may have half a million rows, whereas newTs could have a million. I want to interpolate the data from the old timeseries with the new timeseries, for example:
interpolatedTs = interp(oldTs.time, oldTs.data, newTs.time)
This is giving me an error: x values must be distinct
The thing is, my x values are distinct. I think that MATLAB may be truncating some of the data, and therefore believing that some of the data is not unique. I found that other MATLAB functions do this:
test = [1.00000000000000001, 1.00000000000000002, 1.0000000000000000003]
unique(test)
ans =
1
test2 = [10000000000000000001, 10000000000000000002, 10000000000000000003]
unique(test2)
ans =
1.000000000000000e+19
MATLAB thinks that this vector only has one unique value in it instead of three! This is a huge issue for me, as I need to maintain the highest level of accuracy and precision with my data, and I cannot sacrifice any of that precision. Speed/Storage is not a factor.
Do certain MATLAB functions, by default, truncate data at a certain nth decimal? Has this changed from MATLAB 2012 to MATLAB 2016? Is there a way to force MATLAB to use a certain precision for a program? Why does MATLAB do this to begin with?
Any light shed on this topic is much appreciated. Thanks.
No, this has not changed since 2012, nor since the very first version of MATLAB. MATLAB uses, and has always used, double precision floating point values by default (8 bytes). The first value larger than 1 that can be represented is 1 + eps(1), with eps(1) = 2.2204e-16. Basically you have less than 16 decimal digits to play with. Your value 1.00000000000000001 is identical to 1 in double precision floating point representation.
Note that this is not something specific to MATLAB, it is a standard that your hardware conforms to. MATLAB simply uses your hardware's capabilities.
Use the variable precision arithmetic from the Symbolic Math Toolbox to work with higher precision numbers:
data = [vpa(1) + 0.00000000000000001
vpa(1) + 0.00000000000000002
vpa(1) + 0.00000000000000003]
data =
1.00000000000000001
1.00000000000000002
1.00000000000000003
Note that vpa(1.00000000000000001) will not work, as the number is first interpreted as a double-precision float value, and only after converted to VPA, but the damage has already been done at that point.
Note also that arithmetic with VPA is a lot slower, and some operations might not be possible at all.
I have to import a large integer (1000 digits) into matlab to run some calculations on it. However, when I import it I seem to loose accuracy due to the fact that matlab uses the scientific notation.
Is there any way that I can get the actual integer?
Here's the actual data I have to import:
73167176531330624919225119674426574742355349194934
96983520312774506326239578318016984801869478851843
85861560789112949495459501737958331952853208805511
12540698747158523863050715693290963295227443043557
66896648950445244523161731856403098711121722383113
62229893423380308135336276614282806444486645238749
30358907296290491560440772390713810515859307960866
70172427121883998797908792274921901699720888093776
65727333001053367881220235421809751254540594752243
52584907711670556013604839586446706324415722155397
53697817977846174064955149290862569321978468622482
83972241375657056057490261407972968652414535100474
82166370484403199890008895243450658541227588666881
16427171479924442928230863465674813919123162824586
17866458359124566529476545682848912883142607690042
24219022671055626321111109370544217506941658960408
07198403850962455444362981230987879927244284909188
84580156166097919133875499200524063689912560717606
05886116467109405077541002256983155200055935729725
71636269561882670428252483600823257530420752963450
Such a large integer cannot be represented in IEEE floating point standard. Check out this answer for the largest double that can be represented without losing precision (its 1.7977e+308). That can be obtained by typing realmax in MATLAB.
You can use vpi (available here, as mentioned in comment) or you can use the MATLAB in-built vpa.
This is how you use vpa
R=vpa('7316717653133062491922511967442657474235534919493496983520312774506326239578318016984801869478851843858615607891129494954595017379583319528532088055111254069874715852386305071569329096329522744304355766896648950445244523161731856403098711121722383113622298934233803081353362766142828064444866452387493035890729629049156044077239071381051585930796086670172427121883998797908792274921901699720888093776657273330010533678812202354218097512545405947522435258490771167055601360483958644670632441572215539753697817977846174064955149290862569321978468622482839722413756570560574902614079729686524145351004748216637048440319989000889524345065854122758866688116427171479924442928230863465674813919123162824586178664583591245665294765456828489128831426076900422421902267105562632111110937054421750694165896040807198403850962455444362981230987879927244284909188845801561660979191338754992005240636899125607176060588611646710940507754100225698315520005593572972571636269561882670428252483600823257530420752963450');
You can check the following:
vpa('R+1000-R')
The answer of the above is 1000 as expected. Do not forget to put your expression in quotes. Otherwise, you are passing inifinity to vpa instead of the 1000 digit number.
If you want to use vpi, its a beautiful toolbox, go ahead, download it. Go into its root directory and run the following command:
a=vpi('7316717653133062491922511967442657474235534919493496983520312774506326239578318016984801869478851843858615607891129494954595017379583319528532088055111254069874715852386305071569329096329522744304355766896648950445244523161731856403098711121722383113622298934233803081353362766142828064444866452387493035890729629049156044077239071381051585930796086670172427121883998797908792274921901699720888093776657273330010533678812202354218097512545405947522435258490771167055601360483958644670632441572215539753697817977846174064955149290862569321978468622482839722413756570560574902614079729686524145351004748216637048440319989000889524345065854122758866688116427171479924442928230863465674813919123162824586178664583591245665294765456828489128831426076900422421902267105562632111110937054421750694165896040807198403850962455444362981230987879927244284909188845801561660979191338754992005240636899125607176060588611646710940507754100225698315520005593572972571636269561882670428252483600823257530420752963450')
Well, the advantage with vpi is as follows:
The output of vpi:
a=vpi(<<Your 1000 digit number in quotes>>); %output prints 1000 digits on screen.
The output of vpa:
R=vpa(<<Your 1000 digit number in quotes>>);
this prints:
R =
7.3167176531330624919225119674427e999
Also, with vpi, you can do something like this:
a=vpi('7316717653133062491922511967442657474235534919493496983520312774506326239578318016984801869478851843858615607891129494954595017379583319528532088055111254069874715852386305071569329096329522744304355766896648950445244523161731856403098711121722383113622298934233803081353362766142828064444866452387493035890729629049156044077239071381051585930796086670172427121883998797908792274921901699720888093776657273330010533678812202354218097512545405947522435258490771167055601360483958644670632441572215539753697817977846174064955149290862569321978468622482839722413756570560574902614079729686524145351004748216637048440319989000889524345065854122758866688116427171479924442928230863465674813919123162824586178664583591245665294765456828489128831426076900422421902267105562632111110937054421750694165896040807198403850962455444362981230987879927244284909188845801561660979191338754992005240636899125607176060588611646710940507754100225698315520005593572972571636269561882670428252483600823257530420752963450')
b=a+1
b-a %output of this yields 1.
I somehow cannot do the operation of b-a in vpa and obtain the answer 1.
I am working on floating point to fixed point theory in Matlab. I just need to convert a negative decimal number into binary string but dec2bin command is not working. Kindly suggest me some solution.
please see the following code
freq=-7.2722e-005
u_frac=25
u_fi0=freq*2^u_frac
u_fi=round(u_fi0)
u_fi_b= dec2bin(u_fi0)
For a 32-bit signed integer, you have to add 2^32 to ever negative number:
dec2bin(u_fi0+2^32)
The result is:
11111111111111111111011001110111
I have a question about adding the number 1 to very small numbers. Right now, I am trying to plot a circular arc in the complex plane centered around the real number 1. My code looks like:
arc = 1 + rho .* exp(1i.*theta);
The value rho is a very small number, and theta runs from 0 to pi, so whenever 1 is added to the real part of arc, MATLAB seems to just round it to 1, so when I type in plot(real(arc),imag(arc)), all I see is a spike instead of a semicircle around 1. Does anyone know how to remedy this so that MATLAB will not round 1 + real(arc) to 1, and instead conserve the precision?
Thanks
rho=1e-6; theta=0:pi/100:pi; arc=1+rho*exp(1i.*theta); plot(arc); figure(); plot(arc-1);
Shows, that the problem is in plot, not in loss of precision. After rho<1e-13 there will be expected trouble with precision.
The two other possible misconceptions:
- doubles have finite precision. 16 decimal digits or 1+2^-52 is the limit with doubles.
- format short vs. format long -- matlab shows by default only 6 or 7 digits
It also happens to be that 6-7 digits is the limit of a 32-bit float, which could explain also that perhaps the plot function in Octave 3.4.3 is also implemented with floats.
Left: 1+1e-6*exp, Right: (1+1e-6*exp)-1
There is a builtin solution for exactly this probem:
exp1m()
log1p()
explicitly:
log(arc)=log1p(rho*exp(1i*theta))
to get what you need.
Of course you need to work in log space to represent this precision, but this is the typical way this is done.
In double precision floating point representations, the smallest number strictly greater than 1 that can be represented is 1 + 2^-52.
This is a limitation imposed by the way non-integer numbers are represented on most machines that can be avoided in software, but not easily. See this question about approaches for MATLAB.