Creating own trading system

[j2ee]

Quote from colion:

Your characterization of Amibroker in particular is quite incorrect. It is equal or better than any program when it comes to speed and backtesting. The AFL language is powerful and can be learned by non-programmers with moderate effort. While good programmers can produce almost anything other users might find a more complete set of built-in analytical and graphic tools in other programs that satisfy their needs "out of the box" without any programming. As with any program, the only way to evaluate it is to take it out for a "drive" and then decide which one gets the job done and represents the best value. No comments on this or any other forum beats a "hands on" evaluation. Caveat emptor.

AFL language VS C#, simple choice.

AFL language is just limited and hard to learn. Yeah for a super simple common knowledge level then ok, but once get to little bit complicate, then find out how to program with AFL is a pain. Why not just use real programming C# and it is free? Simple choice.

 

[NetTecture]

Quote from j2ee:

Why would you guys use web and visualization while you need the best performance? If we are talking about HFT level of intensive backtesting or trading, even how far from the exchange matters, web/visualization just doesn't match the demand.

We may talk about HFT, but it is not HFT to have an overvoew and control panel for the backtest grid, to see the jobs and job history. Stuff like that. Even "current PNL and position overview" on a browser is nice - something I can call up from my tablet to see where we are standing.

If you look at a complex system not everything is directly related to trading. Today we did calculation grid updates. Next update is the portal for the grid, where we can see and control the jobs and the grid (take machines out for maintenance). See the job and task queue so that a dev can see where his job is.

Similar standard reports and analysis may be nice on the web - run a simulation, get a URL you can send around to a specific report for that.

System development is not HFT. Trading is - or, maybe - but the development has a ton of tools around it.

 

[colion]

Quote from j2ee:

Amibroker speed is not bad, but it is not fun to deal with the snytax. It is much easier and flexible to directly do it with tradelink C#. There is just no point to learn Amibroker snytax while it is so hard to find out to do so many things in the coding.

Even a very simple strategy with some programming logic, learning how to do it with Amibroker is a pain.

I guess each of us has an individual learning curve. I'm not a programmer so went and took a community college home study course in C++ and the AFL was a snap.

 

[colion]

Quote from hftvol:

true regarding trying something provides more information to make an informed decision. But then I do not shoot heroin up my vein just to make an informed decision. I think I am informed enough to say that Amibroker or for that matter most retail off-the-shelf-products are not fit for serious systematic trading. I have had a copy of Amibroker a long while ago and I liked it and yes, it was very fast. I know the programmer and owner behind it and know he is an excellent C++ programmer.

You are behind the times. I have been an AmiBroker user for over ten years and the improvement has been remarkable and arguably is moving exponentially. Although I still use other programs for particular types of analyses I find that my use of them is constantly decreasing.

 

[j2ee]

Quote from colion:

I guess each of us has an individual learning curve. I'm not a programmer so went and took a community college home study course in C++ and the AFL was a snap.

There is definitely big limitation for AFL whenever someone has a more complicate idea to implement. It is just more natural and complete to use real programming language like C#. Java, C#, C++ are the biggest 3 and complete programming language in the world. I doubt if it is even possible to implement serious complicate non straight forward idea with AFL. Even if it is possible, find out how to do it would be a big pain. C# has unlimited resource, the searching time is too different. You can even get a good job with good at C#, while AFL means nothing in the job market, then why learn something useless in job market!? Yeah it is easy for beginner to learn, but true professional has much more complicate strategy.

 

[colion]

Quote from j2ee:

There is definitely big limitation for AFL whenever someone has a more complicate idea to implement. It is just more natural and complete to use real programming language like C#. Java, C#, C++ are the biggest 3 and complete programming language in the world. I doubt if it is even possible to implement serious complicate non straight forward idea with AFL. Even if it is possible, find out how to do it would be a big pain. C# has unlimited resource, the searching time is too different. You can even get a good job with good at C#, while AFL means nothing in the job market, then why learn something useless in job market!? Yeah it is easy for beginner to learn, but true professional has much more complicate strategy.

You are quite wrong. It is not "easy" for a beginner to learn AFL. As I said it takes a moderate effort.

I program in C++ and AFL and AFL is definitely simpler, more user friendly and can handle the most complicated algorithms. I have yet to see a programming limitation and I doubt that you have either. If you think that there is one I suggest that you post it on the Yahoo forum or send it to Support to find out if there really is a language limitation. These resources offer contact with first rate programmers.

 

[j2ee]

Quote from colion:

You are quite wrong. It is not "easy" for a beginner to learn AFL. As I said it takes a moderate effort.

I program in C++ and AFL and AFL is definitely simpler, more user friendly and can handle the most complicated algorithms. I have yet to see a programming limitation and I doubt that you have either. If you think that there is one I suggest that you post it on the Yahoo forum or send it to Support to find out if there really is a language limitation. These resources offer contact with first rate programmers.

Alright then a simple exercise: Implement the whole set rules of turtle trading. How to do this part with AFL?

The difficult part for programming:
for 20 days break thought, when the last signal was a win, you don't buy in this signal but you need to store the result just like this signal is traded. This "virtual trade" would also have increments like normal and cut lose/exit like normal. Then when the next signal comes, need to check this "virtual trade" result to tell if it was a win or lose to decide to trade or not. If the 20 days break thought was a win then once break through 55 days need to buy. You can see a better description in the free document online, just google original turtle.

 

[hftvol]

maybe you should have been more specific in your previous post. What you describe here makes sense to at least make available through a web interface. But your previous post strongly hinted at your implementing a core trading engine (hft or not does not matter) on a web engine and that makes simply no sense. Populating performance results does make sense. What people often do is they implement a scheduler to periodically push content onto the web interface (if you use silverlight then you can easily bind to the data source that is updated through the scheduler). The Binding takes care of grid and chart population. I do something very similar. I also store all performance results and trade analytics in a database that is bound to controls on my web interface. WPF and Silverlight is very advanced and a pleasure to work with in this regard.

Quote from NetTecture:

We may talk about HFT, but it is not HFT to have an overvoew and control panel for the backtest grid, to see the jobs and job history. Stuff like that. Even "current PNL and position overview" on a browser is nice - something I can call up from my tablet to see where we are standing.

If you look at a complex system not everything is directly related to trading. Today we did calculation grid updates. Next update is the portal for the grid, where we can see and control the jobs and the grid (take machines out for maintenance). See the job and task queue so that a dev can see where his job is.

Similar standard reports and analysis may be nice on the web - run a simulation, get a URL you can send around to a specific report for that.

System development is not HFT. Trading is - or, maybe - but the development has a ton of tools around it.

 

[hftvol]

telling someone who works with FPGAs and has written whole trading systems in distributed and multithreaded fashion from the ground up as well as wrote high throughput binary data bases that even blow away KDB (not in terms of all-round functionality but latency and throughput) that he is behind his times because you are up-to-date with Amibroker makes you look like a monkey.

Amibroker is a charting and LIGHT profiling tool, even the programmer who is behind this application does not claim it to be more than that.

Quote from colion:

You are behind the times. I have been an AmiBroker user for over ten years and the improvement has been remarkable and arguably is moving exponentially. Although I still use other programs for particular types of analyses I find that my use of them is constantly decreasing.

 

[hftvol]

I do not know why you are so married to this application but please keep both your feet on the ground. AFL cannot handle the "most complicated algorithms". You need reasonable work-arounds and maybe you show us how AFL handles a matrix inversion (it could not as of 2008, and as mentioned I have not evaluated any subsequent versions) without having to link up to external libraries. Also, how to implement multithreaded paradigms? How do you handle database access to those dbs that are not supported out of the box? How do you connect to unsupported broker APIs? Right, you need to code an interface in a compiled language!!! And how do you implement a simple Kalman or Particle filter? AFL is what it is, a scripting language in order to avoid having to learn a programming language and as it is based on C++ (well the whole engine is) there are components and ideas that look familiar to someone who knows C++. That is all to it. It comes with all the limitations that most other scripting languages suffer from as well. But again how it is implemented is extremely smart and sleek.

Quote from colion:

You are quite wrong. It is not "easy" for a beginner to learn AFL. As I said it takes a moderate effort.

I program in C++ and AFL and AFL is definitely simpler, more user friendly and can handle the most complicated algorithms. I have yet to see a programming limitation and I doubt that you have either. If you think that there is one I suggest that you post it on the Yahoo forum or send it to Support to find out if there really is a language limitation. These resources offer contact with first rate programmers.