MATLAB: Str2double conversion error

errorfloating pointMATLABprecisionroundoffstr2double

Is there a way to avoid this sort of error/effect (see code below) when converting a string to a double? I have tried using str2num() but get the same result.Thanks!

>> str2double('39.11237316')
ans =
  39.112373159999997

Best Answer

You're witnessing floating point roundoff error. In short, an infinite range of numbers must be represented in a finite number of bits (specifically, 64 for double precision numbers). The number you're trying to represent doesn't fit perfectly in this system so it's rounded.

Check this out.

format long
x = 39.11237316
% x =
%   39.112373159999997

% Even if you round it to 8 dp, it can't be represeneted
round(x,8)
% ans =
%   39.112373159999997

So, it's not the str2double() that is the problem, it's the finite precision that this number can be represented in.

If higher precision is required you can use symbolic representation for your computations. But the difference between your value and the value being represented is very tiny and usually not a problem.

For a wonderful explanation of floating point roundoff error, see Cleve Moler's article (founder of Matlab).

Related Solutions

MATLAB: Do inconsistencies exist with floating-point numbers rounding in sprintf, fprintf, sin etc

It is a floating-point representation issue. The Symbolic Toolbox functions sym (with the ‘f’) option and vpa are useful for understanding why.

First, use sym with ‘f’ to determine exactly what something like 20.05 or 40.05 becomes when you convert it to double-precision floating point.

 >> sym(20.05,'f')
 ans =
 5643573283048653/281474976710656

Now use vpa to convert that rational number to a decimal fraction with more digits:

 >> vpa(ans,30)
 ans =
 20.0500000000000007105427357601

Repeat those steps with 40.05:

 >> sym(40.05,'f')
 ans =
 2818268204315443/70368744177664
 >> vpa(ans,30)
 ans =
 40.0499999999999971578290569596

You can see that 20.05 gets converted to a floating-point number slightly greater than 20.05, whereas 40.05 gets converted to a floating-point number slightly less than 40.05. The issue is not with any specific function such as sprintf, fprintf, sin etc, in fact it is not a MATLAB-related issue. It stems from the way that the IEEE-754 standard represents floating point numbers (or real numbers) in binary.

MATLAB: 1e301-10^301 ~= 0

1e301 is computed entirely at parse time, as a double precision number.

10^301 involves computing 10 and 301 at parse time, each as double precision numbers, and then computing the one to the power of the other at run time, resulting in a double precision number. As this is a floating point calculation, it is subject to standard floating point roundoff .

1e301 comes out as the first representable double precision number greater than 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 and 10^301 is one bit different, coming out as the last representable double precision number less than 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 . 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 itself is not exactly representable in double precision.

Best Answer

Related Solutions

MATLAB: Do inconsistencies exist with floating-point numbers rounding in sprintf, fprintf, sin etc

MATLAB: 1e301-10^301 ~= 0

Related Question