I'm curious. Do you mean a static or dynamic currency calculation? Static is much easier of course. To clarify, if you perform a 5 year portfolios of securities in different currencies, are you okay with a static exchange rate? I assume you would prefer a dynamic exchange rate meaning that the conversion rate will very during those 5 years and directly impact your equity curve. In a portfolio like that it might make sense for your strategy to also play the "currencies" in the sense of somehow hedging changes in currencies. In other words, even if you own a stock (like a US stock) over a period that goes up 30% but the currency (US dollar) drops by 40% during that same time, then you lost value. Personally, I wish options on currencies were more accessible so as to hedge against significant currency changes. But I haven't figured out how to use forex options or where you can do so unless you have an institutional sized account. Just some ramblings. Sincerely, Wayne
I agree that hedging the currency exposure when trading in assets denominated in a foreign currency is a reasonable thing to do. Yes, i would prefer what you call a 'dynamic' exchange rate. Suppose you trade a portfolio of american and european stocks. On one hand TZ does a very accurate simulation of every tick but on the other hand it looses much of its precision when calculating the actual PnL - if you use a static exchange-rate (your european PnL would be off by a factor between 1 and 1.6 in the last 5 years). The way it should work in my opinion is that you can define a currency for each instrument (and in the case of a FX pair both the base- and the quote-currency) and the PnL should settle immediately in the account base currency (mine would be EUR) - using the then prevailing conversion rate. I think every product that advertises portfolio capability should be able to deal with this - yet all software i am aware of fails in that aspect miserably.
Pippi, every effort has been made in TickZOOM to separate the "engine" logic from the rest of the system which includes custom trading rules, performance stats, optimization algorithm, graphical interface, etc. The engine focuses on the complex and job of converting ticks into bars at high speed and calling out to your custom trading models at the intervals they request. In other words, all the complexity of the high speed is hidden from those parts of the system and self contained in the engine. So going even beyond the benefits of open source, it also means you can add formulas (like conversion) etc. into those parts of the system. What you describe sounds like a perform thing to start as part of a community set of functions available. The reason I asked if you want dynamic or static is because the engine will need to add the ability to handle multiple instruments simultaneously. That will be a minor enhancements since architecturally it can handle this. It just needs some minor modifications and then plenty of testing and regression testing. NOTE: I'm curious as on optimization do you need a "per tick" adjustment of the currency? I think you alluded to some less granular like per minute? per hour? per day? The reason is that add a few currency instruments to your stock tick data will impact your performance in historical testing. It might make sense to only use 1 hour bars for exchange rate, for example which would greatly improve performance. Those type of adjustments would involve a little work in the engine to make it all work seamlessly. But the actual calculations would still occur outside the engine in custom or common code. Wayne
Hi, for my personal purposes even daily fixings would be good enough - the results should just not be off by a factor of 1.6 or a similar order of magnitude. Maybe a super high frequency model requires more precise conversions. In my opinion the correct calculation of pnl is a core functionality of simulation software, but if you say that can be added by a user without turning the bowels inside out that's perfectly ok. Its an open source project after all.
Right, it already calculates profit and equity. I even usually graph it on my chart with it green filled so I can see the run-up draw-downs, etc. If this is critical to you right away and you have the daily currency data somewhere, you can (if you program) rather easily load it all into memory since daily data takes very little space. Then you could easily insert a few lines in the equity to access it when calculating the equity curve and use the right one per instrument, etc. It would be kind of "hardcoded". If you actually figured out or communicated with me to plan the right places to add it into TickZOOM in a "wholistic" way so others could use it too, that would qualify you for bonuses, rewards, etc. as a code contributor. Wayne
Speaking of contribution. The TickZOOM Contributor Agreement is now available for download as PDF. Anyone who would like access to commit changes to the code needs to download and sign this agreement. Go to www.tickzoom.org/wiki/TickZoom/Contributors Or click CLA on the left menu. Background: Legal advice was to use a well-known CLA and so the Sun CLA was chosen. The Sun CLA (SCA) works well because the contributor keeps ownership and it makes sure the contribution is always available as source code so that it never becomes closed source. Also, it protects the code base and users from any problems with copyright or patent laws. There is one modification we made to remind contributors to request their reward or bonuses for contributions which may include perpetual free use, support and service for significant contributions. You can download or read the FAQ (linked to Sun site) on the benefits again at www.tickzoom.org/wiki/TickZoom/Contributors The software license itself will be posted tomorrow evening. All these are final preparations for releasing the code!!! All the final preparations should be finished within the next few days. Remember, this will be an alpha release. It's major issue will be sparse documentation. So we'll work on that as the priority to get to the Beta test phase. Sincerely, Wayne
I have been a long-time TradeStation user. Mostly for charts and fast prototyping. But, execution leaves much to be desired. I have begun converting to Ninja with good success (nice development platform). However, I don't see Ninja as the ultimate BlackBox architecture given it's dependency on Windows/UI. I need something that I can run on remote servers 24x7 and can control from a monitor program that gives me real-time updates on profit/loss/progress. Anyway, TickZoom sounds promising. Please let me know when a general release becomes available.
Agreed 100% . Ninja is great or discretionary or even partly automated discretionary as long as you never need to use tick data. TickZOOM operates on tick data and solves all of that.
NOTE: After further legal advice, the license has been custom written to allow modifying of the source code but it disallows copying for any reason except on your own computers. So it differs from open source or free software licenses. It has become our decision that the goal is to give users the source code for developing strategies. And for developers to create add-ins or contributions. But we're not interested, at this time in allowing the software to get reused in other open source or commercial products. Furthermore, the license promotes individuals free use of the software. Businesses may use the software only for 30 days if they have more than 1 employee or more than 2 owners or members. The pricing is FREE. That's not a problem. This license has been dubbed the TickZOOM GPL. Folks, that's how it is. The license and terms may change over time but they'll always center on users having access to source but disallow "derivative" works as they're known in copyright law and differentiate between individual and business use. Sincerely, Wayne