Experts of MATLAB, how did you learn? Any advice for beginner/intermediate users?
The community is very helpful, yet I feel really powerless that I cannot find the appropriate way to code, nor find the problems with the codes I have written. I have read numerous books on MATLAB, mostly related with science and engineering applications. Any advice to improve would be greatly appreciated. Thanks.
66 Comments
Time Descending
MATLAB has extensive documentation and examples. Go through these examples, understand how they work, and try to modify them to do something slightly different. This will help you understand the nuances of the language and its application.
Do you know about the Onramps? I highly encourage you check these out :)
These are typically a short, 2-3 hour commitment, and they are free!
The MATLAB Onramp is the best way to start if you've very new to MATLAB.
There are also the more comprehensive "Fundamentals" courses:
I recommend MATLAB Fundamentals to built a good foundation before moving on to any other courses.
Practice makes perfect
University of Vanderbilt offers an externsive course on MATLAB on the COURSERA platform
To write an mfile for the MATLAB File Exchange, there are other places to look for ideas, besides MATLAB's File Exchange: textbooks, languages, internet, ...
Hi,
I have a collection of samples programs posted on my MathWorks page on here. I also have a collection of YouTube videos that I've put together to help people through basics and some complicated things in MATLAB. These videos correspond to step by step directions on how to make the programs I've posted on MathWorks. How to Create Programs in MATLAB (tutorial): YouTube MATLAB tutorial
I also reply to any comments on YouTube to answer MATLAB questions. I'm always happy to help out.
Best of luck on your learning journey. -Kelsey
I always look in documentation first, unless I already know it. The stuff at the top and the bottom of the pages, of the "commands" and/or "functions" that you enter into the documentation search bar, are usually the most useful. MATLAB "Answers" is what I use next if I can't find what I need in documentation, and you can access MATLAB "Answers" two ways, directly from the File Exchange page and the MATLAB Central (drop down menu), or I use Google Chrome to search for MATLAB "Answers" by entering into the Google Chrome search bar: "matlab" and "search term question", but leave out the previous and, and the quotation marks. Thank you, thank you very much.
Practice Makes Perfection
Practice makes you perfect
Thinking about problems and continuous solving can help you
Even the best coding language needs smart users and can not by itself solve your problems. Some poor hints might be:
- use modulatization, such as functions for repeating tasks in code
- debug small parts of your code before getting huge
- use in appropriate steps output including text and figure and maybe files
- let your code be reviewed by colleagues
- and my favourite one: distrust yourself, you might have been wrong in coding, double check.
+1 good points
First, it could be overwhelm to start using Matlab because if you are not familiar, the concept is completely different from the most common tool that engineers use nowdays: "Excel". So, I recommend to get familir with the platform, take the free Matlab Onramp tutorial offered by MathWorks.
After that, try to force yourself to use Matlab for everything: from simple calculations, to plots curves, to analyze data... and avoid to use Excel at all. Find examples of similar problems in the forums or in Google. I always find a similar program or function that has been coded previously, and I learn a lot from that. And google any function that you need to incorporate. Most likely Matlab already has a function for your problem, and the Matlab help files are very nice and complete.
It takes some time, but at the end, it is much more worth it for your work than use Excel!
Hope this helps!
I am beginner here but trying to lean it and its really fun when we understand the concept.
Good question.
For The "Find the Treasures in MATLAB Central",post this words.
Hello, I am not a Matlab expert by no means. I have been using Matlab for about two years.
Something that has really helped me is to look for other things that I can use Matlab for, that can make my workflow more efficient.
For example, when I am working on a .tex document (which is very used in engineering at my university), instead of making the table yourself, which could take a lot of time, look for a function that can make it for you.
Also, try to use them for personal proyects (to manage different format files), or proyects that are not necesarily engineering ones.
Reading some books and looking at courses if you are starting out is also something useful.
Also, try to ask and answer questions on the Matlab Answers forum, you could really learn from studying diferent solutions to other people's questions, and then trying to solve such question in your own way. There may be some difficult ones but there are also some challenging enough ones.
Also, if you understand the errors that appear on your command window, I think coding will be so much easier.
Really great points on practical and theoretical aspects how to study and master programming in MATLAB environment. My learnig experience of MATLAB and Simulink was a little bit different from the points highlighted above. During my college years, I have employed MS Excel and Visual Basic programming in MS Excel in most of engineering and numerical analysis classes. Then I challenged myself to do everything what I had done in MS Excell and Visual Basic programming in MATLAB.
Later, I challenged my research fellow colleagues to perform all simulation and modelling problems of ours in MATLAB and Simulink environments and find out differences in solutions if there are any. These challenges were really fun and sometimes frustration due to simple ("now we call") or silly mistakes such as overlooking a solver type (i.e. fixed-step solver vs. variable-step solver) or error tolerance ('RelTol', "AbsTol") or executing Simulink models with undefined variables in the MATLAB workspace. One nugget here for Simulink modelling people how to carry all variables and their values along with the models is to define all variables and their values in: Model Explorer -> Callbacks -> InitFcn
As pinpointed above by others, "practice makes perfect!".
One great lifetime lesson that my Math Teacher in school taught was to solve any given problem with at least two or more different ways. That practice I have applied in solving various problems in MATLAB and Simulink in parallel that also helped me to study many different features of programming in MATLAB and Simulink.
Another practice of mine that I have found very essential in learning MATLAB/Simulink is designing and solving specific engineering projects in vibrations, control problems of dynamics, image analysis, etc.
Last but not least by helping others to solve their problems and teach others one can gain significant amount of valuable experiences including new features of MATLAB/Simulink packages and their toolboxes.
I've used MatLab for a couple days. I bought a big book on how to code a particle accelerator. I figure by the time I finish I should have the hang of it. So far, not all the code is running smoothly. I am not mad. Thats how I learn.
Everyone else here has covered what are arguably the more useful answers. I'm no expert, but I think one point that hasn't been mentioned (similar to Stephen's last point) was to spend some time to casually become familiar with your tools without the burden of performing a task for others.
I was taught to type on a typewriter and came away from all that practice without any practical typing ability. It wasn't until I was motivated to communicate with others in real time online that I learned to type for my own selfish motivations. Likewise, all the coursework and research I pushed through Matlab hardly taught me much in terms of breadth or depth of familiarity. It wasn't until I started writing my own projects that the challenges felt meaningfully rewarding and I began to find some shreds of confidence.
... maybe I just outed myself as a terrible learner. I guess I'm old enough to live with that.
Self-paced courses are enough.
@Walter Roberson, you are right. The self-paced course aren't enough until one start 'getting his/her hands dirty' with practical implementation before you can know 'how much you know!'. I have particulary found this community helpful.
Enough for what purpose?
If you visit the main MATLAB Answers page, http://www.mathworks.com/matlabcentral/answers and you look at the list of the 20 most recent questions: of those 20, how many would a person be able to answer after taking just self-paced courses?
It takes a little time to get proficient in MATLAB, especially if you are coming from more traditional programming languages. I agree with everything said in the previous answers, but I'd like to emphasize a few of the things that really helped me personally.
- Understand how MATLAB uses vectors and matrices, and the various ways you can access them using subscripts and slices. Learn how to use a logical mask to filter elements of a vector or matrix.
- Learn to vectorize operations. When you find yourself writing a FOR loop, try to eliminate it using a vector operation. Usually you can do it, making your code faster and easier to understand.
- MATLAB's help system is one of the best. Use 'help <command>' to be reminded of command syntax, and 'doc <command>' to read about usage details and optional parameters.
- Don't reinvent the wheel. MATLAB includes lots of built-in functions that can deal with many types of problems, not to mention all of the specialized toolboxes.
- Don't try to write perfect code the first time. Get something working, verify your results, and then optimize it for size or speed if needed.
- Use comments liberally to document your code. Even if something seems obvious today, after some time has passed you may find yourself wondering, "What the heck was I trying to do here?" Writing good comments saves time in the long run.
- Break problems up into smaller pieces, and write functions instead of large scripts. This helps improve code architecture and makes it easier to reuse, debug, and share code.
- Looking at other people's code helps with learning and understanding MATLAB's unique programming idioms and best practices. Check the file share section for solutions to specific problems.
- Finally, the MathWorks question and answer forums have lots of helpful information. But you already knew that.
Good luck!
Vectorization is not always best. In some cases it can force you into multi-dimensional logical arrays, calculate the values over the whole range of possibilities as-if all the entries were going to be selected, and then selecting the answers using logical mask. As the dimensionality goes up, the fractional of entries that are eventually going to be selected can go down quickly, and it can become much faster to instead loop and select only limited subsets to calculate over.
Is this 5 years old? I hope you fingured it out by now.
The coffee is not strictly mandatory: I never drink the stuff myself.
I could claim that milk does just as well.. but more accurate would be that programming is greatly assisted by having a supply of comfort foods such as potato chips and chocolate.
Two questions that can be useful to ask when writing a significant piece of code are "What problem am I trying to solve?" and "What steps do I need to do to solve my problem?"
Sometimes when I'm writing code I'll start off with either just a bunch of comments listing the steps or a series of function calls (no bodies yet, just the names.) This is just to fix the series of steps in my mind and ensure that I'm not missing anything. Once I have the general workflow in place, I determine what each of those steps needs to receive as input and what it needs to produce for other parts of the workflow. This finishes the signature of each of my functions. Then I can implement each step as its own function, independent of the rest of the workflow. This limits how often I have to go back to an already-implemented function and change it to satisfy the requirements of later functions.
You may be tempted to save time by using short, potentially cryptic function or variable names. I recommend resisting that temptation unless maybe the variable is only in use for a very short period of time. So using single letter variable names like t and y as the input arguments of an anonymous function may be okay.
odefun = @(t, y) t.*y;
For anything that's going to be used repeatedly, I try to choose function and variable names that make my code look more or less like English sentences or phrases that describe the purpose of the function, the variable, and/or the function call. Tab completion can help limit how much typing you need to do. Consider one example:
data = readDataFromFile(filename);
Without knowing anything about the body of that function, you can get a pretty good sense of what it does and roughly what it returns.
data = readDataFromFile(filename);
cleanedData = removeOutliersAndMissing(data);
Those seem like two reasonable steps in the process of analyzing data from a file.
The debugging tools, Code Analyzer, and other tools to help you fix and avoid problems in your code have already been mentioned and they're good tools to have in your toolbox. There are a few others that may have been mentioned in passing that would be useful particularly for larger projects.
- the Profiler can help you understand where the performance bottlenecks in your code are located, focusing your attention on the long poles.
- Given the department I work in at MathWorks, I don't think it'll surprise anyone that I give a plug for the testing tools. Even a few script-based tests to lock down the behavior of the most critical part of your code will help you when or if you need to change that code, to reduce the chances that you'll break it. Note that we have frameworks both for correctness of your code and to measure performance, to reduce the chances that you'll slow your code down and not notice.
odefun = @(t, y) t.*y;
The variable names may be short and cryptic there, but in the context of ode numeric solvers they are also conventional, and that can help a fair bit in having them recognized. Just like how all of the Mathworks optimizers use names such as A, b, Aeq, beq, lb, ub: the coding pattern can become strong enough with common repetition that using different names can start to be distracting.
(If you dig into the implementation of ode45 then you will find a lot of places where you are asking yourself what the difference is between input parameter names and names carried around through the code, because there is a programming maxim that if you use a different name then it should be for a different purpose.)
I hadn't noticed this question at the time (or I think maybe I did, but Stephen's answer was so comprehensive as regards advice that I didn't feel the need to add anything).
To give an answer on a more personal note though, I have first started working in Matlab ~9 years ago. At the time I was a novice C++ programmer, fairly fresh out of a Computer Science PhD, had been offered a job as a software engineer, but mostly with the intention of me becoming the 'research engineer' that I am now - i.e. I do some research, come up with lots if ideas, implement them as prototypes and hopefully they are good enough for our company to put into our main software. I'm neither an expert software engineer nor an expert researcher, I'm just quite good at combining the two in a useful manner.
Matlab was the tool that I was given to do most of this research in, though for many years I did so alongside also programming in C++ for long periods. When I started I had never even heard of Matlab. To this day I have never been on a single Matlab course or done any kind of official training, I have just learned on the job and continue to do so.
Right now I would say I am more of a 2nd tier expert if we accept that people like Stephen, Walter, Chad, John D'Errico are top tier experts. I have a good depth of knowledge in the areas I have used and am able to provide help and advice on those, but I still learn a huge amount from people like those named and others at the same time through browsing this forum.
As I began to produce prototype demos I made it a mission to try to learn at least one new thing in Matlab with every new prototype I created and always enjoy the software engineering design aspect in a language like Matlab. After many years of working in GUIs we began to start building ever more complex tools with multiple communicating windows, etc. At this point I decided it was time to learn Matlab OOP which was pleasingly easy. I completed a 2 week project using OOP for the first time in less time than my boss had expected it to take without knowing I was learning a whole new way of programming. It was one of the best Matlab decisions I have made. Now > 95% of the code I write is object-orientated and I believe our code base is vastly better for having taken that leap.
As for other stuff though, in addition to learning as I go through experimentation and the excellent documentation I started visiting this forum. From the outset I decided I wanted to give at least as much as I 'take' so I began answering questions before I asked my first. I found that I actually have a lot of knowledge that can be passed on to others and by doing so, as others said, I learn a huge amount. That is important because I am doing a full time job - whilst helping others is nice I only spend work time doing so because I learn a lot that improves my own programming too so my employers gain from that.
In addition to this forum Yair Altman's blog has regularly been a source of enlightenment for me, especially when I go 'off-piste' with my requirements and need to delve into java.
Finally, two of the biggest things that helped me learn Matlab:
- The Matlab Command Window - use it! Experiment with syntax and try things out because it is easy
- The debugger - allied with the Command Window debugging code and being able to play around on command line from within a debug session is invaluable.
Walter makes a good point. I've written up my thinking on hundreds of hands of bridge that I have played. Not MATLAB, but often just as difficult. What I found was that by writing out my thoughts in a clear, cohesive manner so that others can follow them, it forced me to actively think about the problem. It made concepts clear to me that otherwise were slightly fuzzy.
It is said that you do not really know something until you can explain it to someone else. Answering other people's questions helps a lot in learning yourself.
I've learned a tremendous amount by asking and answering questions on this forum. I probably learn more when I answer questions than when I ask.
The one thing that really stepped up my skills, though, was developing a habit of properly documenting the codes I write. I typically spend twice as much time writing documentation as I do actually writing the functions, but I am convinced it's worth it. The benefits of good documentation are multifaceted:
- I always start with a Syntax section. This is where I have to ask myself, "how will users try to use this function?" and "what are the simplest, most intuitive options the function can have?"
- Next comes a Description section. This is where I describe the different options listed in the Syntax section. This step forces me to think about what exactly the function is doing and why.
- The Example section is the big opportunity for learning. The process of writing a good set of examples serves quadruple duty as you'll think of all the ways your function can be used, you'll think of new options that your function should have, and you'll see the ways your function could be more user friendly. If you make examples to highlight every different way your function can be used, running those simple examples will be a great way to error check your code.
I am convinced that the best way to become a good coder is to write good documentation. Teaching is the best way to learn, and writing good documentation is teaching. You don't learn many tricks when you write documentation, but you learn how to think about problems, and you develop an intuition for how to make code more efficient and more user friendly. The more user-friendly your codes are, the less cluttered the user's mind will be, the more you'll understand your own code, the more efficient your codes will be, and the more repeatable your science will be.
In my view, the best way to become a better Matlab coder is to learn and use the publish feature. Syntax, Description, Examples. For everything you ever write, even if it's only for yourself.
Very Good Point on Documentation!
+1 a very important point, and clearly explained.
Thanks. The publish feature sounds very useful. I will definitely look into it and start using!
Like Walter, I learned to program in older languages - mainly Fortran & APL. This teaches you good concepts about programming, but languages like Fortran can be counterproductive if they get you in the habit of writing loops. I imagine that C is also in that bin, though I cannot tell, since I can barely spell C, not to mention write in it. (Newer versions of Fortran allow array operations, a much easier way to write code, and better for moving to MATLAB.)
The point is though, that you may need to learn a new programming style, thinking in terms of operations on entire arrays, rather than single element operations wrapped in loops. This takes some practice.
To learn MATLAB, I'd suggest picking a problem that interests you, and solve it. You might start with the Cody problems, but I'd suggest harder and more interesting problems like the Project Euler problems. Many of them are quite solvable in MATLAB. (I've done a few hundred myself in MATLAB, so I know this to be true.)
As you advance in skill, you can also try picking apart the code of others, as found on the File Exchange. I've got 50+ tools on the FEX for example. Pick a simple one, and look how I wrote it. This can teach you things about various programming styles, especially if you look at the work of other respected authors on the FEX.
And of course, you can learn a lot by reading the forums. Be careful though. Apply a filter to what you see, since anyone can answer a question. (Including me!) Think about what you see, and decide if it makes sense to you.
Thanks for the great advice! I have also taken Fortran in some of my engineering classes, but was not very interested in programming that time. However now, after started learning MATLAB, I can see how amazing it is. Never thought programming would be this exciting!
Also, drink lots of coffee!
I reject the label "expert", but here is my two cents worth anyway:
MATLAB Specific:
- MATLAB has a great feature that very few programming languages have: readable documentation. Use it! Search it using your favorite internet search engine. Practice browsing it via the contents on the left-hand side (which are all hyperlinks). Understand how it is grouped by topic. Try out the examples. Use the help to locate related functions and advice on how to solve particular problems.
- Note that the online documentation is for the current MATLAB release: your installed MATLAB version may be different, so ultimately you should always refer to the installed help of your installed MATLAB version.
- Read the help for every function and operation that you use, no matter how trivial you think that operation is. Half of the questions that we answer on this forum are solved by reading the documentation for the function/operator that the user is already using!
- Learn to use the debugging tools. These are indispensable. Read about how they work and what they do, then practice using them! For starting debugging, the most useful command is: dbstop if error
- Learn the differences between array and matrix operations, otherwise your calculations will simply produce nonsense and you won't know why. If you are not doing linear algebra you probably need array operations (aka element-wise operations).
- Learn about comma-separated lists, and the easy ways to use them.
- Learn about indexing, which is one of MATLAB's superpowers. In many cases logical indexing is the simplest and most efficient (but all of the different ways of indexing are useful in different situations).
- Pay attention to all of the code warnings, error messages, underlining, and tips that the MATLAB Editor shows. Do not ignore these messages.
- Learn good MATLAB programing habits right from the start, because life is too short to un-learn bad habits! This means: comment your code, use consistent formatting, write help (with H1 line) in every function, pass variables properly, use input checking, never use eval (or assignin, feval, etc), etc.
- MATLAB blogs are an excellent source of inspiration and ideas. Loren Shure's blog is a mine of great ideas, and a veritable pleasure to read too.
- Check out other people's code on File Exchange (FEX). Note that the comments are often more useful than the ratings... and you will soon get an idea of whose comments are particularly worth paying attention to.
Code Design:
- Write functions, not scripts. Scripts are good for playing around with, but not for real work.
- Make vectorized code your first choice when writing code, and leave those ugly low-level loops behind you... Understand why vectorized code is beautiful, and how it can be used to make your code much more efficient and easier to understand.
- And of course when loops are required, always preallocate the arrays before the loops
- There are important ways to write fast and efficient code. Use them.
- For example, instead of slow and hard-to-debug cd (or even worse, adding data folders to the MATLAB search path) use absolute or relative filepaths when importing/exporting file data.
- In filepaths, use '.' to refer to the current directory (rather than slower pwd or cd).
- In filepaths, use '..' to refer to the parent of a folder.
- Do not use if to operate on parts of your vector/matrix, most likely you should be using logical indexing.
- Pass variables reliably using input/output arguments and do not use globals or assignin. If you need to pass lots of values (e.g. simulation parameters) then put them into a structure and pass that.
- Refer to all graphics objects (figures, axes, lines, etc) using explicit handle references (e.g. using Parent property). This makes plotting and handling graphics robust and predictable. Do not assume that the current figure/axes/etc is going to be the one that your code needs to access.
- Do not force meta-data (e.g. dates, times, indices, test parameters, etc) into variable names or fieldnames: meta-data is data, so store it as data in an array.
- Use subs to substitute values into a symbolic expression and evaluate it. Do not use eval to do this, it is not the correct tool for the job!
General Advice:
- Imagine that every script and function you write is going to be given to someone else... impress them!
- Test everything thoroughly. Check each line as you write it. Does it really do what you think it is doing? Many beginners come here to ask for help because they only think about what they want their code to be doing, but never bother to actually check what their code really is doing. Code cannot read your mind.
- Make a set of test-cases and collect all of the instances that fail while the code is being written, plus all the edge-cases and every case category that it needs to work with. You will not regret doing this.
- Break problems into parts, solve the parts separately. Make functions for code that needs to be repeated: this allows code to be reused, and bug-fixed in one location. Scripts are great for quickly testing an idea, but functions are much more robust for anything that will be used for more than one day.
- Think about what you are doing: actually think. What is the problem being solved? What is really the problem? How can it be solved? With what methods? Read Pólya's excellent book How To Solve It.
- Don't get stuck believing that you have found the best solution... there can be a much better solution waiting just around the corner, that may just require a new perspective, a reformulation of the problem, or a slight rearrangement of the data. Keep an open mind.
- Practice! Challenge yourself with tasks you want to solve, or take part in onlne code challenges or tutorials.
See also:
Other than Onramp, is there anywhere else I can do practice problems?
Tanks
Thank you Stephen. Really appreciate it.
Thank you Stephen. This is some really good advice. Especially for beginners.
Thank you Stephen. This was helpful.
Thanks a lot for such a wonderful advice!
Super helpful. Thanks. Been struggling
Thank you Stephen for teaching us, novices, how to catch the fish!
Along the lines of what Stephen has so ably said here, I have sometimes suggested you write code as if any day, you might be run down by the crosstown bus.
That is, assume that any day, even tomorrow, somebody that you work with will possibly be given the task of fixing and maintaining the base of code you have written. You want your code to be easy to use. Easy to read. Easy to maintain. Treat others as you would want them to treat you.
valuable comments and advices!!
Those are very useful tips, thanks a lot!
One day.. I will grasp things you tried to convey here. Thanks for all the valuable pieces of advice!
@John D'Errico Being "pert" is just like declaring a recession. It takes a long time to recognize the condition, so it's only done after the fact, after much time has elapsed. No on wants to admit to being in one, but are glad to declare that the condition has passed. :)
Congratulations Stephen, I just voted for your answer and it made you reach the exalted 3000 point level so now you have full editor privileges!
"allowing the user to give the name as a string" which is exactly why I would never advise beginners to use it: I believe a clear distinction between functions (which are passed as handles) and strings would actually make things easier for beginners and advanced users alike, as they would instead use function handles properly. Function handles do not require feval and feval probably occurs mostly to support legacy code/syntax, but the fact is that strings are not functions (they need to be eval-uated, or have special parsing).
As MATLAB has developed, more and more emphasis has been placed on using function handles instead of "inline"/string functions and for a very good reason: they are the best tool for the job. A function handle is designed for functions, a string is designed to hold some random characters. Using the correct data class to pass functions makes code simpler (only one class to handle), more robust (class can be checked, but a string needs to be evaluated), more expandable (functions of functions is easy), etc.
Note also that the MATLAB documentation specifically advises: "Avoid functions such as eval, evalc, evalin, and feval(fname)."
But feval(symengine) seems quite reasonable :)
feval() is used all over the place in Mathworks functions in order to invoke user routines with the flexibility of allowing the user to give the name as a string instead of as a function handle.
feval(symengine) is a practical necessity to talk to the additional functionality of the Symbolic Toolbox -- unless, that is, you want to use evalin(symengine) which takes only a string and so is less flexible.
I would thus remove feval() from the list of functions to never use.
My favorite definition of expert was given by Nicholas Butler, president of Columbia University, who said "An expert is one who knows more and more about less and less until he knows absolutely everything about nothing."
To add to the list, if you cannot find it fully documented in the accessible documentation try going to the undocumented matlab website and you may find what you're trying to accomplish there. I find it helpful when trying to create GUIs and graphics handling.
(in my opinion the debugging tools should be higher up on Stephen's list. The majority of the time gives the needed insight into what the issue is and what went wrong in the implementation/or was unexpected.)
What exactly is considered to be "what one would call pert"? Can you give a precise definition of a pert? If not, how can you be sure you've never been one? :-)
In regards to the line "I reject the label "expert""...
My response is that when I was young, I was never what one would call pert, so how could I now be an ex-pert?
Thanks. After numerous of failed attempts, I think I unconsciously started to follow your exact advice. I was exactly thought that I should start fixing my 'bad habits'. Lucky that I am on the right path! Thanks again.
I have not read any books on MATLAB.
I mostly read a lot of postings in the MATLAB Usenet newsgroup, comp.soft-sys.matlab . It does not take long before questions pretty much repeat and one can start to answer other people based upon what one learned before. Through reading enough Questions and the answers from other people, and some experimentation, and reading documentation, one can learn a great deal.
My response has to be understood in the context that I was already a quite experienced programmer when I started using MATLAB, so MATLAB was "more of the same" with some interesting features added on. Possibilities such as classes and parallel programming are, to an experienced programmer, less about syntax and more about learning new ways of thinking about programming. (But experienced programmers can get a bit fossilized in how they think about programming, so it can take a lot of practice to learn completely new ways. I never really "got" object-oriented programming, for example.)
Very practical points how to practice and master programming tools of MATLAB.
Thank you for your answer. I should have checked the older posts, and the one you included is very useful. I have experience in C and C++, yet I still find MATLAB to be quite confusing. I have managed to follow couple of textbooks, but was still struggling. However as you mentioned, reading through Questions and Answers, and trying actual problems from Cody and Project Euler seem to help a lot.
Thanks!.
Sign in to participate
