Printable View
The new 20DMF is available here.
[url]http://www.effectivevolume.com/content.php?1068-real-time[/url]
The main changes are the explanatory messages and the fact that the short signals are now confirmed by the Cumulative ticks instead of the inversed ETFs.
Pascal
[ATTACH=CONFIG]16254[/ATTACH]
[QUOTE=Pascal;23985]The new 20DMF is available here.
[url]http://www.effectivevolume.com/content.php?1068-real-time[/url]
The main changes are the explanatory messages and the fact that the short signals are now confirmed by the Cumulative ticks instead of the inversed ETFs.
Pascal
[ATTACH=CONFIG]16254[/ATTACH][/QUOTE]
Thanks for the new signals Pascal.
Do you get the Cumalative Tick from Tradestation ? If so which settings do you use ?
Trev
We get the raw data from our data supplier and calculate the Cumulative Tick and its average.
Pascal
[QUOTE=Pascal;23987]We get the raw data from our data supplier and calculate the Cumulative Tick and its average.
Pascal[/QUOTE]
Your charts have stuck at 11:50 US time ? At quite a critical spot I think !
Trev
Yes. The system froze when it issued the short signal.
I think that this is a Java bug.
We are working on it.
Pascal
Pascal,
The current message states "buy when OBOS crosses over 30".
Shouldn't that be [COLOR="red"][B]-[/B][/COLOR]30?
When we are in Short mode and cross below -30, a forced buy is executed when the OB/OS returns back above +30, if the MF is still in negative at that time.
pascal
Pascal,
Are the discontinuity jumps at the open of the cum tick moving average to be believed?
Harry
There was a jump yesterday morning because we started the service at 9:40 instead of 9:30 and the price gap attracted buying for the first 10 minutes.
The Cumulative Ticks of the previous days - before the system was put on-line yesterday - is not correct as there was a calculation error that has since been corrected.
Pascal
[QUOTE=Pascal;23998]There was a jump yesterday morning because we started the service at 9:40 instead of 9:30 and the price gap attracted buying for the first 10 minutes.
The Cumulative Ticks of the previous days - before the system was put on-line yesterday - is not correct as there was a calculation error that has since been corrected.
Pascal[/QUOTE]
Is the Cumalative Tick based on The R2000, NYSE, or All US ?
Also, the current graph does not show the CumTick passing down through the 600min. Why is this please ?
Thanks in advance.
Trev
It is only the NYSE Tick.
The graph does not show that the Tick came below its average, because when it crossed below, the system froze due to a bug and then restarted later when the Cumulative Tick was above its average again.
The real pattern is shown below
Pascal
[ATTACH=CONFIG]16267[/ATTACH]
[QUOTE=Pascal;24000]It is only the NYSE Tick.
The graph does not show that the Tick came below its average, because when it crossed below, the system froze due to a bug and then restarted later when the Cumulative Tick was above its average again.
The real pattern is shown below
Pascal
[ATTACH=CONFIG]16267[/ATTACH][/QUOTE]
Thanks Pascal.
I watch the 600min NYSE ($TICK1 min) on Tradestation = xaverage(cum(c). 600)
This has been trending down since about 11am yesterday. Why the decrepancy do you think ?
Trev
I do not use TS. So I cannot comment.
However, we can note that the Cumulative Tick has had moves similar to IWM, which follows 2000 small size stocks.
IWM has been reluctant to go down.
Pascal
[QUOTE=Pascal;24003]I do not use TS. So I cannot comment.
However, we can note that the Cumulative Tick has had moves similar to IWM, which follows 2000 small size stocks.
IWM has been reluctant to go down.
Pascal[/QUOTE]
Pascal,
I do not want to belabour this point but it may be important in the long term.
I watch the following Tick Charts on Tradestation :-
$TIKRL = Russell 2000 Tick
$TICK1 = NYSE Tick
$TIKUSC = All US Tick Comp
At this moment in time all the 600 minute (xaverage(cum(c). 600) averages are trending down. Your RT graphed 600 min Average Cumalative Tick is trending up.
Something is obviously wrong . How sure are you that your data provider is correct ? (I am not saying my figures are correct but I think this observation needs checking as this is an imprtant element of the new 20 DMF RT).
Trev
$TIKQ and $TIKUSC 600min is moving up this morning (on TS) if you use average instead of xaverage. I find Pascal's cum tick is a lot similar to $TIKUSC than to $TICK based on last couple of days' chart.
PS, I tried both average and xaverage, seems the difference is very similar and charts look similar
I understand the issue.
It is more probably due to data sampling of one minute compared to faster data sampling that TS uses.
We use one minute mainly because it is the only format that allows access to 5 years of back data... and we need to use the same data on the system that was used for the backtest.
In other words, we could display a CTick similar to Tradestation, but then it could not be comparable to what was used in the back-test.
I will come back to this discussion on Monday next week, as I am abroad now with limited resources in terms of time and calculation power.
Pascal
To come back to this discussion, i would like first to remind what the Cumulative Tick is:
"The NYSE tick is the number of stocks whose current price is higher than the previous trade (uptick) minus the number whose current price is lower than the previous trade (downtick). This takes the entire NYSE Market into account."
This means that the NYSE Tick changes every millisecond or less. It is therefore a "snapshot" picture taken at a certain time. If between two snapshot pictures, 15 stocks had an uptick and 10 had a downtick, the different is +5. The cumulative tick would simply add this number every time a snapshot picture is taken.
When such snapshots are taken at intervals of 5 seconds, there will of course be more moves (higher numbers) than for snapshots taken every 0.001 second. However, within 5 seconds, many stocks can have upticks AND downticks. What we measure is simply the different for each stock (Up - Downticks.) This means that snapshots that are taken at longer time interval will produce lower figures of cumulative ticks.
For our back-tests, we have used the IQ feed historical minute based cumulative tick. This Minute based cumulative tick is slower than a cumulative tick that would take snapshots every five seconds.
We could of course switch to a faster cumulative tick, but the back-test is based on the minute Cumulative tick and no other data is available for the purpose of back-testing.
Therefore, we will simply keep the current cumulative tick, but rename it the "Minute based Cumulative Tick."
[B][U]Moving to 1200 Cumulative Tick average[/U][/B]
However, thanks to this discussion, we had an in depth review of our calculations of the 600 Minutes average. We discovered that the JAVA based calculation led to different figures compared to the historical calculation for the average figure that I performed for my back-tests in VB. This led us to discover that the back-test has been performed using single precision variables instead of a double precision. This means that the 600 minutes average calculated using single precision variables was slower to move than it should normally have been if we had used double precision variables.
As a consequence, a new back-test was executed using double precision variables. This back-test was performed using a set-up period between July 2007 and end of 2009, and a control period between 2010 and the end of 2012. This back-test showed that the 600 CT had to be replaced by a 1200 minutes average CT.
As a reminder, the CT will be used in the RT 20DMF as a confirmation tool for short signals only. A 1200 Average CT means that the CT will need to show on average three days of weakness in order to confirm a short signal (390 * 3 = 1170.) Below is an example of the 600 and 1200 Minutes average CT
[ATTACH=CONFIG]16325[/ATTACH]
I attach an excel sheet that includes the new 20DMF RT back-test results on EOD and RT data.
The RT data are only valid from June 2009.
[ATTACH]16328[/ATTACH]
The comparative return table is shown below. The RT system clearly shows out-performance for both long and short trades.
[ATTACH=CONFIG]16327[/ATTACH]
[QUOTE=Pascal;24062]To come back to this discussion, i would like first to remind what the Cumulative Tick is:
"The NYSE tick is the number of stocks whose current price is higher than the previous trade (uptick) minus the number whose current price is lower than the previous trade (downtick). This takes the entire NYSE Market into account."
This means that the NYSE Tick changes every millisecond or less. It is therefore a "snapshot" picture taken at a certain time. If between two snapshot pictures, 15 stocks had an uptick and 10 had a downtick, the different is +5. The cumulative tick would simply add this number every time a snapshot picture is taken.
When such snapshots are taken at intervals of 5 seconds, there will of course be more moves (higher numbers) than for snapshots taken every 0.001 second. However, within 5 seconds, many stocks can have upticks AND downticks. What we measure is simply the different for each stock (Up - Downticks.) This means that snapshots that are taken at longer time interval will produce lower figures of cumulative ticks.
For our back-tests, we have used the IQ feed historical minute based cumulative tick. This Minute based cumulative tick is slower than a cumulative tick that would take snapshots every five seconds.
We could of course switch to a faster cumulative tick, but the back-test is based on the minute Cumulative tick and no other data is available for the purpose of back-testing.
Therefore, we will simply keep the current cumulative tick, but rename it the "Minute based Cumulative Tick."
[B][U]Moving to 1200 Cumulative Tick average[/U][/B]
However, thanks to this discussion, we had an in depth review of our calculations of the 600 Minutes average. We discovered that the JAVA based calculation led to different figures compared to the historical calculation for the average figure that I performed for my back-tests in VB. This led us to discover that the back-test has been performed using single precision variables instead of a double precision. This means that the 600 minutes average calculated using single precision variables was slower to move than it should normally have been if we had used double precision variables.
As a consequence, a new back-test was executed using double precision variables. This back-test was performed using a set-up period between July 2007 and end of 2009, and a control period between 2010 and the end of 2012. This back-test showed that the 600 CT had to be replaced by a 1200 minutes average CT.
As a reminder, the CT will be used in the RT 20DMF as a confirmation tool for short signals only. A 1200 Average CT means that the CT will need to show on average three days of weakness in order to confirm a short signal (390 * 3 = 1170.) Below is an example of the 600 and 1200 Minutes average CT
[ATTACH=CONFIG]16325[/ATTACH]
I attach an excel sheet that includes the new 20DMF RT back-test results on EOD and RT data.
The RT data are only valid from June 2009.
[ATTACH]16328[/ATTACH]
The comparative return table is shown below. The RT system clearly shows out-performance for both long and short trades.
[ATTACH=CONFIG]16327[/ATTACH][/QUOTE]
Thanks very much Pascal for your comprehensive tests.
Trev