Thought I would give a quick update, and you all know that the trade system is coming along great. I should have it complete by Monday (give or take a day).

SodyTexas 

Thought I would give a quick update, and you all know that the trade system is coming along great. I should have it complete by Monday (give or take a day).

very interested to see what you've come up with

RickW00716 

very interested to see what you've come up with

Hopefully its not to hard to follow.. But if I post a system with my name associated to it I'm going to make sure it is good.

It will be worth the wait.

Cheers,

Sody

SodyTexas 

The XPS of Ahrens did not upload, so let me attach the PDF of the OCT 2013 S&C.

It is not clear to me -- Is this publication freely available by the source? If it is not freely available, it needs to be removed immediately from futures.io (formerly BMT) as we don't allow copyrighted works (pirated material). Please reply ASAP.

Mike

Big Mike 

It is not clear to me -- Is this publication freely available by the source? If it is not freely available, it needs to be removed immediately from futures.io (formerly BMT) as we don't allow copyrighted works (pirated material). Please reply ASAP. Mike

Am not sure or not if it available freely or not. Please remove immediately. I have a subscription to S&C and I know they have some articles freely available. But I am not sure if this is one of them.

I will do more research and make sure it is before reposting.

Thanks Mike

SodyTexas 

Hopefully its not to hard to follow.. But if I post a system with my name associated to it I'm going to make sure it is good. It will be worth the wait. Cheers, Sody

will your system be for intraday trading or will it be something that can be used on all timeframes?

artemiso 

@Limitless100 I guess you meant this? Firstly, it sounds to me that you're using managed C++, which loses important benefits of the language without gaining anything. To be fair, my opinion is not so useful. I'm generally agnostic to the programming language. I have memory-hungry applications that would cost more in server power/computation time than developer salaries, so C# is not my weapon of choice. At the same time, I have many more lines of Fortran in production mode than C++, so I'm not the best person to defend C++ either. Hand-holding: C# .NET does a fair job of trying to hand-hold mediocre developers, e.g. it doesn't support multiple inheritance through classes; point-and-click UI builder in VS for writing industrial strength GUIs; I would also rather C++ has an immutable string library and think C# has the better default here. Microsoft steals good ideas every now and then (parametric polymorphism in 2.0, lambda expressions in 3.0), and I like the language direction. But I think choosing C# .NET over C++ because of anxieties over memory management is an uninformed decision. It's a commonly-perpetuated myth that memory management is difficult in C++, and that you hardly need to worry about that in C# .NET/C++. I don't think that's the case - I don't want to get into this fight because everyone has written pages of arguments about this, but I can say that in the C# .NET programs that I've written for financial applications, I spent a lot more time making sure every object either lived forever or died immediately before it got promoted to generation 1/2. If you don't understand the purpose of this though, I'd honestly think you're better served with Java/C# .NET for now. The practice of writing good code in C++ is mostly similar to that in C#. Prefer static dispatch over dynamic dispatch (C# .NET 4.0), maintain modular abstractions etc., so at the end of the day, the onus is still on the developer and has nothing to do with the technical merits of either language. Concurrency: I don't know what others think but if you're going to make a living with this, you're going to have multiple cores on multiple machines. A reasonable way to parallelize your workload across multiple machines is to fork multiple processes and have them communicate via message passing. As far as I know, there's high-performance messaging middleware with efficient C++ interfaces, but not so much .NET interfaces. (I would probably recommend Solace if you were working with .NET.) Containers: C++'s STL containers are powerful and useful for what you're trying to do and have no practical equivalents in C#. An interview question I would give to a potential developer is to name/think of an application of a standard C++ container in a financial setting - if you don't know the answer, chances are that you're better off with C# .NET/Java. Libraries and third party integration: There isn't even a serious numerical library or market access API with C# bindings (Lime/WEX, maybe). You could pay for Extreme Optimization's MKL wrappers, I suppose. Low-level facilities: You should make up your mind - you probably picked C++ initially because of what you've heard about its performance (I think this is misguided), but you're going to have a hard time doing any meaningful performance measurement in C# without access to low-level facilities - so perhaps performance isn't really a concern for you after all? MATLAB/R: My most serious problem with using array-oriented languages such as MATLAB/R/numPy is that it accustoms you to manipulate and analyze data in a very rigid, flat and uniform manner - it's a round hole and your market data is like a square peg that doesn't fit in it very well. For example, there's no clean way of processing sub-tuples containing both strings and integers in an array-oriented language. I personally like MATLAB over R/numPy because of its cleaner documentation and the proprietary package distribution model. Think of it as an iPhone. There are many good apps for the iPhone because it's a single spec with tightly-controlled, proprietary distribution; Android apps have to deal with different technical specs, screen sizes etc. Performance-wise, MATLAB's parallel processing model is also more convenient than R/numPy, and similarly, most CPU-bound operations are highly-optimized Fortran/C routines anyway. Basically, I did have a happier experience developing in Fortran and C++ than C#; Fortran and C++ have been more productive and have offered better development tools. To give you an idea, my best times-to-market were about 2 days in Fortran, C++ and Python vs 2 weeks in C#. Your mileage may vary.

Wow Fortran over C#.. How dare you sir.. And to insult numPy as well; let's leave Python out of it. The fact is simple. Fortran and C++ is still relevant to UHFT because of the speed. This journal thankfully is not about HFT and not all quant trading is HFT.

Unless we are here to compare how many Cuda's we have stacked for our parallel processes I'm going to try and move past this code talk.

I apologize if joking about C++ offended you. C# in this case is a necessity to ninjatrader, personally, my trading stack outside of Ninja and beyond the scope of this journal is Python.



Cheers,

Sody

SodyTexas 

Wow Fortran over C#.. How dare you sir.. And to insult numPy as well; let's leave Python out of it. The fact is simple. Fortran and C++ is still relevant to UHFT because of the speed. This journal thankfully is not about HFT and not all quant trading is HFT.

Just to emphasize: I prefer these languages over C# because of their ease of development and availability of tools, and I didn't mention that speed was a deciding factor.

SodyTexas 

I apologize if joking about C++ offended you. C# in this case is a necessity to ninjatrader, personally, my trading stack outside of Ninja and beyond the scope of this journal is Python.

Oh no, no offense taken at all. @Limitless100 just wanted to hear my thoughts on C++, MATLAB, R and C# in reference to what you had mentioned.

Python is my go-to language for almost anything that takes less than 40 lines to express. But to wrap up on my point to @Limitless100 that I prefer to be language-agnostic, take this for example: How would I write a Python script that recursively checks if Quantopian's Zipline is a poorly-written library only designed for single-core processing at the application level? I can do this very quickly in Perl, but not Python:

 

Code

#!/bin/sh grep -r multiprocessing zipline/ | perl -e 'while(<>){}; print $.,"\n";'

Every language has its elegant side, I'd learn many and choose whatever makes you feel comfortable and productive.

Anyway, I agree that we should move past a debate about programming languages.

@artemiso,

You have always made excellent and informative posts, but sad to see that you usually delete them.. sigh..

artemiso 

Just to emphasize: I prefer these languages over C# because of their ease of development and availability of tools, and I didn't mention that speed was a deciding factor.

Just added my two cents, that I see value in C++ and Fortran when it comes to speed. But (at least for me) I find C# easier to code in than C++ (Fortran I have very little experience) . Completely, agree that the language depends on the project your working on.

Thanks for your input to my journal!

Sody