Change of set function in the future

I've read the release notes of Matlab 2012a and found this: ReleaseNotes: Change of set functions. This does not concern 2012a! Then the output of unique etc. will contain the index of the first occurence and the indices are column instead of row vectors.

Does this change affect your work? Will it be a benefit for you? How many lines of code do you have to check to see, if you old programs will be compatible with this midification of standard functions?

Answer 1

[Penny Anderson]

Hi Jan,

The good news is that you have quite some time - several releases - in which to evaluate the impact of this change on your large code base. It need not be as complicated as you outline above.

1. Simply add a trailing 'R2012a' flag to all occurrences of the set functions in you code and run your test suite. 2. Any tests that fail - go back and change the 'R2012a' flag to 'legacy'. Re-run and those tests should now pass.

We understand large MATLAB codes exercising some of our oldest and most powerful features exist, and make it difficult to change those functions, even if the change is really a bug fix. Our hope is that by offering this phased approach to evaluate and buy into the new behavior will give customers a comfortable window in which to adopt it.

Please be in touch if you have other comments. They are always welcome!

Penny Anderson MathWorks, Inc.

[Jan]

Thank you very much for the answer, Penny.

It is a good news, that the change does not happen immediately. But this is relativized by the fact, that this is not the only change of a core function. There have been e.g. undocumented(!) changes in FOPEN and STRCMP in the past (I had gone into details enough in this forum). Therefore I really do appreciate the early and exhaustive documentation this time. Another very clear point is the well documented change of the 4th output of FILEPARTS - it has been set to the empty string in Matlab 6.5 already.

The removing of STRMATCH, DATAREAD/STRREAD and FINDSTR is documented, but means another bunch of additional work for me.

Adding the 'R2012a' flag in the code is *not* an option, because then the programs are not compatible with <=2011b anymore. Then I'd had to deliver two versions of my software to allow the users to compare the results. Afterware I'd had to maintain both versions, because I cannot force all of the different labs to buy a new Matlab license.

I see two reliable solutions:

1. I create wrappers for the set functions, which emulate the old behaviour under the new Matlab release.

2. My program does not support the new Matlab release.

In the past I used the method 2 and the labs used Matlab 6.5 for 6 years. This was cheap for them, but painful for me as programmer. It was hard to convince the labs to upgrade to 2009a: The costs for updating and testing the programs exceeded the costs for the new Matlab release by a factor of >10. But MLINT, UITREE/UITABLE, Win7 and 64 bit support are convincing enough.

Adding a flag in all occurrences and (re-)running the tests sounds easy. While the unit-tests are easy and can be performed on my local computer, the integration tests are more complicated. The software is used for clinical decision making and a "test" means, that the evaluations for the publications from the last 10 years must be proved to be reproducible. The outcomes of several TB of measurement data must be compared in different labs which are located in different continents.

Finally I see, that I have unrealistic expectations. A hyper-sensitive system used e.g. to make decisions about surgical operations of children cannot be distributed a source code which runs on arbitrary versions of the interpreter. Either the interpreter version must be fixed, or the source code must be compiled. While this is absolutely clear for e.g. C++ code, Matlab code has a 99.9% inter-release compatibility already. The remaining 0.1% are a shot in my knee.

A long-term supported Matlab release would be extremly useful: Bugs are fixed for several years, compatibility to new OS' is added (as far as possible), no new features to avoid the introduction of new errors. This would support serious and reliable applications written in Matlab - in opposite to the update-by-upgrade policy.

[Matt Fig]

How is this 'change' a 'bug fix'??

[Mike Hosea]

I am not aware of any significant bugs, but I am aware of several silly edge cases, such as union(zeros(0,1),zeros(0,1)) returning zeros(1,0). A collection of such bugs provided the impetus to examine the set functions thoroughly and holistically. The new versions enforce clear rules about output shapes, even in degenerate cases. Some useful functionality/flexibility was added in addition to fixing the bugs. Backward incompatibilities were a foregone conclusion with or without the added functionality, so once it was decided to have the 'R2012a' and 'legacy' flags to ameliorate that problem (with apologies to Jan, who understandably may not have felt adequately accommodated by it), I guess some liberty was taken to make the new default behavior what it arguably should have been all along vis-a-vis 'first' and 'last'.

Answer 2

[Jan]

The new features of the set functions are powerful and useful. I can add a 'last' flag to all of the unique commands in my code, if the old ordering scheme is required. And I can reshape the output manually to have the former row shape.

The only problem I have is, that I'm supporting a Matlab program with some hundred thousands code lines and I have to check more than 1500 occurences of these commands in my code. Either I analyse the surrounding code to see, if it adjustments are required, or I add the 'last' flag and an extra-line for the reshaping in general. Both solutions consume a remarkable amount of time, and both will set the status of the source code to not tested.

Therefore this change will mean for me:

• About 1500 minutes (25 hours) to check the code - one minute per occurence is a fair estimation, because some commands will use the first output only, while others will be more complicated.
• About 30 hours to run the unit-tests for the tool functions, compare their log files and some automated integration tests for the main functions.
• I have to create and deliver a new release, which is compatible with the new features. The documentation needs a small number of updates in consequence.
• The labs, which use this software, have to run the updated version for about two weeks in parallel to the old version to compare the results.

I see a general conflict between using or publishing large Matlab programs and upgrading the Matlab release. Distributing compiled programs is not an option, because the software is used for scientific projects and the ability to see and modify the source is important. The avoidance of the updating is not a sufficient option also, because existing bugs are usually fixed in newer releases only - e.g. the problems of audioplayer in 2011b are solved by installing 2012a.

The common appearence of 1. changes in the basic functions and 2. the bugfix by upgrade strategy is a very strong drawback, when large Matlab programs are used in scientific projects. What a pitty.