Path: news.mathworks.com!not-for-mail
From: <HIDDEN>
Newsgroups: comp.soft-sys.matlab
Subject: Re: Do not upgrade to Matlab2009a
Date: Thu, 16 Apr 2009 06:11:03 +0000 (UTC)
Organization: UNIVERSITE AIX MARSEILLE 2
Lines: 30
Message-ID: <gs6i5n$ja1$1@fred.mathworks.com>
References: <gs027a$8d1$1@fred.mathworks.com> <a8593395-478c-4c7c-8011-d8a999911cdc@y10g2000prc.googlegroups.com> <gs4gst$pn3$1@fred.mathworks.com> <gs5u4e$77o$1@fred.mathworks.com>
Reply-To: <HIDDEN>
NNTP-Posting-Host: webapp-03-blr.mathworks.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Trace: fred.mathworks.com 1239862263 19777 172.30.248.38 (16 Apr 2009 06:11:04 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Thu, 16 Apr 2009 06:11:03 +0000 (UTC)
X-Newsreader: MATLAB Central Newsreader 870049
Xref: news.mathworks.com comp.soft-sys.matlab:533101


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