not recognizing 3.2220e+03 as a positive integer?

I'm getting the error below:

arraynum =

   3.2220e+03

Array indices must be positive integers or logical values.

Error in kaboomSpeed (line 3)
velocityAtImpact= velocity(arraynum);

but I can type velocity(3.2220e+03) into the command line and it works so why wont it work in my function?

function[velocityAtImpact]= kaboomSpeed(velocity,lengthOfFlight,dt)
arraynum=lengthOfFlight/dt
velocityAtImpact= velocity(arraynum);
end

Thanks in advance to anyone who can help me with this.

Answer 1

[Image Analyst]

Since arraynum is a computed value, not something you typed in, it's close to an integer but not exact. This is a FAQ, so read the FAQ and if that doesn't explain it well enough, then write back. Maybe you just want to pass arraynum into round:

arraynum = round(lengthOfFlight/dt);

[Daire Vickers]

Ok this worked, seems weird that matlab can't just take the value as an integer if it is extremely close. This error only occured when I increased the the length of time this rocket launch simulation went on for, with a shorter time this didn't happen.

[Stephen23]

"...seems weird that matlab can't just take the value as an integer if it is extremely close"

Exactly how close is "extremely close" ? Who gets to decide how close this limit is? What happens if someone else wants it more/less close that you do?

[Daire Vickers]

true, maybe when the error comes up it should suggest using fix if the function requires an integer and the margin of error is obviously due to floating point error?

Answer 2

[John D'Errico]

Because it is not an integer. Yes, if you type in 3.2220e+03, MATLAB is smart enough to know that is an integer.

But how do you know that is the complete value of that number as stored in some variable? That there are not more digits hidden beyond what was reported at the command line? In fact, we can say with 100% certainty that in fact, it is not an integer that you have stored. MATLAB told you that.

Array indices must be positive integers or logical values.

[Daire Vickers]

lengthofflight is a number with only one decimal place and dt is 0.1 so lengthOfFlight/dt is always a whole number.

[John D'Errico]

WRONG!

And that is where you are failing to appreciate floating point arithmetic. You computed that number as:

lengthofflight / dt

with dt = 0.1. Can a floating point number (using a binary mantissa) represent 0.1 EXACTLY as a double? NO!

This happens for the very same reason that you cannot represent 2/3 as a decimal number in a finate number of digits. 2/3 = 0.66666666666666... You will never run out of 6's on the end there. And approximating the result as 0.666666666...67 is not correct. So what happens is as a double, how is the number 0.1 represented? Computers will be forced to usea sum of powers of 2. In fact that sum will be:

B = [-4 -5 -8 -9 -12 -13 -16 -17 -20 -21 -24 -25 -28 -29 -32 -33 -36 -37 -40 -41 -44 -45 -48 -49 -52 -53 -55];
sum(2.^B)
ans =
                       0.1

But in fact, just as in a number like 1/3 or 2/3 as a decimal, this really needs to be an infinite sum, a repeating decimal, although in binary.So the number 0.1 as a double? It is not truly 0.1.

sprintf('%0.55f',0.1)
ans =
    '0.1000000000000000055511151231257827021181583404541015625'

It is a little off. Then when you divide by 0.1? Sorry, but sometimes it need not be an integer.

2.3/0.1
ans =
                        23

It looks like an integer, but is it? NOT so.

sprintf('%0.55f',2.3/0.1)
ans =
    '22.9999999999999964472863211994990706443786621093750000000'
2.3/0.1 == 23
ans =
  logical
   0
2.3/0.1 - 23
ans =
      -3.5527136788005e-15

And this is exactly why your index failed. Not because MATLAB cannot use a number as an integer because it was close but because MATLAB knew that your number was not in fact a true integer, AS YOU HAD COMPUTED IT.

[Daire Vickers]

Ok I am educated in the ways of computing now thanks.

How come it worked in the command line and not in the function though?