Thread Subject: matlab backward compatibility options

I've searched but couldn't find anything on the subject. The other
day, there were some talks at my company about acquiring a few matlab
licences for projects on a long term basis (we have some fortran code
from the sixties still in active use).

And one of the subjects that came up was whether matlab has some
official policy regarding backward compatibility - I, for once,
haven't been able to find it.

Does anyone know what is mathworks's stand on this, and how does
matlab rank practically when it comes to backwards compatibility ? For
example, on the current version, what is the oldest active code which
will still run without any modifications ?

with regards,
Miho

Dear Roni Miholovic!

> I've searched but couldn't find anything on the subject. The other
> day, there were some talks at my company about acquiring a few matlab
> licences for projects on a long term basis (we have some fortran code
> from the sixties still in active use).
>
> And one of the subjects that came up was whether matlab has some
> official policy regarding backward compatibility - I, for once,
> haven't been able to find it.
>
> Does anyone know what is mathworks's stand on this, and how does
> matlab rank practically when it comes to backwards compatibility ? For
> example, on the current version, what is the oldest active code which
> will still run without any modifications ?

To answer your last question: Matlab 2009b runs best with code for 2009b.
Even trivial tasks like calling SUM can have a slightly different behaviour in comparison to older versions: The new SUM can parallelize the computations and the rounding can lead to different results from call to call.

Some trivial tasks are compatible, e.g. "plot(sin(0:0.1:2*pi))", but in larger programs you can always find any incompatibilities between the Matlab versions even for well documented commands. Some examples from the past:
- Arrays of function handles @Fun(1:10). Then @Fun(1) was the first element of the list in one version, or a call to the function with the argument [1] in another version (and therefore function handles must be stored in a cell instead of an array now).
- FOPEN lost the ability to open binary files in the VaxD format in R2008b. It is mysterious to me, why the MathWorks team spent time to remove this support (in opposite to all other programming languages known be me), and why this did not appear in the documentation.
- MAT files written by Matlab 7 can be made compatible to Matlab 6 with "save -v6". Ironically this command is not compatible to Matlab 6 itself. So the save needs to check the Matlab version at first and than use SAVE without v6 flag for Matlab 6, with v6 for Matlab 7.
- Matlab 5.3 can read MAT files written by Matlab 6.5, but it crashes (the process dies on Windows without any error message), if a function handle is included in the file.
- UINT8 truncates arguments of type DOUBLE in Matlab 6, it rounds to the nearest integer in Matlab 7.
- After a button was pressed, it is not possible to give the focus back to the figure e.g. for keypress events in Matlab 2008a. In at least 2008b and 5.3 to 6.5 this can be done by setting the button's ENABLE property temporarily to 'off', but not by the command "figure(fig_handle)" as stated in the documentation.
- I have the impression, that I've read lots of problems related to GUIDE and to Java on MacOS X in this forum. So for a long term program, these two topics should be excluded. Matlab's dependencies to Java mean a general problem ever, because the JVM changes from time to time by automatical updates, and the user has no clue about immediately occuring errors.

I'll stop here. This newsgroup contains hundreds of further examples already.

The list of fixed, open and new bugs grows dynamically. Nevertheless, as far as I know, there are no bugfixes for older versions.

I'm working on medical studies and we must be able to reproduce our published results for 10 years. We started to measure 1998 with Matlab 5 on WindowsNT and published some data in 2006. I really hope, that WindowsNT is still running in a virtual PC, if somebody asks 2016 for an exact reproduction of the values (including eventual bugs of Matlab 5!).
So for my work, a long term support of a specific version would be really really important, too! I'm far more interested in stability and compatibility than in a bunch of new features.

Curiously waiting for a statement from the MathWorks team, Jan

On 23 Sep, 15:14, Roni Miholovic <rmiholo...@invalid.com> wrote:
> I've searched but couldn't find anything on the subject. The other
> day, there were some talks at my company about acquiring a few matlab
> licences for projects on a long term basis (we have some fortran code
> from the sixties still in active use).
>
> And one of the subjects that came up was whether matlab has some
> official policy regarding backward compatibility - I, for once,
> haven't been able to find it.
>
> Does anyone know what is mathworks's stand on this, and how does
> matlab rank practically when it comes to backwards compatibility ? For
> example, on the current version, what is the oldest active code which
> will still run without any modifications ?

Matlab has changed in a few ways, over the 20'ish years
I have used it:

- Functions have been moved from the basic lisences out
  to specialized toolboxes (filter design functions in
  matlab 3 have moved to the Signal Processing Toolbox)
- Functions have become obsolete in the sense that they have
  been redesigned / reimplemented / renamed (the REMEZ
  filter design algorithm is obsolete).

There aren't very many such functions, but it might be
enough to matter.

There is also a present development, as matlab evolves from
its origins as a lap tool, towards a jack-of-all-trades
computation system. I must admit that I haven't kept up
with all the newest bells and whistles, but it seems to me
that what the newest additions that work with the present
release might have to be re-coded after the features mature
over a couple of years.

If you are thinking code stability in the time frame of
decades, matlab might not be your first choise.

Rune

Thanks to everybody who has chimed in on this thread. Release compatibility is always a hot topic, and a big challenge faced by software developers. There's always a tension between maintaining compatibility and evolving the software with bug fixes and features that customers demand. You can look at Apple and Microsoft to see two very different approaches to the problem - Microsoft has put a huge emphasis on release compatibility (I occasionally hear of old DOS programs still running fine), while Apple has shown a willingness occasionally to throw lots away for the sake of moving forward (OS 9 to OS X was just the biggest example). There are obviously benefits and drawbacks to each approach.

The MathWorks does not currently have an official published policy regarding release compatibility, though we do take this topic quite seriously. We have processes and tooling in place to help us make the best overall decisions, but realize it's not possible to please everybody all of the time. We've been working hard on this for a while now, so I hope that users are finding newer releases on average to be doing better in this regard. This doesn't mean that we don't make incompatible changes, just that the ones we do make are hopefully well reasoned and in everybody's best interest.

- scott