Trying my script in another MATLAB release

Hi, I have MATLAB R2015b, and I have a script I would like to test in another MATLAB release, to see if it still works. I would like my script to be able to run in any release, or at least in as many releases as possible.

If you run it, can you tell me the error message that appears and how I can solve it?

[per isakson]

On R2016a x1 produces a series of figures. Seems to work; no messages indicated otherwise. However, I interrupted the execution after fourteen figures

[Image Analyst]

Ricardo, please give all the inputs necessary to reproduce the error you see. And give us the actual error message - ALL the red text not just part of it, because we don't seem to have the error you did.

[Walter Roberson]

I read this as asking people to run it in other releases to determine whether the other releases are compatible -- that is, that the user wants to make the code portable and is wondering what changes to make to ensure portability.

[Image Analyst]

Well I thought that too. It's a little unclear though if "the error message" also appears in his R2015a version or not. If there's no error message the only reason I think it wouldn't run in a later version is if he used a deprecated function that has since been removed. And it wouldn't run in an older version if he used a new function that didn't exist in the old version. The help documentation tells whether functions are deprecated and when they were first introduced so that may help him determine compatibility.

[Ricardo Boza Villar]

No, my script works for me. But since I was going to give it to my professor, and I don't know the MATLAB version he uses, I wanted to know what to change in my program so that when he runs it he doesn't have any problems. That's all. Now I'm thinking the best option would be to write some comment telling the user to change anything that is a problem, because I don't think there is a good way to anticipate all errors the program might have in another versions.

Answer 1

[Jan]

This is a really ugkly start of a function:

clear variables, whitebg('w'), close all; clc, format compact, format long

1. clear variables clears all currently existing variables in the current workspace. At the start of a function this is meaningless, so simply omit it.
2. Setting the standard behavior with whitbg, and format might interfere with the preferences of other users. Therefore it is unfriendly to modify the default.
3. close all closes other dialog windows of Matlab. This impedes working with different programs and other users might hate, if your program deletes their work.
4. Clearing the CommandWindow by clc might hide important information like warning or error message. I would avoid it.

The code is monolitic. Splitting it into subfunction and using loops to avoid repeated code blocks would simplify it substantially. Then you can run unit-tests for the subfunctions to check, if they work as expected under different Matlab versions. Currently testing or debugging the code is nearly impossible, because it is one single massive block and contains too few comments to define the purpose of the code lines clearly.

If you have to adjust the code for a specific Matlab versions, many many almost equal editings are required. I'm sure that this cannot be done without typos. Using loops instead and subfunctions would be much simpler and more clear and than editing a single line would be enough.

Avoid gimmicks like pause(eps) . It might look funny, but pause uses a resolution of 0.01 seconds.

Hiding indices in the names of variables like "tx10", "p1" etc. is a bad idea. Using arrays instead will simplify the code.

Writing more than one command per line impedes Matlab's JIT acceleration and the debugging.

This disables a warning, which is thought to point out limitations with running on different Matlab versions:

warning('off','MATLAB:HandleGraphics:ObsoletedProperty:JavaFrame');

If you intention is to run the code with as many releases as possible, better use a method with TRY-CATCH.

[Walter Roberson]

The pause resolution is 0.001 seconds on osx

Answer 2

[Image Analyst]

You didn't say what to enter for inputs. I'm running R2016b and I put in 1 for all the inputs and it ran for a while and then crashed with this error message:

To use 'local2globalcoord', the following product must be both licensed and installed:
  Phased Array System Toolbox

I don't have that toolbox. I've added it to the Products section above.

[Ricardo Boza Villar]

Yes, writing 1 as input for all inputs is fine.

Ok, thank you!

[Image Analyst]

You should unaccept this since I really didn't solve anything.

[Ricardo Boza Villar]

Yes, but it's the intention that counts ;)

Answer 3

[Walter Roberson]

R2014a:

Error using contour3 (line 65)
Too many input arguments.
Error in x1 (line 185)
    contour3(x,y,z,30,'-','linewidth',1), title(string_3,'interpreter','latex','FontSize',13), axis equal, pause(2) % pause(0.1)

[Ricardo Boza Villar]

Thank you Walter!

But can you tell me how to solve the problem? I don't have release 2014, the 'help contour3' that I type on release 2015 must be different, because in R2015 the program runs ok with the inputs that I gave to that command.

[Walter Roberson]

In R2014a contour3 is not documented as permitting any option after the linespec.

The work-around is probably

[~, h] = contour3(x,y,z,30,'-');
set(h, 'LineWidth', 1);

This should work for both R2014a and before, and for R2014b and later. In R2014b and later, h would be a contour object, which has a LineWidth property directly. In R2014a and earlier, in the special case that you specified a linespec (which you did) then the h returned would be a vector of line objects, and those have LineWidth properties too.

If you had not specified '-' then in R2014a and earlier then h would be patch objects -- and they happen to have LineWidth properties as well.

[Ricardo Boza Villar]

Ok, got it.