MATLAB Survey for Mac OS X

gsfprez writes "It's fairly simple: MATLAB wants to know if a Mac OS X port would be worth their while or not. I tell you what, I know a few engineering R&D organizations who'd have to reverse their anti-Mac IT decisions solely based on the idea that MATLAB would be available for Mac OS X because there could finally be high power, yet affordable, Unix machines running it."

Comments

Re:Wonderful

[EddydaSquige]

I tried to vote early and often, but the survey looks like it will be conducted by phone and not the web. The survey link simply gives you a form to fill out you name, title, address, ect... And that's it, no other questions. So expect a call from marketing in the morning.

Octave

[DustMagnet]

There's always the open source alternative called Octave. It doesn't even require a license server, something I hate about matlab.

Re:Octave

[EccentricAnomaly]

Unfortunately Octave's plotting is horrible... and the main reason that I use Matlab is for its plotting.

What we need is some good open source plotting libraries ....hmmm :)

Re:Could someone confirm this survey's legitimacy?

[mkoz]

It is also posted on MacNN:

http://osx.macnn.com/news.php?id=13863

Re:Wonderful

[softsign]

You can get Matlab for Linux - I run copies on RedHat - so the implication of the post that Matlab for Mac OS X would finally bring Matlab to Unix is a little strong.

You can get Matlab for just about any Unix (and it will run fine on a $1000 Sun Netra). So the implication by Mathworks that it would be difficult is bogus. Releasing a port that uses X would probably take them about one month. Using Aqua would probably take some more time. But with the rate of OS X adoption among engineers, they would be stupid not to pursue this.

Re:Math S/W

[b_pretender]

Comparing MATLAB to Mathematica is like comparing apples to oranges.

Mathematica offers a great symbolic algebra tool, a functional scripting language, a good plotting data visualization tools.

MATLAB offers a great procedural scripting language, awesome array/matrix handling, and good plotting data visualization tools. Although, overall, MATLAB scripts run very slowly, when it comes to array/image manipulations, our best coders couldn't write C code that would perform as quickly as a well-written MATLAB script.

I have extensive educational experience with Mathematica and extensive proffesional experience with MATLAB. One is good for some things the other is good for other things. For basic math projects or assignments, probably either tool is equally good, and tools such as Octave or SigmaPad are effective and free alternatives for MATLAB or Mathematica, respectively.

MATLAB and Mathematica shine, however, when it comes to toolboxes. At Lockheed Martin, I used the Neural Network and Image Processing toolboxes extensively, and I was very happy with them. Also, MATLAB lends itself nicely to reprogramming your code in C, or using MEX wrappers to program in C or insert C code into MATLAB.

Although I don't have much experience with Mathematica add-ins (except for the Statistics Toolbox), I imagine that they are also well written and efficient. I would guess that Mathematica would have better *analytical* toolboxes, whereas MATLAB would have better *numerical* toolboxes.

Re:Math S/W

[Circuit Breaker]

You've obviously never had to use Simulink or Real-Time Workshop. Mathematica has nothing like this and it is the lifeblood of engineers.

Actually, I've had the misfortune to use Simulink. I had to simulate a non-linear multiple input/multiple output system, and I couldn't get Simulink to do it; So I turned to all the local experts who told me to use it in the first place, and once I described the problem to them, they said "Oh, of course you can't do that in Simulink". Granted, it was a very complex system, but that's why I needed modelling in the first place - I couldn't get an approximation any other way.

I would like to see you write a script that will do 2D signal processing and plotting of the results in about 20 lines. I can do this in Matlab. Not only can I do it in about 20 lines of code, it will be blazingly fast if properly written to take advantage of Matlab's matrix capabilities

With the exception of "import Numeric" and "import ", which I can hide away in a "Matpython" startup script, your 20 lines will probably work in Numeric Python with minor syntax tweaking and (unless you have no loops or unneeded copying, which is hard to get in Matlab) noticably faster. Numeric even uses the many of the names used in Matlab (which in turn copies some old fortran libraries) for most functions. But Python is significantly more capable - Let's see you do proper 4D signal processing with those 20 lines - I was able to do that in Python and I wasn't able in Matlab (that was why I switched at the time). It was Matlab 4, I think, and anything beyond 2D was hardly supported - perhaps things have changed.

But one thing I know HASN'T change is Matlab's horribly inefficient scripting. I'm probably not representative, but I never seem to do anything "standard" with any tool - I usually find "standard" solution I'm content with without redesigning them (DCT, for example). I always do nonstandard things, usually nonlinear, and Matlab hasn't once given me a good surprise (and I gave it more than enough chance).

A lot of people make the mistake of writing Matlab code like they would C - lots of embedded loops, iterating over one variable. That's not how Matlab works and it usually results in awfully slow execution. Use matrices like they're supposed to be used and Matlab works like a champ

I'm not one of them. I've worked in languages (APL, Fortran) and environments (some IBM vector pipelines from 10 years ago whose name I can't recall, among others) that capitalized on vectorized access; I write vectorized matlab code. Unfortunately, sometimes it's the wrong thing to do.

In one case, while trying to compute a three dimensional electrostatic field around a weird asymetric structure, I needed a matrix that contained, for each point in space, a distance from one of a set of given points. Doing this vectorized required multiple large intermediate matrices (think tens of megabytes), none of them sparse. When I debugged the matlab code on small matrices, it worked fine; When I went to the full size, it got a slowdown factor of 500 or so due to swapping. I rewrote this as a Matlab loop instead without any additional computation, and it was 5 times faster (100 times slower than anticipated if vectorizing didn't spill to disk). Writing the same loop in Numeric yielded nearly 20 times improvement. Not quite the vectorized result, but just 5 times slower than that (The code did many superfluous computations, which were unavoidable in vector form). I also converted the original vectorized version to Numeric, and it ran at exactly the same speed as Matlab.

It was around that time that I stopped taking Matlab seriosly - Python/Numeric consistently outperformed it in any test, was easier to interface to C, and didn't have licensing hassle attached. It isn't as prettily packed, and you have to collect "packages"/"toolkits" yourself instead of relying on Mathworks to do that for you, but it has been more than worth my time to do so.

Exactly. Matlab is great for what it does. I can spend a few days designing and testing an efficient DCT algorithm, or, I can use Matlab. I can spend a few days designing and testing an efficient DWT algorithm, or, I can use Matlab. You see where I'm going with this...

Actually, I don't. Are you designing a new DCT algorithm, different from the Lanczos/Daniels, Sorensen or Winograd algorithms? Because doing so would take you days (if not months) in any environment. Are you designing a new DCT implementation? If Matlab saves you time, you should probably be spending time on something else - Matlab doesn't help you evaluate precision loss, limit cycles, saturation problems, etc. Is that DCT needed as a component inside something else? Then you aren't designing a DCT algorithm at all - the same way you call "dct2()" in Matlab, you could do that in C, Python, Fortran or Lisp.

Regarding your DWT algorithm - you didn't really try to compute any interesting wavelets or any continuous ones lately, have you? Another area I have experience with and which I found Matlab severely lacking (And yes, I _was_ designing new wavelets, not just reiterating the standard families).

Not only that, but when I'm done with my simulation, Matlab has some pretty decent graphing capability. I don't need to waste my time handling spreadsheets full of data and trying to get a meaningful plot.

It has decent graphing capability, but nothing out of the ordinary. I used DISLIN, gnuplot, and various other packages through time; They're just as easy to use, some give matlab-quality output, and there are a few that give quality output, that I wouldn't be ashamed to publish in a referreed magazine (which I can't say about matlab output).

The reply suggests, more than anything, that you've only used Fortran, C and Matlab - out of which Matlab is definitely the environment of choice for most design work. But there are a lot of other tools out there, and I have found them definitely worth my time. Check them out when you have the time.

Personally, having a strong Prolog origin, I like Mathematica's syntax as well, and usually requiring weird things Matlab can't do efficiently, don't find it significantly slower than Matlab even for numeric work. But that's probably just me.