Having Fun Yet?
Show older comments
Reverse compatibility for MATLAB is not very impressive.
>> fwave1
Warning: PACK can only be used from the MATLAB command line.
> In fwave1 (line 335)
Oh getting all these 20-30 year old programs to work with this "new and improved" version is going to be time consuming. Good thing I'm retired, and still have AT-MATLAB with gpp on a DOS machine. Hey, it'll keep me out of trouble. Probably should wait till I have a campfire and a beer. :-)
6 Comments
Adam
on 28 Feb 2017
Trying to get 20-30 year old code to work in software that has twice yearly updates is always going to be a significant task. I'm thankful I upgrade with each version of Matlab so that I can tackle any incompatibility problems just 1 version at a time (though in general there are next to none in most cases as backwards compatibility is very good). Of course we do have an ever increasing library of Matlab code going back over 10 years and most of which I don't currently use so getting some of that up to speed in the latest Matlab if I need to can be problematic, though in most cases due to my dreadful programming skills of 10 years ago!
Chris Conant
on 28 Feb 2017
Steven Lord
on 28 Feb 2017
Every so often, I believe Cleve starts up his original MATLAB and runs some code on it. For example, I bet he ran the code he posted in this article on that original version. As he said in the article, that code to compute the SVD of a particular matrix needed only one change.
In more recent releases, MATLAB has a unit testing framework that you could write to lock down the behavior of your ever increasing library of code, to help you detect when or if we make a change that affects it. For releases that predate the introduction of those frameworks, you could write script-based tests.
x = 1;
y = 2;
z = myAdditionFunction(x, y);
assert(z == 3)
Or if you want to go back before the introduction of the assert function in release R2007a:
x = 1;
y = 2;
z = myAdditionFunction(x, y)
if ~(z == 3), error('Test failed!'), end
I bet that would work back in some pretty darn old releases of MATLAB.
John D'Errico
on 28 Feb 2017
I do have MATLAB code that is nearly 30 years old, dating back to around 1987-1988. Still used, still works with no changes needed. But expecting 20-30 year code to always work perfectly given the amount of changes to computers and languages in that time is asking for trouble. Languages need to change sometimes, especially those that employ sophisticated mathematical algorithms, since on-going development on those algorithms sometimes necessitates that change.
For example, suppose that your code used quad. At one time, quad was the workhorse numerical integration routine in MATLAB. It has gone through many evolutions over the years as numerical analysts have come up with better ideas, more robust, more stable algorithms to solve the problem. Surprisingly, quad is still around. But if you read the help in quad, you will see this statement:
"quad will be removed in a future release. Use INTEGRAL instead."
Things change, and as they evolve, so must we. If not, then we must join the dinosaurs. Call me a bird-brain if you want, but I'm trying to avoid the fate of the dinosaurs. :)
Chris Conant
on 28 Feb 2017
Chris Conant
on 28 Feb 2017
Accepted Answer
More Answers (1)
Jan
on 28 Feb 2017
1 vote
A campfire and a beer is a valuable solution.
pack was an evil hammer to start a garbage collection and defragment the memory. On modern machines install enough RAM and omit all calls to pack.
I suffer from the the limited backward compatibility of Matlab also, but compared to other programming environments, Matlab is the most stable system I know. Especially pack is a bad example, because it was a really good idea to limit its power.
3 Comments
Chris Conant
on 28 Feb 2017
Edited: Stephen23
on 28 Feb 2017
Jan
on 28 Feb 2017
I'm still frustrated when I see how damn fast Matlab 5.3 or 6.5 starts in a virtual machine. While I wait endless seconds until the first figure is drawn by R2016b, they appear almost immediately in the ancient versions. Some weeks ago I ran some tests with compiled C-mex files and was 20% faster under R2009a.
Nevertheless, while Matlab 6.5 saves me seconds of runtime, the MLint code checker saves me hours for debugging. I will not miss uipanel's and uitree's anymore, nor the MExceptions in TRY/CATCH. I hate the auto-completion, but it is marvelous to rename all occurrences of a variable automatically.
Chris Conant
on 28 Feb 2017
Categories
Find more on Scripts in Help Center and File Exchange
Products
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!