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

7 views (last 30 days)
Vigneshwaran Sankar on 18 Jan 2023
Commented: Stephen23 on 19 Jan 2023
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 on 19 Jan 2023
"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.

Steven Lord on 18 Jan 2023
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
##### 2 CommentsShowHide 1 older comment
Steven Lord on 19 Jan 2023
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.

Luca Ferro on 18 Jan 2023
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: