Converting TickZOOM Engine to C++? Support C++,Java,& C#?

There's been an exciting development.

My C and C++ past life is coming back to me in floods!!

At first I was struggling with the most basic syntax--frustrating after spending over 10 years of my life programming C and C++.

Anyway, last night it started to flow, things started popping into my head.

It seems the C++ juices are flowing again after browsing through some reference material, etc.

BTW. I actually won awards for C++ coding in the past. I remember getting a "Road Runner" award for (they claimed) coding 7 times faster than anyone else on the 40 person project.

I wasn't really that fast.

But anyway, it seems far easier to "remember" a lost skill than to learn it from scratch like I did when learning C#.

Sincerely,
Wayne
 
Ninjatrader does a good job in the area of inclusivity of non-techies. I'm a self taught programmer [and that really, really does not work for things like C#] and they provide full documentation with example code. I got used to their stuff and can whip up an indicator faster in C# for Ninja than EasyLanguage..
 
Quote from Fractals 'R Us:

Ninjatrader does a good job in the area of inclusivity of non-techies. I'm a self taught programmer [and that really, really does not work for things like C#] and they provide full documentation with example code. I got used to their stuff and can whip up an indicator faster in C# for Ninja than EasyLanguage..
More...

That's true. And C# has many advantages over EasyLanguage.

But EasyLanguage has some solid advantages too.

If TickZOOM fits a user's needs for market simulation and automated trading then ....

... you get the best of both worlds in the writing of indicators and strategies EXCEPT there's limited examples and existing indicators to reuse.

That's because TickZOOM C# handles data the same way as EL by doing automated bounds checking and reverse indexing.

Also, the base classes for TickZOOM models are all open source which facilitates understanding and makes it possible to modify them.

Again, NinjaTrader is awesome if you want to discretionary trade with some of your work automated. It's very cool.

Wayne
 
Quote from greaterreturn:

Interesting. Can metatrader call com objects?

Metatrader has an "engine" though for converting ticks to bars so it's unclear what use could come of running the TickZOOM engine in your strategies for MetaTrader. Interesting.

Wayne
More...
Yes, Metatrader can call com objects. MQL is basically c.

Tell me if I'm barking up the wrong tree here, but I have several issues with Metatrader that I'm hoping I can resolve with TickZOOM as a partial solution. I've emailed you about some of this, in case it sounds familiar.

My main problem with Metatrader is in its backtesting and optimization. It's OK I guess but I've very quickly run into its limitations. For instance, I can manually run one backtest, or request a series of backtests as an optimization, but I can't automate things any more than that. For instance, I can't have my strategy automatically backtest, walk-forward test, or run any optimizations every day or week or whatever.

It also seems to interpolate its ticks from M1 data, which as you can imagine can yield some, well, useless backtests. So even if I manually exported the backtesting results for further analysis outside Metatrader (a tedious exercise in itself), I have no confidence in the validity of the results.

Additionally, Metatrader is a Windows programme and I am primarily a Mac user. Metatrader's backtesting/optimization will only use 1 CPU at a time. You can imagine my frustration sitting here with an 8 core Mac Pro, watching 1 core chugging away inefficiently in a Windows VM on an optimization that I'm told will take 100 hours to complete.

My current plan is to write my optimizations in such a way that I can call them via COM from Metatrader through some sort of thing wrapper programme written in MQL. Then also call them from TickZoom using tick data from my broker (FxPro) that I've accumulated. I'll do my optimizations and backtesting from TickZoom, but run the same code, called via COM, as my live trading strategy from Metatrader.

- Andrew.
 
Folks, I'm really discouraged with C++.

In fairness, I got a part of the program completely running.

But what has me lamboozled is that there's very little tool support for C++ compared to C# or Java.

The most absolutely frustrating part is that C++ doesn't have any kind of serious Unit Testing framework other than CppUnit which is a ROYAL pain to try to use.

Without a doubt, even if C++ may run 20% to 30% faster than C# it will take 10 X longer development wise to get anything done.

Nowadays, I REFUSE to write any code without thorough a automated test suite.

The amount of time it takes to retest code manually is unthinkable anymore after using TDD in Java and C#.

My ability to fix bugs and turn around enhancements is C++ would be about 5 to 10 X slower than in C# or Java.

The other tools issue is the ability to refactor code in C# or Java. There's almost none of that in C++.

I found out why, it's because the syntax of the language is so much more complex (rich?) that it's 10 X harder to make automated tools like that.

I did a simple rename of a something in Eclipse and it only renamed maybe half the stuff it should have.

So I had to manually change all that stuff.

It stinks to HIGH heaven.

Folks, before I came to this conclusion, I searched website after website, tried tool after tool and it's the same everywhere.

Java actually looks more promising long term for cross platform with the GNI GCJ compiler since it can compile Java code on many platforms to binary executable.

It seems we're going to have to move forward with C# for now.

I'm open to suggestions and ideas on better cross platform support.

Java is a highly productive development language due to the tons and tons of SUPERB and free tools to work with.

I really had no idea how far Java had some in that area compared to C++ and C#. But there's not competing on raw productivity at this point.

Sincerely,
Wayne
 
I fully support you decision.

You are not the only one who is addictive to TDD. In my community we do not make a step without test coverage fully thought out, BVT in place and Gates check-ins (aka SNAP system).

Thats why I was sort of surprized you weren't going to release your test suite. Without it any contribution would become a nightmare of ping-pongs.
 
Quote from vladisld:

I fully support you decision.

You are not the only one who is addictive to TDD. In my community we do not make a step without test coverage fully thought out, BVT in place and Gates check-ins (aka SNAP system).

Thats why I was sort of surprized you weren't going to release your test suite. Without it any contribution would become a nightmare of ping-pongs.
More...

Ping pongs? Good point. But my plan has evolved (and will continue to evolve).

What we need to keep in mind the difference between the different types of users.

As you know many users are "non programmers" who taught themselves to write strategies.

So a test suite will be just a hassle and bother for them to learn and for us to support.

If those want to make a change or add something, then can. And then commit it then we'll test it, if it's worth accepting.

But for those making a significant contribution, I will bend over backwards to assist a developer who convinces me that he/she is seriously working on adding significant functionality.

So for example, if someone is adding a new broker interface, I can release a the existing tests related to that to avoid "ping pong".

And any developer making something significant is wise to create unit tests in the process of doing that.

Basically, I plan to deal very differently with public in general then people who prove themselves in various ways to be contributors.

And the other reason for holding the entire test suite is to have a concrete, serious motivation for people to actually go through the hassle registering as a commiter to submit the code.

Does that make more sense?

Nothing is written in stone at this point.

Sincerely,
Wayne
 
Quote from vladisld:

I fully support you decision.

You are not the only one who is addictive to TDD. In my community we do not make a step without test coverage fully thought out, BVT in place and Gates check-ins (aka SNAP system).

Thats why I was sort of surprized you weren't going to release your test suite. Without it any contribution would become a nightmare of ping-pongs.
More...

By the way, I loathe to get sucked into using all the vendor specific tools like SNAP, etc.

I was comfortable with C# due to SharpeDevelop and NUnit for TDD.

But recently as I was considering tools for builds and documentation, I'm dissatisfied with C#. It seems anything good comes from MS.

The maven build system is superior to anything available in MS land and open source to it's possible to extend it.

Add CruiseControl to Maven and Subversion and you have a recipe for a world class continuous integration system.

Frankly, due to the cross platform ability and awesomely powerful and open source tools available in Java, that will become my official target platform.

Specifically, (not now) but soon I will port the engine to Java in spite of lack of pointers or sizeof operator. There's always tricks to handle those situations. And there's other ways to squeeze performance out it.

Write now, I'm working on releasing C#.

Sincerely,
Wayne
 
By the way, I'm glad I did learn C#. Even after the engine goes to Java we can still support C#. A lot of people feel very comfortable with the vendor specific tools.

And Java can register as a COM object (just like C++) so it can Interop fine with C# and other Microsoft tools like VB, Excel, etc.

But that's all future. Right now, I'll focus on releasing C#.

Sincerely,
Wayne
 
Quote from greaterreturn:
What we need to keep in mind the difference between the different types of users.

As you know many users are "non programmers" who taught themselves to write strategies.

So a test suite will be just a hassle and bother for them to learn and for us to support.
More...

"non programmers" via "programmers" via "contributers" problem is already solved in most open source projects. It seems you are inventing a wheels here and only adding a complexity to your policy - which will eventually turn the contributers off.

Regular users and "non programmers" advanced users will be more then happy with binary distribution and will really enjoy your product being free. Adding .pdb file will be even enouph for basic strategy debugging and proper (and usefull ) bug reporting.

Others who will manage to get the sources from subversion and succesfully compile it, are "proffesional" :-) enough to enjoy the test suite - do not underestimate people skills.

Still the contributions can't be made directly to the trunk without the core team approval - it mean without your approval - so you retain the complete control over the project.
 
You must log in or register to reply here.
Back
Top