for-next loop parameter gets printed out

Curious behavior. I have a matlab code with lots of for-next loops. One in particular that starts with

for I = J:LL

for some reason resulted in the LL value being printed out unexpectedly. None of my other for-next loops

did this. When I changed the statement to read

for I = J:LL;

i.e., I added a semicolorn to the end, LL was NOT printed out. This is worrisome because I'm not sure something

else has gone wrong. How does one track down what causes this behavior?

[dpb]

Can you post a code snippet that exhibits the suspect behavior?

I've never seen it happen but I've not upgraded to a more recent release than R2020b yet, either, if somehow something got broken in an update.

[Ken Bannister]

Thank you. File attached.

Answer 1

[dpb]

You've got a malformed for expression, the comma serves to make a second line of code on the same source line; the value of ll is echo'ed to the screen as asked for by this syntax.

for l = 1,ll
  ...    
end

is syntactically the same as

for l = 1
  ll
  ...
end

You undoubtedly intended to write

for l=1:ll
  ...
end

So, indeed, something else did go wrong besides; the loop only executed once instead of ll times since were no colon operators to set either step nor upper bound.

And, in this case the typo is also not a syntax error nor can the parser presume you didn't have some reason for only executing the loop once.

[Ken Bannister]

Spot on! Many thanks! The computer only does what you tell it. Stared at this code until I went blurry. Always helps to have another set of eyeballs take a look!

[dpb]

Ayup...such happens to all of us at some time or another...

[Ken Bannister]

I noticed one other squiggly in my code - in the driver program, i had

z = ones(20)

... some statements

z = ncorth(...)

So, when I stepped through the code line-by-line in the editor, no sooner was ncorth called than control jumped back to the first statement of the driver. I think that is MATLAB's polite way of saying "You crashed, but I will let you have another chance." Changing the call to:

zz = ncorth...

fixed it and then everything worked ok inside ncorth. This may be why you were seeing that loop appeared to run only once.

[dpb]

"...This may be why you were seeing that loop appeared to run only once."

No. The loop ran only once because that's precisely the syntax you provided did -- you (inadvertently) wrote

ll=10;      % provide a value for ll
for i=1,ll
  disp(i)
  ...
end

ll = 10

     1

which is IDENTICALLY THE SAME as

for i=1
  ll
  disp(i)
  ...
end

ll = 10

     1

which says to run the for...end loop once and only once and the 'll' line will, as always echo the value of "ll" to the command window.

Would have to see the other precise code in context to have a real klew on what else may have gone south, but this issue isn't it -- it's perfectly valid code, just not logically what you intended.

[Ken Bannister]

OK, thanks again. I will continue working on it. Almost at the point where I should buy a FORTRAN package, e.g., Lahey or Absoft, and stay with it. As it is, I have a three-step process:

1. Convert f77 to f90 using what is at

https://fortran.uk/plusfortonline.php?id=140&id1=3&id2=1&id3=1&id4=-1&id5=1

2. Convert f90 to MATLAB using Ben Barrowes' f2matlab, note any errors

3. Cycle back to 1 and debug and update.

Then hope for the best. Doable, but will require patience and careful attention to details. The good news is that I have a confirmed listing of what the final output should look like.

[dpb]

Your test code before ran here with the correction noted; I don't know what answers should be, of course, but it ran to completion with the fix for the loop construct alone. There are a couple of warnings on suggested better syntax, but none that are of computational significance.

As for the conversion, I've not looked at the code much at all, but unless there were a huge amount of it and/or I didn't really know what it was trying to do, my first inclination would be to not do 1:1 translation but rewrite a MATLAB solution using MATLAB syntax and idioms instead of Fortran's.

The unfortunate decision by TMW to not support anything except Intel for mex is a real kick in the private parts that is, frankly, :just plain rude!" to long-term users but there seems to be no leverage to be able to use to get them to change course. Supporting the fortran compiler with gcc would be a major help and seems like should be essentially trivial to add to the existing support, or to simply just open up the interface and document the libraries and linking to let use any compiler. I fail to grasp the logic behind their current position. Anyways, as of now it appears that using Intel compiler is the only practical choice for going the mex route and they (Intel) have now also closed off that option except for "the high-priced spread" route.

It's an impasse, indeed...