MATLAB switching between integer and floating numbers in a loop during computation

Hi,

I am wondering what is happening in the following for-loop where the variable is changing from being an integer to float to integer to float even though it is not supposed to (?). Don't know what I am missing here.

clc;clear;
for i = 4 : 0.1 : 5
    sd=i*1e-09;
    start_cell=sd*1e10+1
end

start_cell = 41

start_cell = 42.0000

start_cell = 43.0000

start_cell = 44.0000

start_cell = 45.0000

start_cell = 46.0000

start_cell = 47

start_cell = 48.0000

start_cell = 49

start_cell = 50.0000

start_cell = 51

[Stephen23]

"I am wondering what is happening in the following for-loop where the variable is changing from being an integer to float to integer to float even though it is not supposed to"

It isn't. The value is floating point the entire time.

"Don't know what I am missing here."

The behavior of floating point numbers and how MATLAB displays floating point numbers: the values with no trailing zeros are exactly that value, the others have some accumulated error.

Answer 1

[Steven Lord]

What you're missing is that 0.1 is not exactly one tenth. Welcome to the world of floating point arithmetic. See the "Avoiding Common Problems with Floating-Point Arithmetic" section on this documentation page for a brief introduction.

Do not assume that (as an example) 4.1 times 1e-9 times 1e10 is 4.1 times 10 or exactly 41. In theory it is. In practice it isn't.

x = 4.1;
y = x*1e-9;
z = y * 1e10;
z - 41

ans = -7.1054e-15

[Vigneshwaran Sankar]

Thank you for responding. I get the concept of floating point arithmetic. But still, why not all the time, start_cell is not an integer and why only specific set of times (for instance, in my case, when i=1,6,8,10 start_cell is a n integer). Is this something (pseudo)-random?

[Steven Lord]

Sometimes 4+something*0.1 is close enough to four and something-tenths that when you multiply it by 1e-9 and 1e-10 the closest floating-point number is an integer value. Sometimes it isn't. In this case, I would avoid using non-flint values for anything that was going to be an index into an array. Compare your original code:

next = 1;
sd = zeros(1, 11);
start_cell = zeros(1, 11);
for i = 4 : 0.1 : 5
    sd(next)=i*1e-09;
    start_cell(next)=sd(next)*1e10+1;
    next = next + 1;
end

and the more integer-focused version.

next = 1;
sd2 = zeros(1, 11);
start_cell2 = zeros(1, 11);
for k = 40:50
    sd2(next) = k*1e-10;
    start_cell2(next) = k+1;
    next = next+1;
end

Both the quantities we're adding to compute start_cell2 are integer values and so start_cell2 must also be an integer value. Let's look at the results and check how far from an integer value they are.

format longg
start_cell - round(start_cell)

ans = 1×11

1.0e+00 * 0 -7.105427357601e-15 7.105427357601e-15 7.105427357601e-15 7.105427357601e-15 7.105427357601e-15 0 7.105427357601e-15 0 7.105427357601e-15 0

start_cell2 - round(start_cell2)

ans = 1×11

0 0 0 0 0 0 0 0 0 0 0

How different are sd and sd2?

abs(sd-sd2).'

ans = 11×1

1.0e+00 * 0 8.27180612553028e-25 0 0 0 8.27180612553028e-25 0 8.27180612553028e-25 0 8.27180612553028e-25

That's close enough for government work.

Answer 2

[Luca Ferro]

start_cell is always of type double during the entire execution. You can test it by debugging the code manually or by using the whos command like this:

for i = 4 : 0.1 : 5

sd=i*1e-09;

start_cell=sd*1e10+1;

whos start_cell

end

The 'issue' you are facing is just visual, it depends on how your format is set.

Here you can find how to set and what type of settings you can change for the visualization:

Set output display format - MATLAB format (mathworks.com)