Matlab for Beginners

User avatar
tptspecial
Posts: 0
Joined: Thu Jan 01, 2004 12:00 am

Matlab for Beginners

Post by tptspecial »

@jungle:



Thanks for mentioning my blog.



My experience with R has been very bad. It was slower than matlab and documentation is worst. Moreover, it is open source. How well has it been tested for bugs is everybody's guess. Syntax wise and ease of use, i like matlab over anything else.
User avatar
redandtheblue
Posts: 0
Joined: Thu Jan 01, 2004 12:00 am

Matlab for Beginners

Post by redandtheblue »

I know that I should not wade into this argument but I wanted to mention several things.



for fair use,I use R and I find it great. There are many packages and it is incredibly easy to try certain ideas. However, the documentation sucks. If R is incredibly slow, I would check out the Burns book: http://www.burns-stat.com/pages/Tutor/R_inferno.pdf



Also, I could not understand why someone would want to implement R inside of C++.



large open source projects tend to be very good against bugs and I have not seen more in open source than proprietary programs. I use an open source operating system, and libraries in c++(boost).



At the end of the day, I think it would be pretty slow to test any high frequency strategy in either environment. R is pretty bad at iteration.

Writing an instruments class that is then iterated over all ticks would take a long time. If you can write a test using vector operations, R is great.



kamikaze Trader, in answer to your question. matlab would be fine but what makes the biggest difference is what time frame you are looking at. If you are looking at High Frequency, I would think it would be worth it to implement in C++. Otherwise, if your plan is to trade a few times a day at most, it would not make a large difference.



One language that I would recommend a beginner to look into is Python. There are a lot of resources on the web to help you.
User avatar
Polter
Posts: 0
Joined: Thu Jan 01, 2004 12:00 am

Matlab for Beginners

Post by Polter »

Whenever I encounter a discussion like this, the following fragment springs to mind:



"The question “Which is the best memory management algorithm?” is very similar in spirit to any of the following questions:



“Which operating system is the best?”

“Which programming language is the best?”

“Which data structure is the best?”

“Which type of screwdriver is the best?”



I can recall asking a program manager at Eaton Corp., John Schindler, what the best operating system was. John was managing at least a dozen different high-end platforms for Eaton, and I thought he would know. I was expecting him to come right back with a quick answer like: “Oh, OpenBSD is the best.” What actually happened was something that surprised me. He looked at me for a minute, as if the question was absurd. Then he smiled and said, “Well, it really depends on what you’re going to use the machine for. I use Solaris for networking, HP-UX for app servers, AIX to talk to our mainframe, NT for mail, . . . ”



The truth is there is no “best” solution. Most solutions merely offer certain trade-offs. In the end, the best tool to use will depend upon the peculiarities of the problem you are trying to solve.



This is a central theme that appears throughout the domain of computer science. Keep it in the back of your mind, like some sort of Buddhist mantra:



“There is no best solution, Grasshopper, only trade-offs.” " -- Bill Blunden (2006) "Memory Management: Algorithms and Implementations in C/C++"



Seriously, what's the point of arguing about the best type of screwdriver?



In my daily work I find myself using C++ (both MS and GCC implementations) sometimes relying on C libs -- as this solution is fast enough and quite expressive while giving access to plenty of accumulated code, R comes quite handy for plotting and prototyping and a wealth of libraries/packages certainly helps, Mathematica is most convenient for playing with equations, MATLAB has a great profiler (and compatible Octave has useful libraries), the stuff I've learned from functional programming comes useful in all of the above. Gee, sometimes one even has to use Excel to present the results/make them available to folks who don't have time/money/skills/reason to use anything else...



BTW, there is also open-source MATLAB-compatible GNU Octave:

http://www.gnu.org/software/octave/



As for the performance benchmarks -- while I've personally found the NCrunch one quite interesting, those are also to be treated with a grain of salt -- e.g. while MATLAB certainly achieves a reasonable run-time performance, its start-up time may exclude it as a prototyping/quick modeling solution, while Mathematica (according to the same benchmark on par with MATLAB) or R start pretty much instantaneously. Similar criticism can certainly be raised against larger C++ projects, when compile-time (esp. when using QuantLib) becomes non-trivial -- though the run-time performance benefit is usually more than enough to outweigh this and that's when it makes most sense to use C++.



What I am trying to say by all of this is that your particular application matters -- a LOT. Perhaps you'll find it best to play with some initial formulation of your model in R and code the final solution in C++ -- perhaps you'll find a completely different approach, involving different languages, works best for you -- and perhaps hours/days/weeks/moths later, while working on another project, you'll end up using a very different toolchain than the one you started with. Hence, it's worthwhile learning to be flexible -- and note, that learning more programming languages can make you a better programmer in general (e.g. understanding map & fold/reduce in a functional programming language won't hurt when using std::transform & std::accumulate in C++).
MadMax, some curiosities regarding the performance of std::accumulate are also related to it using operator+ (not operator+=) and issues with trying to optimize it with move semantics (from a compiler point of view) keeping standard-compliance; discussion here: http://gcc.gnu.org/ml/libstdc++/2011-01/msg00015.html

I solely mention those as "curiosities", since I wouldn't expect them to have an impact on "small" data structures (like a built-in double) (and the example above considers std::string), but it might still be of interest.
User avatar
ast4
Posts: 0
Joined: Thu Jan 01, 2004 12:00 am

Matlab for Beginners

Post by ast4 »

It's kind of entertaining that this thread has digressed into a Matlab vs. R thread.



Where I stand at with this issue is somewhat in line with what Polter had to to contribute. And that is Matlab is great at somethings, while R is great at others. I use the two interchangeably depending on the task at hand.
"Mathematicians are machines for turning coffee into theorems!"
User avatar
jslade
Posts: 0
Joined: Thu Jan 01, 2004 12:00 am

Matlab for Beginners

Post by jslade »

R&B: "Also, I could not understand why someone would want to implement R inside of C++. "



I have a hard time figuring out his motivation as well, but I know why I want to do it. Let's say you have a high level language which is trivial to call C++ from (yes, I code in Lisp; get a load of the propellor on my head Radiation ). You wake up one morning and decide it would be neat to try some kind of machine learning gorp in your wacky doodle idea. Trying ideas like this are what high level languages are good for after all. If you have to port the whole ML thing to your language, you might waste a lot of time, because maybe it was a dumb idea. If you can feed a string to your encapsulated R and get the result to see if it's promising, that can be helpful. Python uses this trick, though I think RPY is more complex than the embedded R thing.



Of course you can do this in Matlab also, but not if your boss don't want to pay for a license.
"Alles hat ein ende, nun die wurst hat zwei."
Post Reply