Monday, December 31, 2007

Beta period extended until end Jan '08

No major changes in the code, but a few cosmetic updates lately. So in order to keep version number simple, beta is extended by one month.

Beta and trial users: please update your DLL as it may crash TS when it expires, and as often with TS, your charts will just disappear from your workspaces. Make sure you back them up.

The corrected DLL will only be compiled and sent on request.

Saturday, December 15, 2007

Toolset Minor Update - Dec 15th '07

Cycle detection uses a Genetic Algorithm to find the optimal sine wave or pair of sine waves to represent price data. We have already described the difficulty in reaching an optimal solution, not only because of Shannon, but because there are too many good solutions close to the optimum (fairly flat error curve).

A possible solution is to push the G.A. a bit, but since it is a computing intensive process, i have added the following GA settings:


as well as a debug parameter to write calcs to file (which will disappear in the release version).

Please contact me to try and test this new version. Note though that it can be only of interest those having a very fast PC.

Monday, December 10, 2007

Toolset Update - Dec 10th '07

Version 1.01 of the DLL now available.

This version fixes an annoying memory leak in Cycle Detection. The cycle detection being quite processing intensive, a search depth parameter ("SD") has been added. Recent computers can tolerate a value of 5 for multiple charts. It is up to the user's discretion to set it according to the number of charts and processing capabilities.

The other major change is the new internal symbol coding, which only affects API users (The $ prefix for indices has been removed).
All EasyLanguage analysis techniques have been already amended to use the new coding. A new toolset must be imported to be compatible with the new DLL.

The new coding is as follows:
SymbolName + "." + "T" + BarType + "I" + BarInterval + "M" + Multiplier

It can be verified by displaying the EasyLanguage Output Bar (View menu):
Symbol ID: NDX.T1I60M1
NDX.T1I60M1 registered in DLL memory at index: 12
Checking idx 12: NDX.T1I60M1

This example is the registration of the NDX symbol, Type 1 (Intraday), Interval = 60 mins, and a Time Frame Multiplier of 1.

Saturday, December 1, 2007

Advanced commentary on cycle detection

All my previous articles have insisted on being cautious with detecting and analysing cycles, and this point will be reiterated implicitly as I now describe it a little further.

Detecting cycles is a process whereby one tries to fit a combination of cycles (sine waves) to a time series. All time series exhibit a certain statistical behaviour (mean, standard deviation etc), which make it stationary or not. Stationary time series are easier to analyse, but unfortunately market data generally isn't.
Stationary systems (e.g. ECG) if periodical, are likely to provide stable cycles, therefore sampling the last 128 points should in such case capture all replicable cycles with higher frequencies (periods below 64 points). There is ample literature available on the Internet (Cycle detection, Shannon. etc), so i'm going to leave this topic aside.

In our case, there is no reason to believe cycles will repeat themselves. Life would be just too simple. No, market data can hardly ever be summed up in a combination of sine curves. Sorry to disappoint you if you spent money on books and seminars offered by some shrewd market guru. I might elaborate on the topic of selling hot air in a future article.

OK, back to the nitty gritty: let's live with it, frequencies will always change. We can take a snapshot and estimate some degree of stability in the short term with due caution. In recent weeks, we've had a cycle detection that worked just fine (admittedly also supported by other indicators), but one should not extrapolate further as this is highly sensitive to a change in market dynamics. Such sudden change in dynamics (energy bursts, pulses) will generally translate into new (also short-lived) cycles, and even when they remain relatively stable, those rapid changes (i.e. an event like a Fed announcement) generate a phase shift, which in layman's terms corresponds to the main cycles being offset backward or forward. This is a very advanced topic, that very very very few have explored or even thought of.

Let's come back to our cycle detection. We use 128 points (the indicator can use more), so we detect a number of possible cycles that fit our price series. The genetic algorithm does a good job at finding the optimal phase etc, but since there are multiple solutions close to the optimum, and since the problem at hand is discrete (i.e. not continuous), the indicator will often jump between very good solutions that are all very very close to the optimum.

It does not matter so much as this is not an exact science and cycles are generally elusive. They however can give us turning points within a few bars, which is what we really care about.

OK, let's leave the 'heavy stuff' aside for now, and let's get back to one of our standard charts, here NDX. Cycles are plotted, and the main cycles are F1 (period: 168 bars) and F2 (period: 63 bars). F1 is too long, as we cannot grab the dynamics of a long cycle with only 128 bars. We already know that there are a number of good solutions with shorter cycles. The combination of the 2 cycles provides the best fit to the price series, so we kept it that way.

The 2 cycles have have relative amplitudes of respectively 87 and 53, making the 2 cycles significant, and actually visible. One can now apply the phase shift indicator, or if we want to discard the longer cycle apply manually a quarter cycle phase advance to the shorter cycle F2 to anticipate the next potential turning point.

There will be a few improvements to that indicator soon to accommodate these functionalities. For the time being, users of the toolset are welcome to send comments and feedbacks. Thanks.