Học Matlab

[Maryetta Worm]

I have been a longtime MathCad user (though not necessarily a particularly adept one). Recently I decided to learn Matlab and started doing this by rewriting some Matlab programs in MathCad (although the reverse might seem more sensible). Although MathCad has obvious advantages for combining text and calculations in a more or less free form way, my impression is that MatLab offers many programming advantages. For example, fzero seems to work more robustly than root, MathCad seems to have no function equivalent to fminsearch or fminbnd, it treats NaN differently (MathCad returns 0).

I've used all of the "M" systems (MathCad, MatLab, Mathematica, and Maple). It really depends on what you need to do in deciding which system is "best". Here are some considerations that I've used ...

I started with MathCad first. I needed something that would let me express mathematics to do some simple analysis, make a few plots (for my own edification and for teaching purposes), and, most important, would let me create documents that combined text, math (meaning equations, usually), and graphics that could be used for teaching or other didactic purposes.

At a certain point, I needed to analyze a lot of data, often multi-channel analog samples from a variety of sources. In some cases, complicated calculations involving these data needed to be performed. For example, I might want to know the 3-D orientation of an object (roll, pitch, yaw), given voltages measured by coils fixed to the object inside a stationary magnetic field. I used MathCad to develop and test the equations to take the signals (voltages) and convert them (through multiple steps, including getting "scaling" information from other files) into a series of three components representing roll, pitch, and yaw (these eventually were converted to rotation vectors). For doing the "number-crunching", involving multiple files and megabytes of data, I used MatLab, as I found it easier to handle the "point the program at the following directory and let 'er rip" with MatLab than with MathCad.

A number of years ago, I started working on an even more complicated problem involving vector-like objects in a six-dimensional space. I needed to be able to "point it at data", like MatLab, but needed more sophisticated math ability, like MathCad. However, the MathCad at the time (12? 13? I'm not sure) didn't seem up to the task. So I bit the bullet and tried Mathematica. This definitely has all of the "power" that I could imagine, particularly in the "solving" arena (which is where MathCad had let me down). However, its ideosyncratic syntax (basically, you need to learn an entirely different set of "rules" for things like parentheses, square and curly brackets, upper and lower case) gave it an extremely steep (and rocky!) learning curve, not something I would want to turn to for a simpler problem. While it does support the creation of documents that combine text and math, the math is in Mathematica syntax rather than looking more like equations we can intuitively grasp, as MathCad provides.

At this point, needing the math capability of Mathematica but wanting the syntax and ease-of-use of MathCad, I decided to try Maple, which I understood to be a MathCad "parent". I must confess I probably did not give it a fair trial, as I was put off by the difficulty of entering "math" into the system (compared to MathCad), and the relative lack of transparency and intuitiveness of the system.

I've just downloaded and installed MathCad Prime 2.0 (I "passed" on Prime 1.0 because it lacked 3-D plots and symbolics (both of which I use). I'm hoping and planning to "get re-acquainted" with MathCad for my algorithm development, modelling, and data analysis (not of the "number-crunching" variety, but I might decide to "give it a try" ...).

I like Mathcad! It's easy to learn to use (once you've climbed the "learn the editor" hill. You don't have to learn a programming language. (I'll concede that Matlab is much easieer than FORTRAN, but it's still a programming language.) Mathcad handles units. And I can do in Mathcad practically whatever others can do in Matlab.

In my experience, Matlab handles file I/O better than Mathcad. (Some people have been writing DLL's and scripts to address that, you can find a wide assortment here.) And I suspect that Matlab may have an advantage with HUGE quantities of data. (Mr. Jackson may have an input.) Matlab can create a page of graphs as a stand alone image; I really wish Mathcad could do that. But I can read a Mathcad sheet and understand it--it looks like hand written math. Pray tell, what is fzero? fminsearch? (Admitted: soome of the Mathcad functions can get isoteric too.)

I had seen some programming steps written for a protection relay response, the Mathcad file plus it had a data file associated to it. I was surprised to see the level of programming similar to Fortran for instance. I realised then that it had its ability to be a cad like and programming software. That was in a formal course at Uni of Idaho. Now I am getting into signals and systems thru a tutorial book for Mathcad, plus an engineering textbook.

So it takes me a while to get the entries and syntax right, slowly I am making progress. I say to myself there cant be anything more Mathlab can do for what I am doing now, and if it could it would be more of a GUI input.

So thus far I am pleased with Mathcad but I need to study its programming side. I got me a textbook with some Mathlab files in it too, but I have to do the signals and systems in Prime first. Then hopefully I will be able to do the coding for filters and other topics for the relay algorithm in the textbook in Prime.

I had the same question John Rudniki had, and also asked it on a portal called Stack Exchange Signal Processing, the moderator there felt it was a personal preference and the replies would be opinions and requested I rewrite the question I wanted to post in the group.

I say Mathcad has many features and areas that are applicable to electrical engineering, more so than other fields. From probability to signal processing, transforms, and lots more. I am comfortable with Mathcad Prime but would not mind learning Mathlab for some speciality area where industry might have preference.

Programming in Mathlab is closer to programming in a language like Fortran Python etc while in Mathcad for me so far its not programming but how to effectively use the few commands in the student version.

I am a PhD student at the University of Kansas. Today was the first day of class. My Probability professor recommended that we purchase Mathematica. Before I go down that road, I thought I'd ask your opinion on which one of the discussed M software packages would be best suited for a PhD student majoring in civil engineering with an emphasis in transportation?

In my opinion, Mathematica is best for mathematicians. If you are going to be doing a lot of "number-crunching", particularly if your numbers are ASCII strings in a file, and you are doing fairly simple things with them and want something quick, MatLab isn't a bad bet. It is basically an "interpreter" (like BASIC), and is definitely a "text-based" language (so you'll have some syntax to learn).

However, if you are going into engineering (as you are), and are likely to be doing a mix of data analysis (which includes number-crunching) and possibly some theoretical/experimental work (I notice you're taking a Probability class, so you might do some Monte-Carlo type simulations, such as estimating pi by figuring out the probability that a needle lands on a line when dropped onto a set of evenly-spaced parallel lines spaced the length of the needle), you'll probably find that MathCad is more intuitive, easier to learn, and has tools (such as the ability to create "text" documentation, to have the "program" and graphs be readable by people who don't know MathCad, and to include units to prevent mixing inches and meters inappropriately) that get the software "out of the way" of solving the (engineering) questions you really want to ask.

I have been using Mathcad for decades (since the mid 1980s? V1). I am an early adopter of tools that show promise, and Mathcad was one of those. For some time, it was the only tool that did what I needed, though other tools had/have their own strengths. I now use Mathcad 14/15 (1st choice), MATLAB (2nd choice), Maple (3rd), and just began looking into Mathematica. I use Mathcad 15 rather than Prime 2.0 because of shortcomings in Prime, but Prime is now getting up to steam, so I try to develop in parallel until Prime fails me, then I switch back to M15. The problem with that approach is that there is no converter for Prime > M15, but there is M15 > Prime, so I will not commit any serious work at this point to a draft in Prime, expecting that I will want to redo it in M15. Prime 2.0 is not the tool for you as a PhD candidate.

I find Maple very powerful as a math analysis tool...much more so than Mathcad. Great solvers and plotting features. But the user interface is arcane, units are handled in a manner that seems unique to Maple, and is not a clean process (through Maple 16, at any rate), and documents are not easy to format unless one accepts the Maple presentation style. All these items have been on the table for years with the folks at Maple, so I don't expect changes soon.

MATLAB is very powerful, and includes data handling features that I need in my work (space plasma physics) that are not available in Mathcad. In addition, programming is more intuitive in MATLAB for me (extensive background w 3G, 4G programming languages) than Mathcad. It is fast, well supported by MathWorks, has a great user community, has a student license, and is far, far, far, far, easier to manage, license-wise, than any PTC product. The same goes for Maple. I currently run several versions of Maple and MATLAB side-by-side on the same platform, with no problems.

Mathcad 15 is the fastest to prototype models in, and the units checking is one of the most valuable features. I recently "checked" a published equation that I wanted to use, only to find that it contained en error, an error that would have been much more difficult to find without unit checking. (Complicated expression involving current-voltage characteristics of swept Langmuir probes in tenuous plasma.)