Numerical Solutions to ODE

Please someone help me how to find information about the advantages and disadvantages of each method (Euler, Heun and Runge-Kutta). I surched in google and there is nothing useful posted there. We using Dennis Zill textbook for First course of DE. I need to kind of compare them before I use one of them for a mini project. This independent study online course.

Consider whether the method is explicit or implicit (implicit methods require solving non-linear algebraic equations at each time-step which is gah :( , but on the other hand tend to be more stable as far as absolute stability is concerned which is a definite yay :D ) . . . think about the advantages or disadvantages of the method being single-step or multi-step, of methods that are linear versus non-linear methods . . . of methods which are specifically designed for solving "stiff" problems . . . there are advantages and disadvantages to all these aspects, depending too on the differential system you need to solve . . . reducing the step-size when a method is not performing well is not always the best solution because very small step-sizes can lead to problems related to finite precision errors . . . so it's good to look for alternate methods :)

A good book (at least I like:P) is: "Numerical Methods for Ordinary Differential Systems: The Initial Value Problem" by J. D. Lambert.

After learning the numerical methods, the next step is to write program for the algorithm. I don't expect we calculate manually. So what is the most appropriate language for doing numerical computation? I would say use Matlab ( sorry this is the only language I know! )

But I have seen people using C++ to do numerical computation. Is there any advantages of using C++ over matlab ? Beside it able to create exe file (stand alone program). Graphic is difficult to display in C++.

I'm like yoo matematikawan, I only know Matlab :P I don't think there'd be any advantages or disadvantages to programming the method in any other language (as far as the end results go, as long as you use the same precision to represent numbers), just it would be harder maybe, and take longer to execute, because Matlab is optimized to operate with matrices and for the programmer it's really so easily to operate with them . . so for example how would you do x=A\b in C+, would you have to implement another algorithm just for that? I really don't know . . . but if you do, then I'd stick to Matlab :)

Well, Matlab is really a scripting environment more than a programming language. It is interpreted, if my recollection is correct, which means that it's never actually compiled to machine code. This has advantages and drawbacks. Advantages include less restrictive syntax and easier debugging / execution. Drawbacks include slower speed and more complex semantics. Also, as a scripting language, interfacing with hardware and using low-level constructs is clunky and/or impossible.

A good discussion can be found at http://www.cpptalk.net/c-vs-matlab-vt47148.html [Broken] .

Basically, I feel like Matlab is a numerical analysis tool, and that C++ is a general-purpose programming language.

Apparently, Matlab is Turing complete. Still, I wouldn't want to misuse it to write general-purpose programs.

Thanks for the link the matlab vs C++ discussion. I copy here the reasoning by one responden Tuva

...With that said, there are cases whereby one still might consider C++ for a scientific function library. I can think of three:
A) Matlab code isn't fast enough,
B) Matlab code cannot be transported to a DLL or COM object (for example some of the neural net functions cannot be compiled), or
C) Matlab is too expensive.
But even in those cases I would think long and hard before going C++ entirely...

For the reason A, I don't worry much. I think Matlab is fast enough to do my job. For reason C, I also do not worry. Our department have matlab install in almost all PC in the lab. To work at home I can use matlab clone Octave.

But I don't understand reason B. What are these DLL or COM object? Never came across before.