Thread Subject: Do not upgrade to Matlab2009a

I've worked with almost all the recent Matlab releases (WinXP 32bits). With each new release, I discover a few improvements a many new bugs. For my use, the most stable appeared to be Matlab 2007b, that's why I've kept it for 2 years.

I upgraded to Matlab 2009a three weeks ago, and I regret it a lot: now it crashes at least 15 times per day, even because of really basic GUI operations (copy/paste, new file, open file, ...)
It is the most unstable Matlab version since a long time...

It's a shame to make people pay to get programs that are each time less reliable.

Mathworks should stop produce TWO new versions per year: one is enough, and they could spend the other six months to fix all the bugs introduced at each new release.
It was a good idea, but obviously it doesn't work.

Francois

Francois,
 It is regretable youve got therse problems but aren't you putting the blame a little to fast on MATLAB.
 I mean have you even tried to fins out why your having these problems? I know that most people can run matlab for at least several hours without crashes (atleast up to 8 hours at which there systems are turned off so I can't be sure about longer).

Also Windows it self is not known for its stabilitie so what is the last time you did a fresh install of that?

furter as a tip I can tell you to keep all of the tempory files and caches clean and as empty as possible. that often does more than the above.

Last I don't think this is the place to shoutout you don't like MatLab. your entitled to your opinion ofc but I would recommand first talking to the MathWorks support staff.

Francois -

I am sorry to hear that you are having so many problems with R2009A. I need to do some more poking around, but this is the first I've heard regarding serious quality/stability concerns of this release. It would be great if you could provide us with more specific information about what the issues are, so we dig into it for you. Your best bet is to contact technical support directly.

I'm curious if anybody else is having similar issues.

Thanks,
 -scott

"Francois Tadel" <francois.tadel@gmail.com> wrote in message <gs027a$8d1$1@fred.mathworks.com>...
> I've worked with almost all the recent Matlab releases (WinXP 32bits). With each new release, I discover a few improvements a many new bugs. For my use, the most stable appeared to be Matlab 2007b, that's why I've kept it for 2 years.
>
> I upgraded to Matlab 2009a three weeks ago, and I regret it a lot: now it crashes at least 15 times per day, even because of really basic GUI operations (copy/paste, new file, open file, ...)
> It is the most unstable Matlab version since a long time...
>
> It's a shame to make people pay to get programs that are each time less reliable.
>
> Mathworks should stop produce TWO new versions per year: one is enough, and they could spend the other six months to fix all the bugs introduced at each new release.
> It was a good idea, but obviously it doesn't work.
>
> Francois

I've run old ver 7.5 for 5 to 16 hours continuous under WinDoZ with no stability problems. trying do your work with -nojvm

On Apr 14, 7:02=A0am, "Francois Tadel" <francois.ta...@gmail.com> wrote:
> I've worked with almost all the recent Matlab releases (WinXP 32bits). Wi=
th each new release, I discover a few improvements a many new bugs. For my =
use, the most stable appeared to be Matlab 2007b, that's why I've kept it f=
or 2 years.
>
> I upgraded to Matlab 2009a three weeks ago, and I regret it a lot: now it=
 crashes at least 15 times per day, even because of really basic GUI operat=
ions (copy/paste, new file, open file, ...)
> It is the most unstable Matlab version since a long time...
>
> It's a shame to make people pay to get programs that are each time less r=
eliable.
>
> Mathworks should stop produce TWO new versions per year: one is enough, a=
nd they could spend the other six months to fix all the bugs introduced at =
each new release.
> It was a good idea, but obviously it doesn't work.
>
> Francois

I concur completely with Francois.
Indeed, I stopped upgrading at 2006b when I found that routines that
worked fine under 2006a did not work properly under 2006b.

For example, running matlab -r myfile from DOS executed the program
and closed down under 2006a, but stayed open under 2006b. This may
seem trivial, but I run numerous Matlab routines on a schedule and
when I came in the day after upgrading to 2006b, there were 40 Matlabs
open. This is not a bug, but an inconvenient change for no good
reason that I can see. Sure, it can be accommodated, but why should I
have to? So, I'm sticking with 2006a which is stable and has all the
features I need.

"Scott Hirsch" <shirsch.nospam@mathworks.com> wrote in message <gs1o66$9su$1@fred.mathworks.com>...
> Francois -
>
> I am sorry to hear that you are having so many problems with R2009A. I need to do some more poking around, but this is the first I've heard regarding serious quality/stability concerns of this release. It would be great if you could provide us with more specific information about what the issues are, so we dig into it for you. Your best bet is to contact technical support directly.
>
> I'm curious if anybody else is having similar issues.
>
> Thanks,
> -scott

Hi,
I am having some stability issues, but not very serious. 2009a has sometimes given pages of red javaLangOutOfMemory.... EventPump... UnknownSource... (can't remember exactly). Not often, but more than previous versions.
I am still usually able to use Matlab for days. I typically have Matlab (or two) open all the time with various things going on and carry my laptop around in "sleep" and only restart when I really have to (not even every week).
Though in my case 2009a is not the only new thing. I now have for the first time Vista 64 bit and 64 bit 2009a. Hard to tell which one is the reason.
But still not often enough to trigger me contacting tech support.
 

To Tideman -

Point made about the incompatible changes. It's always a challenge to find the right balance between preserving legacy behavior and continuing to evolve MATLAB to address user demands (both with new features and bug fixes). We try really hard to make sure we do the right thing, but realize it's not possible to please everybody all of the time.

As for the change in "matlab -r" behavior - can't you just put a call to QUIT or EXIT at the end of the code that needs to run (or wrap it in a script that calls the code then quits)? The reason I ask is that when assessing a proposal to make an incompatible change we look at the anticipated impact on our users, but we are guessing as to what various users' tolerances are for dealing with changes. If a change has seemingly easy/low-cost/acceptable workarounds, we are certainly more likely to consider it. I haven't given this particular change much thought, but I would have guessed that this one would have fallen under the easy workaround category.

Thanks as always for the input.

- scott

"Scott Hirsch" <shirsch.nospam@mathworks.com> wrote in message <gs4gst$pn3$1@fred.mathworks.com>...
> To Tideman -
>
> Point made about the incompatible changes. It's always a challenge to find the right balance between preserving legacy behavior and continuing to evolve MATLAB to address user demands (both with new features and bug fixes). We try really hard to make sure we do the right thing, but realize it's not possible to please everybody all of the time.
>
> As for the change in "matlab -r" behavior - can't you just put a call to QUIT or EXIT at the end of the code that needs to run (or wrap it in a script that calls the code then quits)? The reason I ask is that when assessing a proposal to make an incompatible change we look at the anticipated impact on our users, but we are guessing as to what various users' tolerances are for dealing with changes. If a change has seemingly easy/low-cost/acceptable workarounds, we are certainly more likely to consider it. I haven't given this particular change much thought, but I would have guessed that this one would have fallen under the easy workaround category.
>
> Thanks as always for the input.
>
> - scott

matlab should stop trying to release new versions and fix damn bugs, get out of that microsoft mentality of release buggy software. that's why virtually no one is buying Vista, it's bloated CRAP. latest version of Matlab appears to be the same, throw out something new instead of fixing existing problems. this is what happens when sales and marketing weenies drive a company.

"Chaos" <rothko.fan@gmail.com> wrote in message <gs4i0h$6um$1@fred.mathworks.com>...
> "Scott Hirsch" <shirsch.nospam@mathworks.com> wrote in message <gs4gst$pn3$1@fred.mathworks.com>...

> matlab should stop trying to release new versions and fix damn bugs, get out of that
>microsoft mentality of release buggy software. that's why virtually no one is buying
>Vista, it's bloated CRAP. latest version of Matlab appears to be the same, throw out
>something new instead of fixing existing problems. this is what happens when sales
>and marketing weenies drive a company.

Choas, its clear to me you've never worked in a Software Produciton enviroment, based on these kind of reactions. as Scott was saying, ther eis always a trade off between fixxing bugs, implementing (user requested) changes, introducing new features,maintaining lagacy. A company with a product as widely used as MATLAB will most likely be working mainly on bug fixes and User requested changes. as for people not using / buying Microsoft products, thats a bad analogy. mainly becouse OEM'
ers dont give consumers (and companies) a whole lot of choice. tis there way or the high way. not so with the mathworks. if you have a need that The mathworks can fill, theat need can be filled also with opensource software. true you wont have a ready made solution. but it is possible.

you are as always intitled to your opion, but try not to thrust it down other peoples throat...

It's disappointing that this is how you (and presumably other MATLAB users) feel. We made a huge shift from focusing on new features to focusing on quality starting right after the release of R14. We had several releases that were mostly bug fixes (sp1, sp2, sp3), only starting to bring in features once we felt bugs were under control. We continue to have a very high focus on quality, both on improving the quality of the existing product and ensuring that new features are introduced with high quality.

As always, it's what you all experience as you use the products in the real world to do real work that counts, so we take input like this very seriously. I'm very interested in hearing reactions from the community.

 - scott
(your MATLAB marketing weeny, who only wishes he were driving the company)

"Lawri " <removethis.external.lawri.vanbuel@nl.bosch.com.removethis> wrote in message <gs4k7p$8m$1@fred.mathworks.com>...
> "Chaos" <rothko.fan@gmail.com> wrote in message <gs4i0h$6um$1@fred.mathworks.com>...
> > "Scott Hirsch" <shirsch.nospam@mathworks.com> wrote in message <gs4gst$pn3$1@fred.mathworks.com>...
>
> > matlab should stop trying to release new versions and fix damn bugs, get out of that
> >microsoft mentality of release buggy software. that's why virtually no one is buying
> >Vista, it's bloated CRAP. latest version of Matlab appears to be the same, throw out
> >something new instead of fixing existing problems. this is what happens when sales
> >and marketing weenies drive a company.
>
> Choas, its clear to me you've never worked in a Software Produciton enviroment, based on these kind of reactions. as Scott was saying, ther eis always a trade off between fixxing bugs, implementing (user requested) changes, introducing new features,maintaining lagacy. A company with a product as widely used as MATLAB will most likely be working mainly on bug fixes and User requested changes. as for people not using / buying Microsoft products, thats a bad analogy. mainly becouse OEM'
> ers dont give consumers (and companies) a whole lot of choice. tis there way or the high way. not so with the mathworks. if you have a need that The mathworks can fill, theat need can be filled also with opensource software. true you wont have a ready made solution. but it is possible.
>
> you are as always intitled to your opion, but try not to thrust it down other peoples throat...

no Ali, not in a 'Production' environment. we write code that 'actually' works in real-time, 24x7.

so what dept of matlab do you work in?

i'm surprised you didn't try to mention a solution that involved buying some kind of expensive toolbox.

i don't thrust anything down people's throat, i express my many years of hard-core engineering experience in the 'real world' not some cushy "Production" software environment where they have no clue about the 'real' world usage. i express them directly and to the point.

you are free to interpret that however you like but don't even begin to try and lecture me on 'shoving down people throat'.

if you look at my posts in replies to people's question, mine are 95% correct.

so i will continue to express myself, so piss off, the usenet is free for anyone to post.

take a hint if you see a post with my name DON"T read it, if it offends your sensitivities.

if i see a post of yours that is lame or fails to the point, i will post a answer that rips your apart.

On Apr 15, 11:37=A0pm, "Scott Hirsch" <shirsch.nos...@mathworks.com>
wrote:
> To Tideman -
>
> As for the change in "matlab -r" behavior - can't you just put a call to =
QUIT or EXIT at the end of the code that needs to run (or wrap it in a scri=
pt that calls the code then quits)? =A0The reason I ask is that when assess=
ing a proposal to make an incompatible change we look at the anticipated im=
pact on our users, but we are guessing as to what various users' tolerances=
 are for dealing with changes. =A0If a change has seemingly easy/low-cost/a=
cceptable workarounds, we are certainly more likely to consider it. =A0I ha=
ven't given this particular change much thought, but I would have guessed t=
hat this one would have fallen under the easy workaround category. =A0
>

Yes, it is easily changed, but why should I have to?
I'm using Matlab for producing plots that go onto several webpages
hourly.
As a result of that change to Matlab 2006a, I would have to go through
a dozen or so schedules and add quit to each one, maybe introducing
unforeseen bugs in the process. Then there would be the ones that I
missed that I'd have to fix later, and so on. All this hassle for
some incremental (and probably inconsequential) improvement in the
program.

Contrast this with a language like Fortran, where stuff that was
written in Fortran IV 40 years ago still works today.

Dear Scott!

I am surprised by the emotions in this discussion. The facts are simple:
1. Upgrade means: new features, new bugs, some fixed old bugs, some incompatibilities.
2. No upgrade means: no new features, no new bugs, no fixed bugs, no incompatibilities.
This is the classical behaviour of complex systems and not restricted to powerful software. As consequence the decision depends on the demands of the user: If you need new features, buy a new release and be frightened of new bugs. If you need a reliable system with known limitations/bugs, stay at the running and tested release.

Users can control (not avoid!) problems in current versions by participating in this newsgroup and reading the release notes on the Mathworks web pages. Unfortunately, these web pages are not complete, e.g. I was not able to find the information, in which release FOPEN stopped supporting files in VAX-D format, because the function reference can be explored for the current Matlab release only (am I right?). After I moaned in this newgroup, a friendly employee of Mathworks contacted me and offered to convert my files! Although this was impossible, because it concerned 50.000 files containing clinical measurements of patients, I was absolutely satisfied with the service. It took me 2 weeks to figuring out the problem and writing a conversion tool.

Scott wrote:
> ...The reason I ask is that when assessing a proposal to make an incompatible change we look at the anticipated impact on our users, but we are guessing as to what various users' tolerances are for dealing with changes. If a change has seemingly easy/low-cost/acceptable workarounds, we are certainly more likely to consider it.

Remaining questions:
By which method do you estimate the complexity/cost/acceptance of workarounds for incompatible changes? How does Mathworks get feedback before an incompatible change is inserted in a published release?
Do you think, the list of open bugs (http://www.mathworks.com/support/bugreports/) will get longer or shorter in 2009?

Kind regards, Jan

"Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message <gs5u4e$77o$1@fred.mathworks.com>...
> Dear Scott!
>
> I am surprised by the emotions in this discussion. The facts are simple:
> 1. Upgrade means: new features, new bugs, some fixed old bugs, some incompatibilities.
> 2. No upgrade means: no new features, no new bugs, no fixed bugs, no incompatibilities.
> This is the classical behaviour of complex systems and not restricted to powerful software. As consequence the decision depends on the demands of the user: If you need new features, buy a new release and be frightened of new bugs. If you need a reliable system with known limitations/bugs, stay at the running and tested release.

I would be interested to know the criteria used by The MathWorks to select and prioritize new features. Similarly how to rank the severity of known bugs. Do large customers influence development policies? Or is everything decided from within?

- Steve

Hello,

I understand that is very frustrating to downgrade a version software after being exited with its new features. When I install a new release of matlab, I always do my proper "check list" mainly articulated around Matrix computations. I like some of new features of Matlab and new directions taken, but I don't want to have at the end an "enormous monster" eating half Ram just to be lunched.

Well, it's not the topic of the subject, but can we imagine a Matlab 2011 (maybe earlier) where computations are deported on GPU with either CUDA/OpenCV API standard ? (I know there is an excellent third party software doing this job, but I think, it should be included in the main package) ...

Another question : Is 64bits architecture is now more competitive than 32 ? (Matlab & used lib especially compiled in 64 bits ?)


Sebastien


"Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message <gs5u4e$77o$1@fred.mathworks.com>...
> Dear Scott!
>
> I am surprised by the emotions in this discussion. The facts are simple:
> 1. Upgrade means: new features, new bugs, some fixed old bugs, some incompatibilities.
> 2. No upgrade means: no new features, no new bugs, no fixed bugs, no incompatibilities.
> This is the classical behaviour of complex systems and not restricted to powerful software. As consequence the decision depends on the demands of the user: If you need new features, buy a new release and be frightened of new bugs. If you need a reliable system with known limitations/bugs, stay at the running and tested release.
>
> Users can control (not avoid!) problems in current versions by participating in this newsgroup and reading the release notes on the Mathworks web pages. Unfortunately, these web pages are not complete, e.g. I was not able to find the information, in which release FOPEN stopped supporting files in VAX-D format, because the function reference can be explored for the current Matlab release only (am I right?). After I moaned in this newgroup, a friendly employee of Mathworks contacted me and offered to convert my files! Although this was impossible, because it concerned 50.000 files containing clinical measurements of patients, I was absolutely satisfied with the service. It took me 2 weeks to figuring out the problem and writing a conversion tool.
>
> Scott wrote:
> > ...The reason I ask is that when assessing a proposal to make an incompatible change we look at the anticipated impact on our users, but we are guessing as to what various users' tolerances are for dealing with changes. If a change has seemingly easy/low-cost/acceptable workarounds, we are certainly more likely to consider it.
>
> Remaining questions:
> By which method do you estimate the complexity/cost/acceptance of workarounds for incompatible changes? How does Mathworks get feedback before an incompatible change is inserted in a published release?
> Do you think, the list of open bugs (http://www.mathworks.com/support/bugreports/) will get longer or shorter in 2009?
>
> Kind regards, Jan

On Apr 16, 6:00=A0pm, "Steve Amphlett" <Firstname.Lastn...@Where-I-
Work.com> wrote:
 =A0Do large customers influence development policies?
>
> - Steve

Well, I'm rather large at 110 kg, but I've had no luck in getting
action, so I guess that settles that.
Maybe I should use my size to threaten someone at TMW?

Thanks again to everybody for some great discussion. I'll try my best to address the questions that were raised.

@Jan:
I think Jan really nailed the approach to upgrading to new releases of software. Users must always trade off benefits from new stuff vs. cost from stuff that has changed. We certainly do this with all of our critical software internally, whether it is a new C compiler or a new version of the software we use to create tutorial videos.

The vaxd file format issue Jan mentions is one that I'm not proud of. This represented a breakdown in our release compatibility process, where the proper assessment and communication was not made.

Estimating impact and getting feedback on incompatible changes:
This is definitely a black art, and one that we are always looking for ways to get better data. Our best tools seem to be searching code to get an idea of how much (and how) something is used. We search our (rather large) internal code base, plus external code on the File Exchange and posted elsewhere on the web (thank you, Google code search!!). After we have implemented a first pass of making a change, we see what happens. We check for breaks in our internal code, and in representative code from users.

We know that this doesn't catch everything, so then we turn to our instincts. We rack our brains trying to think of ways users might have come to rely on any given functionality. It's definitely challenging, since MATLAB users are probably some of the most "creative" coders in the world :).

Getting feedback before a change has been made for good is also tough. Our best mechanism is the prerelease, which is made available to all customers with current subscriptions a few months before each release. The primary intention of the prerelease is to check for compatibility issues. We also occasionally implement surveys to assess impact while we are fazing something out. You might come across a warning message that behavior is likely to change that includes a link to fill out a quick survey to let us know how this would affect you.

@Steve:
How do we select and prioritize new features?
We make decisions based on many different sources of data, and the weight of different sources can vary based on the particular product and the market it serves. For instance, our approach to prioritizing features for MATLAB (25 years old, with over 1,000,000 users) is necessarily quite different that our approach to prioritizing features for Simulink HDL Coder (newer, smaller, more targeted market).

The short answer is that data comes from everywhere. Here's a partial list of the places we turn to for data:
 - Files posted on File Exchange. Popular files can indicate a strong need, such as with the versions of xlswrite and datatips I posted back in the R13 days.
 - Discussions on CSSM
 - Discussions on blogs, about MATLAB and other software
 - Interviews with customers, from accounts of any size.
 - Meetings with customers, from accounts of any size.
 - MATLAB User Survey, as we conducted again last fall.
 - Enhancement requests from customers, entered on our web site or passed along through members of The MathWorks field organization.
 - Discussions with our trainers, application engineers, and consultants. These guys are closest to all of you, and they help us spot key trends among our customers. I spent 7 years as an Application Engineer,which has really informed my understanding of our users.
 - Our own brains. We live, eat, and breathe MATLAB. We know what features we would love to have for ourselves.
 - MathWorks developers who need stuff to make their code work better.
 - Usability tests.
 - Advisory boards.

The key point is - make your voice heard. When we hear lots of voices supporting an idea, we tend to think it's more valuable. One other key - help us understand WHY a feature is important to you. This is absolutely essential.

My email is on my File Exchange page, so feel free to look me up and drop me a line.

@Sebastien:
32-bit vs 64-bit:
In general, we expect performance to be about the same between 32-bit and 64-bit. The #1 (and #2 and #3) reason for going to 64-bit is for memory - you blow open your total addressable memory space from 2-4GB up to something like 8TB. You'll still have performance issues when you exceed your computer's physical RAM, but you won't hit the hard limit you may run across on 32-bit.

GPUs:
I'll spawn this off as a separate thread of discussion.

Wow, I just realized I spent all morning, and 2 cups of coffee responding to this thread. I hope I've given you some insight into our thinking. We're always looking for more robust ways to make the right decisions for you, so keep the input coming.

 - scott

Whilst on the MathWorks site to upgrade to R2009a, the title of this thread caught my attention (!). Anyway, after reading most of the posts, it occurred to me that a tool that would allow users to evaluate the impact of moving to the next release before making the decision to would be a tremendous asset. Presumably, like any high-quality software developer, TMW evaluates and approves all changes that it intends to include in its next release. I am suggesting that TMW build these known changes into a tool that users download and use to scan their existing scripts, models, etc. for potential compatibility issues. If this is done early enough, TMW will get valuable feedback on the impact of changes on the user base, and could make more informed decisions about what features to change, and which to leave alone. (This would, of course, not address unintended side effects and bugs.)

I, for one, would prefer to have the potential effects of API changes identified before going through the trouble of installing a new version, and then having my code break when it is supposed to be making money.

"Scott Hirsch" <shirsch.nospam@mathworks.com> wrote in message <gs79p9$n10$1@fred.mathworks.com>...
> Thanks again to everybody for some great discussion. I'll try my best to address the questions that were raised.
>
> @Jan:
> I think Jan really nailed the approach to upgrading to new releases of software. Users must always trade off benefits from new stuff vs. cost from stuff that has changed. We certainly do this with all of our critical software internally, whether it is a new C compiler or a new version of the software we use to create tutorial videos.
>
> The vaxd file format issue Jan mentions is one that I'm not proud of. This represented a breakdown in our release compatibility process, where the proper assessment and communication was not made.
>

> - scott

I am responding to this thread because of the vaxd file format getting lost! I am currently using 2008a and can still read in my files from 1975. So to upgrade I will either need to convert all my files (a major pain in the ass) or just lose the ability to read in the files (not acceptable). I would like to put in my vote for the vaxd file format coming back!!!!

Steph

"Scott Hirsch" <shirsch.nospam@mathworks.com> wrote in message <gs79p9$n10$1@fred.mathworks.com>...
> Thanks again to everybody for some great discussion. I'll try my best to address the questions that were raised.
>
> @Jan:
> I think Jan really nailed the approach to upgrading to new releases of software. Users must always trade off benefits from new stuff vs. cost from stuff that has changed. We certainly do this with all of our critical software internally, whether it is a new C compiler or a new version of the software we use to create tutorial videos.
>
> The vaxd file format issue Jan mentions is one that I'm not proud of. This represented a breakdown in our release compatibility process, where the proper assessment and communication was not made.
>

> - scott

I am responding to this thread because of the vaxd file format getting lost! I am currently using 2008a and can still read in my files from 1975. So to upgrade I will either need to convert all my files (a major pain in the ass) or just lose the ability to read in the files (not acceptable). I would like to put in my vote for the vaxd file format coming back!!!!

Steph

Steph -

You might want to check out this submission on the File Exchange, which Mike put up to help people with precisely this issue:

"Read VAXD and VAXG files in R2008b and later"
http://www.mathworks.com/matlabcentral/fileexchange/22675

- scott

"Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message <gs5u4e$77o$1@fred.mathworks.com>...

> I am surprised by the emotions in this discussion. The facts are simple:
> 1. Upgrade means: new features, new bugs, some fixed old bugs, some incompatibilities.
> 2. No upgrade means: no new features, no new bugs, no fixed bugs, no incompatibilities.


I am quite frustrated, because we payed for 2 years the Matlab Software Maintenance (Matlab + Compiler, Signal Processing and Filter Design Toolbox) and i am still working on R2007b. In my opinion the last stable version of Matlab. Since R2008a i had big stability issues under GUIDE and with Java commands.

Rather than get into a religious debate, I'd just like to say that my copy of 2009a (and the last 2 years worth of versions) runs fine for weeks without crashes, memory leaks, or anything irritating that's not easy to fix. This is doing physical simulations, numerical analysis and other cpu intensive number crunching. It runs as fast as one would expect, so I'm completely happy with the product.

As the original post (and followups by 'Chaos' etc) felt the need to get emotional instead of delving into specifics of their problems, I suspect these might be a collection of PEBKAC errors.

Dear Stephan Hoffmann!
> > I am surprised by the emotions in this discussion.
> I am quite frustrated, because we payed for 2 years the Matlab Software Maintenance [...]. Since R2008a i had big stability issues under GUIDE and with Java commands.

Ok, this clears my question about the emotions: You have paid for a service, you cannot use. And this service is called "maintenance", but you cannot get the feeling, that something is "maintained". Then frustration is a reasonable reaction.

What eatcly does "stablity issue" mean? Do programs, running fine under 2007a, crash 2008b and 2009a? Are new features concerned or are the problems caused by the removal of old functions? Did you get help here in the newsgroup or directly from the Mathworks team?

Beyond the emotions, can you imagine a strategy to satisfy your needs for stability? According to my experiences, the Mathworks team is interested in satisfying the user's needs, because this is strongly correlated with earning money. Nevertheless, I cannot find a well defined public interface between the user's voice and the quality management of TMW.

There is such an interface in the FileExchange: The users can rate the quality of functions with stars and explicit comments. I'm still wondering, why the TWM does not use the incredible cheap comments of the users for the toolbox functions. I think, this is worth to start a new thread.

Kind regards, Jan

"Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message
news:gurkae$2h7$1@fred.mathworks.com...
> Dear Stephan Hoffmann!
>> > I am surprised by the emotions in this discussion.
>> I am quite frustrated, because we payed for 2 years the Matlab Software
>> Maintenance [...]. Since R2008a i had big stability issues under GUIDE
>> and with Java commands.
>
> Ok, this clears my question about the emotions: You have paid for a
> service, you cannot use. And this service is called "maintenance", but you
> cannot get the feeling, that something is "maintained". Then frustration
> is a reasonable reaction.
>
> What eatcly does "stablity issue" mean? Do programs, running fine under
> 2007a, crash 2008b and 2009a? Are new features concerned or are the
> problems caused by the removal of old functions? Did you get help here in
> the newsgroup or directly from the Mathworks team?
>
> Beyond the emotions, can you imagine a strategy to satisfy your needs for
> stability? According to my experiences, the Mathworks team is interested
> in satisfying the user's needs, because this is strongly correlated with
> earning money. Nevertheless, I cannot find a well defined public interface
> between the user's voice and the quality management of TMW.

There are two "well defined public interface" mechanisms: they are our
Customer Service and Technical Support departments.

http://www.mathworks.com/company/aboutus/contact_us/?s_cid=docframe_aboutus_contact_us

If you're having a problem with your license, contact our Customer Service
department. If you're having a problem with the technical capabilities of
our products, contact Technical Support.

If you send Technical Support a description of what your workflow is with
GUIDE when you experience a "stability issue" (and what you mean by
"stability issue" -- does MATLAB throw a warning, throw an error, do
something unexpected, crash, etc.) if it's an issue that others have
reported, they may have a solution available; if not, they can forward the
information you provide about the problem to the development staff so that
the developers can determine what's causing the problem and how to fix it.

> There is such an interface in the FileExchange: The users can rate the
> quality of functions with stars and explicit comments. I'm still
> wondering, why the TWM does not use the incredible cheap comments of the
> users for the toolbox functions. I think, this is worth to start a new
> thread.

Thank you for reminding me, that's a third "well defined public interface"
mechanism. If you have a comment about the content of one of our
documentation pages (I'm arbitrarily choosing the SYSTEM page to use to
demonstrate)

http://www.mathworks.com/access/helpdesk/help/techdoc/ref/system.html

go to one of the right-hand corners of the page. You should see a link
"Provide feedback about this page". You can enter comments about the page
there, whether it be "This page could use more examples!" or "I don't
understand what's in the Note box -- can you clarify it?" I know these
links are present in the online documentation, and they've been in the Help
Browser for at least a few releases -- I don't know if they're present in
the version you're using.

Note that this feedback mechanism is specifically intended for
comments/questions about the reference pages; if you have a general comment
about or a problem with how the function works, that's probably better sent
to Technical Support.

--
Steve Lord
slord@mathworks.com

Dear Steven Lord!

> There are two "well defined public interface" mechanisms: they are our
> Customer Service and Technical Support departments.
>
> [...] If you're having a problem with the technical capabilities of
> our products, contact Technical Support.
>
> [...] that's a third "well defined public interface"
> mechanism. If you have a comment about the content of one of our
> documentation pages (I'm arbitrarily choosing the SYSTEM page to use to
> demonstrate)
> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/system.html
> go to one of the right-hand corners of the page.
>[...]
> Note that this feedback mechanism is specifically intended for
> comments/questions about the reference pages;

Thank you for answering and pointing to these 3 interfaces, which are very important for the discussed topic. Stability and reliability of complex systems can be reached only with (such) feedback systems.

However, it seems like I've not been clear enough with my last post (most likely based on tha fact, that English is not my native language): It's not **me** who have stability issues with Matlab. I am satisfied with the versions I use, which is based on 4 points:
1) The vast majority of Matlab function work well - in my personal opinion Matlab 6.5.1 and 2008b are >99.9% bugfree. Well done!
2) The most problems appearing inspite of point 1) can be solved by discussions in the Newsgroup (thanks to all the active members!).
3) As experineced programmer I know, that Matlab -as each programming system- has limitations and I consider this in a quite defensive programming style. Following Kurt G?del, every complex system can be crashed. So stability is also in the responsibility of the programmers, not just a "fault" of the underlying system. (A little bit arrogant, I know)
4) For really hard problems, the Technical Support of TMW works competent and highly motivated. After my contacts with the Technical Support, I was pleased to fill out a feedback form to rate the effectiveness of the support! (By the way, this is a 4th "well defined public interface"!).

In conclusion, it is my opinion that some of the posts of this thread are not complete: "I have stability issues" is just the half story. Therefore I asked, what has been performed to solve them. Only if the posters would have replied, that neither the Newsgroup nor the Technical support can help to solve the problem or assist by searching a workaround, there is a "stability issue" according to my definition.

However, beside my personal positive experiences with Matlab and its Support, I meant something different with "**public** interface". The intefaces you mentioned have a direction from the user to the MathWorks team. With "public" I meant, that the number of problems and the degree of satisfaction with the support can be seen by the users.

I'm using improved (mostly accelerated) versions of BLANKS, IND2RGB, ISCELLSTR, NOW, STRVCAT, TEMPDIR, @CELL/STRCAT, FGETL, GRADIENT, STRTOK and WAVPLAY. Beside this I think PATHSEP, FILESEP, ISPC, ISUNIX can be accelerated by adjust them to the operating system to save processing time. Is somebody interested in such ideas?! I cannot publish the files in the FEX, because this would interfer with the license conditions.

Finally I am still missing a platform, which help me to decide, which version of Matlab I should buy, if I want to upgrade from 6.5.1 and my absolute main interest is stability?

Kind regards, Jan

"Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message
news:gv1fjf$h8e$1@fred.mathworks.com...
> Dear Steven Lord!
>
>> There are two "well defined public interface" mechanisms: they are our
>> Customer Service and Technical Support departments.
>>
>> [...] If you're having a problem with the technical capabilities of
>> our products, contact Technical Support.
>>
>> [...] that's a third "well defined public interface"
>> mechanism. If you have a comment about the content of one of our
>> documentation pages (I'm arbitrarily choosing the SYSTEM page to use to
>> demonstrate)
>> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/system.html
>> go to one of the right-hand corners of the page.
>>[...]
>> Note that this feedback mechanism is specifically intended for
>> comments/questions about the reference pages;
>
> Thank you for answering and pointing to these 3 interfaces, which are very
> important for the discussed topic. Stability and reliability of complex
> systems can be reached only with (such) feedback systems.
>
> However, it seems like I've not been clear enough with my last post (most
> likely based on tha fact, that English is not my native language): It's
> not **me** who have stability issues with Matlab. I am satisfied with the
> versions I use, which is based on 4 points:
> 1) The vast majority of Matlab function work well - in my personal opinion
> Matlab 6.5.1 and 2008b are >99.9% bugfree. Well done!
> 2) The most problems appearing inspite of point 1) can be solved by
> discussions in the Newsgroup (thanks to all the active members!).
> 3) As experineced programmer I know, that Matlab -as each programming
> system- has limitations and I consider this in a quite defensive
> programming style. Following Kurt G?del, every complex system can be
> crashed. So stability is also in the responsibility of the programmers,
> not just a "fault" of the underlying system. (A little bit arrogant, I
> know)
> 4) For really hard problems, the Technical Support of TMW works competent
> and highly motivated. After my contacts with the Technical Support, I was
> pleased to fill out a feedback form to rate the effectiveness of the
> support! (By the way, this is a 4th "well defined public interface"!).

Yes, I'd forgotten about the feedback forms that Technical Support
management sends out asking for comments about your ("your" meaning the
person who contacted support, not just you, Jan) support experience.

> In conclusion, it is my opinion that some of the posts of this thread are
> not complete: "I have stability issues" is just the half story. Therefore
> I asked, what has been performed to solve them. Only if the posters would
> have replied, that neither the Newsgroup nor the Technical support can
> help to solve the problem or assist by searching a workaround, there is a
> "stability issue" according to my definition.
>
> However, beside my personal positive experiences with Matlab and its
> Support, I meant something different with "**public** interface". The
> intefaces you mentioned have a direction from the user to the MathWorks
> team. With "public" I meant, that the number of problems and the degree of
> satisfaction with the support can be seen by the users.

So you're asking for Technical Support to share some of the feedback they've
been given in a public forum, like CSSM or the support webpage? I'm not
sure that's feasible, unless we were to ask on the feedback form if users
would allow us to post their feedback, plus (hopefully) most of the feedback
is positive, so I could see people accusing us of not posting all the
negative feedback we've received simply because there's more positive than
negative.

> I'm using improved (mostly accelerated) versions of BLANKS, IND2RGB,
> ISCELLSTR, NOW, STRVCAT, TEMPDIR, @CELL/STRCAT, FGETL, GRADIENT, STRTOK
> and WAVPLAY. Beside this I think PATHSEP, FILESEP, ISPC, ISUNIX can be
> accelerated by adjust them to the operating system to save processing
> time. Is somebody interested in such ideas?! I cannot publish the files in
> the FEX, because this would interfer with the license conditions.

If there are specific improvements you'd like to see us incorporate into the
product, let Technical Support know. I can't guarantee we'll implement all
of them (after all, the easiest way to accelerate these functions would be
to rip out all that pesky time-consuming error checking code and let the
functions give the wrong answer/error/crash if the user passed in the wrong
data, right? Not going to happen. But if there's redundant checking or if
you can think of a more efficient way to perform the error checking, we'd
like to know.) but Technical Support can enter them into the enhancement
database.

> Finally I am still missing a platform, which help me to decide, which
> version of Matlab I should buy, if I want to upgrade from 6.5.1 and my
> absolute main interest is stability?

I don't really have a good answer for you to this question. What are your
requirements? Which OS are you going to be using? 32-bit or 64-bit? What
types of applications are you going to be working on? [For instance, if
you're working on a graphics-intensive application but you're not working
with the FFT, then any bugs that would affect graphics or graphics
performance would be show-stoppers, but a bug in the FFT routines might not
be -- and vice versa if you're running without a display but
batch-performing FFTs on thousands or tens of thousands of data sets.] Do
you need to interface MATLAB with hardware or another application (which
could impact your choice of OS, among other things.)

In general, I would default to the most recent release that meets your
requirements -- if you're not sure which that is, you can contact your sales
representative (or our general sales staff) and describe what you're trying
to do. You can also take a look at the online Bug Reports page:

http://www.mathworks.com/support/bugreports/

and see if there are any bugs that would critically impact your work. Sorry
I can't provide a more specific answer, but that particular question's much
trickier than it sounds at first glance.

--
Steve Lord
slord@mathworks.com

R2009a works fine for me ...



"Steven Lord" <slord@mathworks.com> wrote in message <gv3o9e$pce$1@fred.mathworks.com>...
>
> "Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message
> news:gv1fjf$h8e$1@fred.mathworks.com...
> > Dear Steven Lord!
> >
> >> There are two "well defined public interface" mechanisms: they are our
> >> Customer Service and Technical Support departments.
> >>
> >> [...] If you're having a problem with the technical capabilities of
> >> our products, contact Technical Support.
> >>
> >> [...] that's a third "well defined public interface"
> >> mechanism. If you have a comment about the content of one of our
> >> documentation pages (I'm arbitrarily choosing the SYSTEM page to use to
> >> demonstrate)
> >> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/system.html
> >> go to one of the right-hand corners of the page.
> >>[...]
> >> Note that this feedback mechanism is specifically intended for
> >> comments/questions about the reference pages;
> >
> > Thank you for answering and pointing to these 3 interfaces, which are very
> > important for the discussed topic. Stability and reliability of complex
> > systems can be reached only with (such) feedback systems.
> >
> > However, it seems like I've not been clear enough with my last post (most
> > likely based on tha fact, that English is not my native language): It's
> > not **me** who have stability issues with Matlab. I am satisfied with the
> > versions I use, which is based on 4 points:
> > 1) The vast majority of Matlab function work well - in my personal opinion
> > Matlab 6.5.1 and 2008b are >99.9% bugfree. Well done!
> > 2) The most problems appearing inspite of point 1) can be solved by
> > discussions in the Newsgroup (thanks to all the active members!).
> > 3) As experineced programmer I know, that Matlab -as each programming
> > system- has limitations and I consider this in a quite defensive
> > programming style. Following Kurt G?del, every complex system can be
> > crashed. So stability is also in the responsibility of the programmers,
> > not just a "fault" of the underlying system. (A little bit arrogant, I
> > know)
> > 4) For really hard problems, the Technical Support of TMW works competent
> > and highly motivated. After my contacts with the Technical Support, I was
> > pleased to fill out a feedback form to rate the effectiveness of the
> > support! (By the way, this is a 4th "well defined public interface"!).
>
> Yes, I'd forgotten about the feedback forms that Technical Support
> management sends out asking for comments about your ("your" meaning the
> person who contacted support, not just you, Jan) support experience.
>
> > In conclusion, it is my opinion that some of the posts of this thread are
> > not complete: "I have stability issues" is just the half story. Therefore
> > I asked, what has been performed to solve them. Only if the posters would
> > have replied, that neither the Newsgroup nor the Technical support can
> > help to solve the problem or assist by searching a workaround, there is a
> > "stability issue" according to my definition.
> >
> > However, beside my personal positive experiences with Matlab and its
> > Support, I meant something different with "**public** interface". The
> > intefaces you mentioned have a direction from the user to the MathWorks
> > team. With "public" I meant, that the number of problems and the degree of
> > satisfaction with the support can be seen by the users.
>
> So you're asking for Technical Support to share some of the feedback they've
> been given in a public forum, like CSSM or the support webpage? I'm not
> sure that's feasible, unless we were to ask on the feedback form if users
> would allow us to post their feedback, plus (hopefully) most of the feedback
> is positive, so I could see people accusing us of not posting all the
> negative feedback we've received simply because there's more positive than
> negative.
>
> > I'm using improved (mostly accelerated) versions of BLANKS, IND2RGB,
> > ISCELLSTR, NOW, STRVCAT, TEMPDIR, @CELL/STRCAT, FGETL, GRADIENT, STRTOK
> > and WAVPLAY. Beside this I think PATHSEP, FILESEP, ISPC, ISUNIX can be
> > accelerated by adjust them to the operating system to save processing
> > time. Is somebody interested in such ideas?! I cannot publish the files in
> > the FEX, because this would interfer with the license conditions.
>
> If there are specific improvements you'd like to see us incorporate into the
> product, let Technical Support know. I can't guarantee we'll implement all
> of them (after all, the easiest way to accelerate these functions would be
> to rip out all that pesky time-consuming error checking code and let the
> functions give the wrong answer/error/crash if the user passed in the wrong
> data, right? Not going to happen. But if there's redundant checking or if
> you can think of a more efficient way to perform the error checking, we'd
> like to know.) but Technical Support can enter them into the enhancement
> database.
>
> > Finally I am still missing a platform, which help me to decide, which
> > version of Matlab I should buy, if I want to upgrade from 6.5.1 and my
> > absolute main interest is stability?
>
> I don't really have a good answer for you to this question. What are your
> requirements? Which OS are you going to be using? 32-bit or 64-bit? What
> types of applications are you going to be working on? [For instance, if
> you're working on a graphics-intensive application but you're not working
> with the FFT, then any bugs that would affect graphics or graphics
> performance would be show-stoppers, but a bug in the FFT routines might not
> be -- and vice versa if you're running without a display but
> batch-performing FFTs on thousands or tens of thousands of data sets.] Do
> you need to interface MATLAB with hardware or another application (which
> could impact your choice of OS, among other things.)
>
> In general, I would default to the most recent release that meets your
> requirements -- if you're not sure which that is, you can contact your sales
> representative (or our general sales staff) and describe what you're trying
> to do. You can also take a look at the online Bug Reports page:
>
> http://www.mathworks.com/support/bugreports/
>
> and see if there are any bugs that would critically impact your work. Sorry
> I can't provide a more specific answer, but that particular question's much
> trickier than it sounds at first glance.
>
> --
> Steve Lord
> slord@mathworks.com
>

Matlab r2009a Mac sucks, big time!

they just cant seem to get it right! it crashes so damn often! r2008b was much much better.

omg where do i even start with guide on mac? positioning stuff is a nightmare!

why two versions each year? ofcourse - money money money. seriously one good version each year is better than two crappy rushed versions.

64 bit, a REAL, EASY TO USE, repeat - EASY USE compiler for mac, proper parallel computing that can be compiled for supercomputers and university clusters - we want to get on with the real task rather than waste time with setting up the shitty parallel toolbox nonsense. please please please mathworks sort it out.

dont get me wrong i love matlab. been using it for 5 years. makes life for engineers easy but lately its been frustrating especially the mac version :(

"Scott Hirsch" <shirsch.nospam@mathworks.com> wrote in message <guckg2$gs5$1@fred.mathworks.com>...
> Steph -
>
> You might want to check out this submission on the File Exchange, which Mike put up to help people with precisely this issue:
>
> "Read VAXD and VAXG files in R2008b and later"
> http://www.mathworks.com/matlabcentral/fileexchange/22675
>
> - scott

Thanks for the pointer to the vaxd reader. If I only have a few files in vaxd format that would solve the problem. Unlike some folks 100% of my data from 1975 to now is in this format. Any solution to this is a major recoding issue. I will have to rewrite my binary file writer and reader so it does not use vaxd. I then need to create a function to read in the faxd format using the freadVAXD functions (These are easy compared to the next step) Then I need my programs to know when I am in the vaxd vs the new format. I could change the file extension but then I need to change ALL my other code to look for in the new extension. If I use the same extension then how does my programs know which is which. Most of my code is automated processing so there must be an automatible answer. Unfortunately, I think the answer is I will be staying in 2008a until I don't have a choice. That also
means I will be recommending that all my colleagues also stay in 2008a or later. Regardless of the Matlab procedures to determine what should be keep I think file IO functions should be left alone!! They are the most fundamental functions and should not be messed with! ARGH! If Matlab decides to reinstate vaxd let me know.

Stephanie -

I'm sorry about the challenges your are facing as a result of the removal of vaxd file format support. I'm a bit confused about your last post, though. Your comments make it seem like you would need to store data in a new format. I would expect that the only necessary changes would be to your file reading code - to literally update the FOPEN and replace the FREAD calls. I'm not saying that this would be a trivial amount of work, but it at least seems tractable. My apologies if I'm missing something.

 -scott


"Stephanie" <flora@mlml.calstate.edu> wrote in message <h0c1t5$ffp$1@fred.mathworks.com>...
> "Scott Hirsch" <shirsch.nospam@mathworks.com> wrote in message <guckg2$gs5$1@fred.mathworks.com>...
> > Steph -
> >
> > You might want to check out this submission on the File Exchange, which Mike put up to help people with precisely this issue:
> >
> > "Read VAXD and VAXG files in R2008b and later"
> > http://www.mathworks.com/matlabcentral/fileexchange/22675
> >
> > - scott
>
> Thanks for the pointer to the vaxd reader. If I only have a few files in vaxd format that would solve the problem. Unlike some folks 100% of my data from 1975 to now is in this format. Any solution to this is a major recoding issue. I will have to rewrite my binary file writer and reader so it does not use vaxd. I then need to create a function to read in the faxd format using the freadVAXD functions (These are easy compared to the next step) Then I need my programs to know when I am in the vaxd vs the new format. I could change the file extension but then I need to change ALL my other code to look for in the new extension. If I use the same extension then how does my programs know which is which. Most of my code is automated processing so there must be an automatible answer. Unfortunately, I think the answer is I will be staying in 2008a until I don't have a choice. That also
> means I will be recommending that all my colleagues also stay in 2008a or later. Regardless of the Matlab procedures to determine what should be keep I think file IO functions should be left alone!! They are the most fundamental functions and should not be messed with! ARGH! If Matlab decides to reinstate vaxd let me know.

Scott

Writing is not the best way for me to communicate so the fault is probably on my side. Ok, since the removal of vaxd format means I can not write a file in that format, then would I not have to write any new binary files in a different format?? Or can I still write files in vaxd even thought it has been removed??? I think I might have gotten lost too? What I need is a fix which can reading all the old vaxd and new "whatever" format with the same reader. And continue writing files which are readable by that same program. I am not sure if this is any clearer, let me know.

Stephanie

"Scott Hirsch" <shirsch.nospam@mathworks.com> wrote in message <h0imoi$5q4$1@fred.mathworks.com>...
> Stephanie -
>
> I'm sorry about the challenges your are facing as a result of the removal of vaxd file format support. I'm a bit confused about your last post, though. Your comments make it seem like you would need to store data in a new format. I would expect that the only necessary changes would be to your file reading code - to literally update the FOPEN and replace the FREAD calls. I'm not saying that this would be a trivial amount of work, but it at least seems tractable. My apologies if I'm missing something.
>
> -scott
>

I am not surprised at the emotions just at the venom. I have had numerous problems with Matlab removing or changing features I needed. Many required days of programing time (which I don't have). I have usually called technical support to ask for a modification but nothing every happens. So far date changes in the graphics programs have caused the most problems. Legend being the one still causing a problem and a function I am still not happy with. But so far the improvements in the newer version had been enough to want to go through these painful changes (until this vaxd change, with no warning I might add). All the code changes required when updating versions make me less likely to update in a timely matter ( I am currently about a year behind). I think this is were the problems come in for folks. I (and a lot of other folks), don't have time to test the beta version or the
upgrade to see if there are problems. Nor do I have time to be part of a user group. We get father and father behind making updates more and more painful and very frustrating. Anyway that is the point of view of a over worked and tired programmer. Steph

"Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message <gs5u4e$77o$1@fred.mathworks.com>...
> Dear Scott!
>
> I am surprised by the emotions in this discussion. The facts are simple:
> 1. Upgrade means: new features, new bugs, some fixed old bugs, some incompatibilities.
> 2. No upgrade means: no new features, no new bugs, no fixed bugs, no incompatibilities.
> This is the classical behaviour of complex systems and not restricted to powerful software. As consequence the decision depends on the demands of the user: If you need new features, buy a new release and be frightened of new bugs. If you need a reliable system with known limitations/bugs, stay at the running and tested release.
>
> Users can control (not avoid!) problems in current versions by participating in this newsgroup and reading the release notes on the Mathworks web pages. Unfortunately, these web pages are not complete, e.g. I was not able to find the information, in which release FOPEN stopped supporting files in VAX-D format, because the function reference can be explored for the current Matlab release only (am I right?). After I moaned in this newgroup, a friendly employee of Mathworks contacted me and offered to convert my files! Although this was impossible, because it concerned 50.000 files containing clinical measurements of patients, I was absolutely satisfied with the service. It took me 2 weeks to figuring out the problem and writing a conversion tool.

Dear Steven Lord!

> > I'm using improved (mostly accelerated) versions of BLANKS, IND2RGB,
> > ISCELLSTR, NOW, STRVCAT, TEMPDIR, @CELL/STRCAT, FGETL, GRADIENT, STRTOK
> > and WAVPLAY. Beside this I think PATHSEP, FILESEP, ISPC, ISUNIX can be
> > accelerated by adjust them to the operating system to save processing
> > time.

> [...] (after all, the easiest way to accelerate these functions would be
> to rip out all that pesky time-consuming error checking code and let the
> functions give the wrong answer/error/crash if the user passed in the wrong
> data, right? Not going to happen. [...]

I'm amused about the idea of omitting the error checks. This would exactly increase the danger of upgrading to newer version of Matlab!
By the way, BLANKS, NOW, TEMPDIR, FGETL, STRTOK, PATHSEP, FILESEP and ISPC do not have error checking at all...
To be correct: STRTOK checks, if it is called without arguments. I agree, that this test is not going to vanish.

I am aware, that BLANKS is most likely no bottle-neck. Therefore it is clear, why this tiny function has not been touched since 2002 (or 1984?). It's no big deal to replace the 2 lines with " b(1:n) = ' '; ". Anyhow, a speedup of 50% is worth to be implemented.

For the more serious improvements (like applying the fast CELLFUN(isempty/isclass/prodofsize) in @CELL\STRCAT) I will contact the support, as you suggested. Nevertheless, I do not dare to hope, that there will be hotfixes for Matlab 6.5.1.

And if the MathWorks team is on its way to brush up some old code from the last century, please enable the VAXD support again!

Kind regards, Jan

Stephanie -

On VAXD: I completely missed the fact that you were still creating new files in this format. I've sent Mike a note to see if he could create a submission similar to the VAXD reader which supports writing.

On Release Compatibility: I hear you loud and clear. We try hard to very carefully weigh the "cost" of dealing with incompatible changes against the net benefit provided to our end users. As I've mentioned in earlier posts, the VAXD decision is one that we have realized slipped through the cracks.

Thanks,
 -scott

"Steve Amphlett" <Firstname.Lastname@Where-I-Work.com> wrote in message <gs6hhp$8h2$1@fred.mathworks.com>...
> "Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message <gs5u4e$77o$1@fred.mathworks.com>...
> > Dear Scott!
> >
> > I am surprised by the emotions in this discussion. The facts are simple:
> > 1. Upgrade means: new features, new bugs, some fixed old bugs, some incompatibilities.
> > 2. No upgrade means: no new features, no new bugs, no fixed bugs, no incompatibilities.
> > This is the classical behaviour of complex systems and not restricted to powerful software. As consequence the decision depends on the demands of the user: If you need new features, buy a new release and be frightened of new bugs. If you need a reliable system with known limitations/bugs, stay at the running and tested release.
>
> I would be interested to know the criteria used by The MathWorks to select and prioritize new features. Similarly how to rank the severity of known bugs. Do large customers influence development policies? Or is everything decided from within?
>
> - Steve

Steve,

I've obviously not been keeping up with this thread.
But I'll admit that they really do use advisory teams
composed of other users around the world for these
issues. I am one of the individuals who has been
asked for input on occasion.

John

"John D'Errico" <woodchips@rochester.rr.com> wrote in message <h0lfkv$k2c$1@fred.mathworks.com>...
> "Steve Amphlett" <Firstname.Lastname@Where-I-Work.com> wrote in message <gs6hhp$8h2$1@fred.mathworks.com>...
> > "Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message <gs5u4e$77o$1@fred.mathworks.com>...
> > > Dear Scott!
> > >
> > > I am surprised by the emotions in this discussion. The facts are simple:
> > > 1. Upgrade means: new features, new bugs, some fixed old bugs, some incompatibilities.
> > > 2. No upgrade means: no new features, no new bugs, no fixed bugs, no incompatibilities.
> > > This is the classical behaviour of complex systems and not restricted to powerful software. As consequence the decision depends on the demands of the user: If you need new features, buy a new release and be frightened of new bugs. If you need a reliable system with known limitations/bugs, stay at the running and tested release.
> >
> > I would be interested to know the criteria used by The MathWorks to select and prioritize new features. Similarly how to rank the severity of known bugs. Do large customers influence development policies? Or is everything decided from within?
> >
> > - Steve
>
> Steve,
>
> I've obviously not been keeping up with this thread.
> But I'll admit that they really do use advisory teams
> composed of other users around the world for these
> issues. I am one of the individuals who has been
> asked for input on occasion.

yes, jd is correct, TMW has been asking for my input as well a few times over the decades...
also, there was a big survey a few years ago, which was open to anyone visiting TMW's w3-site...
in addition, it seems that the exchange on the TMW blogs seems to catch the attention of important seniors at times...
altogether, i think TMW is listening to their customers and (probably) try to come up with a 'best' solution to (statistically and resource-wise) 'appease' most of those zillions of hungry critters...

us
ps: just installed 9b

Scott

That would be awesome!!! Thanks.

In the compatibility issues I think file IO should be holy ground and not messed with. I can deal with major changes in the graphics area as painful as they are. But if I can not read or write my files that is not easily worked around. Work stops, and I get very ticked off. That is a major pain even regardless of the number of folks who use what ever file IO functionality is being adios ed. Why would Matlab assume no one is using the vaxd format if it is available in fopen??? Leave the file IO stuff alone. Is there any chance of getting it back??? Can you let them know to stop messing with file IO stuff??

Thanks for all your replies I appreciate your time!

Steph

"Scott Hirsch" <shirsch.nospam@mathworks.com> wrote in message <h0l9ad$3p6$1@fred.mathworks.com>...
> Stephanie -
>
> On VAXD: I completely missed the fact that you were still creating new files in this format. I've sent Mike a note to see if he could create a submission similar to the VAXD reader which supports writing.
>
> On Release Compatibility: I hear you loud and clear. We try hard to very carefully weigh the "cost" of dealing with incompatible changes against the net benefit provided to our end users. As I've mentioned in earlier posts, the VAXD decision is one that we have realized slipped through the cracks.
>
> Thanks,
> -scott

I just upgraded to Matlab 2009a and am facing the same dilemma as Stephanie. All my post-processing routines are set up to read and write vaxd format and now I can read the data am without option to write my processed data!

Could you please let us know if we would get a routine to write files in vaxd format as well?
Thanks

"Stephanie" <flora@mlml.calstate.edu> wrote in message <h0m3iu$klc$1@fred.mathworks.com>...
> Scott
>
> That would be awesome!!! Thanks.
>
> In the compatibility issues I think file IO should be holy ground and not messed with. I can deal with major changes in the graphics area as painful as they are. But if I can not read or write my files that is not easily worked around. Work stops, and I get very ticked off. That is a major pain even regardless of the number of folks who use what ever file IO functionality is being adios ed. Why would Matlab assume no one is using the vaxd format if it is available in fopen??? Leave the file IO stuff alone. Is there any chance of getting it back??? Can you let them know to stop messing with file IO stuff??
>
> Thanks for all your replies I appreciate your time!
>
> Steph
>
> "Scott Hirsch" <shirsch.nospam@mathworks.com> wrote in message <h0l9ad$3p6$1@fred.mathworks.com>...
> > Stephanie -
> >
> > On VAXD: I completely missed the fact that you were still creating new files in this format. I've sent Mike a note to see if he could create a submission similar to the VAXD reader which supports writing.
> >
> > On Release Compatibility: I hear you loud and clear. We try hard to very carefully weigh the "cost" of dealing with incompatible changes against the net benefit provided to our end users. As I've mentioned in earlier posts, the VAXD decision is one that we have realized slipped through the cracks.
> >
> > Thanks,
> > -scott

I just upgraded to Matlab 2009a and am facing the same dilemma as Stephanie. All my post-processing routines are set up to read and write vaxd format and now I can read the data am without option to write my processed data!

Could you please let us know if we would get a routine to write files in vaxd format as well?
Thanks

"Stephanie" <flora@mlml.calstate.edu> wrote in message <h0m3iu$klc$1@fred.mathworks.com>...
> Scott
>
> That would be awesome!!! Thanks.
>
> In the compatibility issues I think file IO should be holy ground and not messed with. I can deal with major changes in the graphics area as painful as they are. But if I can not read or write my files that is not easily worked around. Work stops, and I get very ticked off. That is a major pain even regardless of the number of folks who use what ever file IO functionality is being adios ed. Why would Matlab assume no one is using the vaxd format if it is available in fopen??? Leave the file IO stuff alone. Is there any chance of getting it back??? Can you let them know to stop messing with file IO stuff??
>
> Thanks for all your replies I appreciate your time!
>
> Steph
>
> "Scott Hirsch" <shirsch.nospam@mathworks.com> wrote in message <h0l9ad$3p6$1@fred.mathworks.com>...
> > Stephanie -
> >
> > On VAXD: I completely missed the fact that you were still creating new files in this format. I've sent Mike a note to see if he could create a submission similar to the VAXD reader which supports writing.
> >
> > On Release Compatibility: I hear you loud and clear. We try hard to very carefully weigh the "cost" of dealing with incompatible changes against the net benefit provided to our end users. As I've mentioned in earlier posts, the VAXD decision is one that we have realized slipped through the cracks.
> >
> > Thanks,
> > -scott

Muna -

Thanks for speaking up - it's helpful for us to know how many people are affected. We are wrapping up work on a File Exchange submission which will provide the ability to write in vaxd format. I'm hopeful that it should be up in the next couple of weeks.

 -scott

Dear Scott Hirsch!

> Thanks for speaking up - it's helpful for us to know how many people are affected. We are wrapping up work on a File Exchange submission which will provide the ability to write in vaxd format. I'm hopeful that it should be up in the next couple of weeks.

I've written a conversion tool for C3D files in VaxD and published it in the FEX. To my surprise it is downloaded by about 70 people per month - I thought the problem concerned a dozen of labs only.

I'm not really happy with the VaxD reading routine:
http://www.mathworks.com/matlabcentral/fileexchange/22675
Beside the fact, that results are absolutely correct (thanks!), commands like "bitshift(X, 0)" make me insecure. For reading large files, this function is not really efficient.

Is it inside the area of technical possibilities to enable the Matlab 2008a method of FOPEN with VaxD support in 2008b to 2009b again?
It would be completely easy for us users.

Thanks, Jan

 

Jan -

Thanks for posting the submission to the File Exchange. It is interesting to see how popular it has been.

I don't fully understand your concerns regarding the VAXD file exchange submission. Is it unacceptably slow for large files compared to the old, native behavior? I also don't understand why you are concerned about the use of bitshift, if the results are accurate.

Our current best thinking is that the file exchange submissions represent the best balance between helping to address the needs of customers who were impacted by the removal of native vaxd support and allowing our developers to continue to focus on projects which will have much greater impact on our user base.

Thanks,
 -scott

Dear Scott Hirsch!

> I don't fully understand your concerns regarding the VAXD file exchange submission. Is it unacceptably slow for large files compared to the old, native behavior? I also don't understand why you are concerned about the use of bitshift, if the results are accurate.

The native VAXD processing was much faster and less susceptible to errors.
In "BITSHIFT(X, 0)" not "BITSHIFT" is my problem, but "0" (it is a zero, not an uppercase 'o'). Of course, a multiplication with 1 does not change the result, but it looks strange. Perhaps it's just a question of taste.

> Our current best thinking is that the file exchange submissions represent the best balance between helping to address the needs of customers who were impacted by the removal of native vaxd support and allowing our developers to continue to focus on projects which will have much greater impact on our user base.

Thank you for the clear message! Now I can stop waiting for VAXD to return and proceed to find another solution. I took the chance to mention my opinion about the impact of VAXD.

I'll stop posting in this thread. I have a bad conscience to feed a thread with this title! I'll have to learn how to pick up your posting and start a new thread. Perhaps I could change the subject?!

Kind regards, Jan

Scott Hirsch wrote:
...
> Thanks for posting the submission to the File Exchange. It is
> interesting to see how popular it has been.

Just maybe there's a message there?????

...
> Our current best thinking is that the file exchange submissions
> represent the best balance between helping to address the needs of
> customers who were impacted by the removal of native vaxd support and
> allowing our developers to continue to focus on projects which will
> have much greater impact on our user base.
...

How can it possibly take much away to simply continue to compile
previously debugged code instead of taking the effort to actually remove
functionality (and test that that hasn't somehow affected something else)?

I don't have a dog in this fight but seems like a very small amount of
code reduction for essentially no real purpose to an observer...

--

Hi,

Code to write VAXD and VAXG files in R2008b and later is now available on MATLAB Central:

http://www.mathworks.com/matlabcentral/fileexchange/24793

Feedback concerning this code is probably best placed/tracked in the Comments sections of the MATLAB Central submission (and not this thread).

Best Regards,
KEN ATWELL