MATLAB - script generates another script faultlessly but has problems running it.

Hi,

This problem involves a script of over 1,000 lines, so please only read on if that's okay with you. I'm not a great coder, so it may not be efficient code, but I'm only a student. I have tried asking at a generic answer website, but had no joy, so I'm going to try here, too.

I've written a MATLAB script m-file which essentially finds out as much detail as it can from the given data, and writes another script m-file to brute force anything it cannot be sure of.

I find that I encounter problems when running the first script, when it reaches the point it needs to call the second script. The error changes places each time I run the program, and usually disappears if I open the second script file after the error and do something aesthetic, but not code-changing[*]. However, this is now useless, because the loop of the original script file has been terminated.

MATLAB appears to skip a line of the script, then throw the "subscript indices must be real positive integers or logicals" error; although, as far as I can see, there is no reason for it to skip a line, and, even though it has, the indices are all of the required type.

I have tried for many hours to figure out where I'm going wrong but I'm stumped. The files I've been using are here, written alone, beside the one taken from FEX, for which credit is given accordingly.

Thanks for any time you may waste trying to help. There is a readme m-file in the zip with some system details, and a more detailed explanation of what the code hopes to achieve.

Bob.

[*] For example, if I open the allegedly erroneous script m-file, use "select all", then "smart indent", only the number of spaces in the file is changed. However, MATLAB runs it perfectly afterwards.

Answer 1

[Walter Roberson]

Do you change the content of the script you generate after you first invoke it? If so then you need to "clear" the script name after the change and before you invoke it again. Or if it really is a script rather than a function, you may need to "clear" the function that invokes the script.

[Jan]

Exactly. It sounds, like Matlab does not reload the automatically created file. Then a CLEAR forces it to do.

[Bob Marsh]

I thought it was overwriting the script each time - I guess not. (Any idea why not?) Using a clear before it generates the script works. Thank you both!

[Walter Roberson]

Once a file has been Just In Time (JIT) compiled, MATLAB does not check to see if the file has been changed. clear'ing the file throws away the remembered JIT so that the JIT will be rebuild the next time the file is invoked.

[Jan]

I do not agree with Walter. If the folders are added in non-freezed mode, the M-files are read after they have been changed - when the command prompt got active. The "clear" is required if the M-file is changed and started in the same program, or for freezed folders.

[Bob Marsh]

I was working under the assumption that fprintf with permission 'w' would overwrite the script each time, and rehashing would force MATLAB to check the directory again, thus the up-to-date file would be found, and run. CLEARly, I was wrong.

The thing that still puzzles me, having read both contributions, is, that the error was not always in the same place. It always threw the same error message, but after the loop had run a different number of times, and referencing different lines of the script. If the filesystem is consistent, this should not happen; could this be due to instantaneous processing speed or something similar? After all, native code is largely deterministic.

P.S. Jan, I cannot find any information about freezed or non-freezed modes, except in "help addpath", which says something about Windows, but I'm using openSUSE. What exactly do these modes represent?

[Walter Roberson]

rehash() after the file had changed should also work, provided that the file was in the MATLAB path and was not within a toolbox.

I have no explanation for why the difficulty occurred at different points -- or at least nothing more than complete surmise.

[Bob Marsh]

Thanks for all of your help!