TickZOOM Decision. Open Source and FREE!

Status
Not open for further replies.
Yep, similar to NT, the first feed to log on to will be the Master and the other/s if any the back ups...
The "if any" will be important in case one chooses to use just one feed of choice.
 
Quote from Fractals 'R Us:

I can't login to your wiki so I'm posting here.

Backward compatibility can be a real albatross as the code grows. Maybe you could ensure backward compatibility by supporting all versions. If something is done to break the backward compatability the user can use the older versions until they fix their code to be newly compatible.

Interactive Brokers does not do backward compatibility, they break things with their new releases of the API. I guess they work with the main vendors that are using it, not sure about that..
More...

Understood. Backwards compatibility is a challenge however it is very possible.

Look at the Java language. It has lasted many, many lifespans in the software arena due to always supporting all the functionality of the previous versions. Anything new is always an addition. Sometimes features are marked as "deprecated" and the API can do that too.

When deprecated, they still leave them functioning until several versions later they get disabled.

Meantime people go years with the warnings if necessary.

Wayne

P.S. Let's take a simple example.

TickZOOM right now supports each strategy controling one Trading signal for one instrument to long/short/flat N positions.

It would be nice in the future to make that multiple so that in the same strategy code, I can go long one and short the other simultaneous like a hedge. Right now the Formula class only has a single member called TradeSignal which controls the single signal.

In a later version we may add a member to the interface called TradeSignals which is a plural. Internally it can still work with the TradeSignal (marked deprecated) as the first signal in the list.

That means any older strategies work seamlessly without change.

If you have a new strategy and you want to use 2 signals, you can use the newer TradeSignals.

And all strategies written from that point would avoid the single and using the 1st signal for a single strategy.

See? It's possible to always be backwards compatible.

If we completely overhaul the API for some reason. That's no reason to orphan the old one.

Since it's all interface driven, we can easily have 2 (or more) implementations. Also, we have the flexibility to make TONS of changes inside the engine that won't impact the previous written strategies.

NOTE: It takes tremendously more architecture skill to build backwards compatible systems which is while most software companies fail and usually it's because they fail to get enough input on the design from others in the community.

Java on the other hand is user community driven as far as enhancements and improvements.

But think about it. Other than minor stuff like switching to multiple signals. What can change?

Strategies will always have Bars with high/low/close, always have Ticks, etc.

Thing will more likely get added like options pricing information, etc.

So 90% of the API should never change.

Sincerely,
Wayne
 
In the recent past I looked into GV and learned that it actually is competitively fast!
Without intending to confuse the issue now, once we have the source I could try to find out if the API could just look to GV and pickup it's data regardless of whose feed is it and as such every user can do their own part there by supplying the number of feeds and back ups desired and how they would operate hence keeping the API as lean and mean as possible and simpler to maintain and avoid collision of choices over the feed and the broker issue as long as the API remains data aware?
The same could be done about the Broker as in the user receiving the orders and porting them to the Broker of choice using the Broker's API.
Again just for the purpose of easing the burden of the engine development.
 
Hi Wayne,
I am looking forward to trying your software. I would like to put a vote in for a Java version. Vista has pushed me over the edge, I want to run on Linux. As for speed, Java has been faster than C++ for most operations for many years now. I am an ex C++ programmer and there are a few things I miss from C++, but standard libraries and threading across operating systems made me switch. Java does have some disadvantages though. In general they are: slow startup, high memory usage, approximately 10% slower IO (this continues to get faster), slow trig functions (Java meets IEEE standards, but who cares). The reason Java is generally faster is the Hot Spot complier, which continues to optimize your code as it runs. Also Java memory allocation and garbage collection is much faster than C++ (go figure). Okay, most of these thing don't really matter, what matters is running fast on multiple platforms, and really fast on Linux (much faster than Windows).

Thanks for your great effort,
David
 
Hi Wayne,
For my primary data feed I use IQFeed from DTN. It is one of the most popular and does not filter the ticks. I get 1200 real time symbols for a good price (I can't remember the price). I use IB as my broker and would like to use it a a back up data feed. IB does not send ticks.

Thanks,
David
 
Quote from dholliday:

Hi Wayne,
For my primary data feed I use IQFeed from DTN. It is one of the most popular and does not filter the ticks. I get 1200 real time symbols for a good price (I can't remember the price). I use IB as my broker and would like to use it a a back up data feed.

Thanks,
David
More...

Thanks for the info.

IB does not send ticks.
More...

What do they send??

That was inconceivable to me until now. But obviously it's possible for broker to only provide a connection to place trades. Still it seems old, how do they know the bid/ask and last to track your account balance?

Oh maybe the have ticks but just don't provide them. Odd.

It's kind of cool the MB trading has such high quality tick data for free--just for having an account.

Wayen
 
Quote from dholliday:

Hi Wayne,
I am looking forward to trying your software. I would like to put a vote in for a Java version. Vista has pushed me over the edge, I want to run on Linux. As for speed, Java has been faster than C++ for most operations for many years now. I am an ex C++ programmer and there are a few things I miss from C++, but standard libraries and threading across operating systems made me switch. Java does have some disadvantages though. In general they are: slow startup, high memory usage, approximately 10% slower IO (this continues to get faster), slow trig functions (Java meets IEEE standards, but who cares). The reason Java is generally faster is the Hot Spot complier, which continues to optimize your code as it runs. Also Java memory allocation and garbage collection is much faster than C++ (go figure). Okay, most of these thing don't really matter, what matters is running fast on multiple platforms, and really fast on Linux (much faster than Windows).

Thanks for your great effort,
David
More...

I share your love for Java. If nothing else, it has provided my family a nice income for a number of years.

Java is very fast as I have argued on here myself.

However, I have run into some limitations in Java which are infuriating when you're trying to write low level, very high speed code. That has forced me to reconsider.

NOTE: We are committed to supporting Java and C#, .NET for the higher level stuff like you're own trading rules.

sizeof(). Did you realize that it's impossible to find out the exact number of bytes in a Java class? That's no such equivalent to sizeof() in C++ and C#.

There is some rough experimentation you can do like allocate a bunch of objects and manually measure the amount of memory divided by the number of objects to get an idea of the size but it does not equal the size of the members.

Also, I have found that using "pointers" are necessary for very high speed memory manipulation and faster at moving bytes around. Java has zero ability to do that. Also, structs give far better performance in certain cases that classes.

So I have been forced to face a hard reality. What we're writing here in TickZOOM needs to run at the same level as the compilers that convert byte code to machine code. In other words, low level--high speed code.

And those byte compilers are not written in Java, obviously. They're written in C or C++.

While it's true that, C# has these features and therefor can be extremely fast, it nevertheless is a real hassle the lack of platform independence. Why?

Well, everyone says, "run mono on Linux". But did you know that mono only runs C# version 2.0 at this moment?

I was using C# 3.5 to build TickZOOM which means it wouldn't run on mono. Last week, I reverted back to 2.0 and that forced changing some minor stuff.

But, isn't it a little bit annoying that Microsoft won't support Linux for .NET? So the open source community will always be behind the C# versions.

Another amazing thing has happened. I have been reviewing C++ again to get up-to-date and have found a number of surprising things.

Which only makes sense because it has been over 10 years since I worked with C++.

They now have (I never noticed) full Eclipse integration for GNU.

They have STL (standard template library) and many other standard libraries as part of the GNU project.

Also, the GNU compiler "cross compiles". That means unlike the old days, you can compile code that will run on a variety of servers without even having those servers around! And everyone reports (including vendors like IBM and Sun) that it works reliably and therefore is often better to use than their own proprietary compilers.

That solves the cross platform issue nicely, doesn't it?

Here's the BIG discovery for me at least, C++ now has garbage collection. Wow. That makes it much easier to never worry about missing free() calls.

In short, it has become obvious that C++ is the right choice long term for the low level code in the Engine.

HOWEVER, please don't worry about that because C++ operates with Java and C# nicely. (Obviously, those byte compilers are written in C++.)

So you can still write your trading models in Java but the engine will convert to C++.

NOTE: We have adopted the term "model" instead of "strategies and indicators".

Well, again, the most critical need is supporting the various languages for the high level programming of your trading rule models.

Sincerely,
Wayne
 
Quote from Fractals 'R Us:

That all sounds good to me Wayne. You are focusing on the design, it's the only way to get good software, lots of effort up front in the design phase and the rest will fall into place nicely.

I'm with IB currently.

I'll provide beta tester feedback.
More...

I missed your post originally. Thanks for the vote of confidence.

I got the API fully complete and regression tested. So I'll spend this evening and tomorrow writing comments for very interface and field. That's the kind that will come up on tool tips also while writing in the editor.

FYI, one painful thing I had to do was convert all the datetime usage. The one in the .NET library is immutable so it always allocates a new object every time you do anything as simple as add one second to it.

The other pain was that I couldn't find any way to alter the local time zone for .NET than to change the setting for the entire PC! Maybe I'm wrong about this but I tried very hard.

Plus it takes up over 20 or 30 bytes of memory each.

Anyway, we're now using an OLE type date in a struct so it only takes 8 bytes.

Unfortunately, it doesn't have any kind of time zone at the moment.

TickZOOM will standardize of course around the UTC time for ticks themselves.

But it will be nice to have some way of setting the local times. But that can be a little later.

Plus I was forced to convert that because I had snagged the code for the Microsoft datetime and modified it. That obviously is closed source. So I had to eliminate it. Isn't closed source a pain?

Anyway, that took up my weekend.

I'm in the home stretch now to document the API, refactor and document the startup API, refactor and document the Optimization API.

And that should do it.

I have to some code to a programmer who wants to work on a IB interface. I can do that now too since I have changed the date type.

Sincerely,
Wayne
 
Quote from babs2000:

Here is a another file system database (directory trees):
TREE Data Server http://tree.sourceforge.net/

The TREE Data Server captures real-time financial data from one or several datafeed services, archives data in a historical database, and makes both live and archived data available to client applications. The system can be used in real-time charting, an ATS, tick feed simulator, etc. or any situation in which multiple clients need real-time access to the tick stream or archived tick data. In addition, the archived tick stream and tick data are available for offline data analysis and backtesting.
In the current distribution a subset of the TREE Data Server collection of applications(C/C++) has been updated to support the following platforms and datafeed:

Platforms(32-bit):
Linux x86 (Ubuntu 7.10)
MacOSX PPC (10.4.11)
Windows XPSP2 x86 (MINGW port see tree/doc/ib.notes)

Datafeed: Real-time tick(snapshot) data from Interactive Brokers TWS API
More...

This project looks very interesting.

Many good things. In C++, handles interactive brokers.

There's another item here that merits discussion.

TREE also defined a "standard symbol" set.

Unfortunately, right now, all the data vendors use different symbols for financial instruments.

That's very inconvenient.

One of the powerful forces at work in open source is "standardization". It has happened already in other industries that open source communities define a standard. Then even vendors adopted them as standard.

Without reviewing it in detail yet, I propose that we adopt the TREE standard for instrument symbols in TickZOOM.

It's obvious they put a lot of thought into this. That will provide some momentum to that symbol standard.

Anyone agree or disagree?

Sincerely,
Wayne
 
Status
Not open for further replies.
Back
Top