Gosh, i can see why you wanted this.  I'm trying a proper "window"
method now, and it easily takes 10X the optimization time, maybe even
100X.  I'm doing a D&C (max) and its telling me it needs 2 days.

When are we going to get those quantum computing extentsions ? :)

On Aug 4, 5:57 pm, Eugene Kononov <[email protected]> wrote:
> Yep, that's what I am doing, optimizing the period.
>
> On Tue, Aug 4, 2009 at 12:55 PM, Martin Koistinen <[email protected]>wrote:
>
> > Sure thing.  What period are you using for the weighted version?  That
> > looks a pretty large number.  I think you're going to want to bring it down
> > sufficiently such that the first couple of hours of both charts look
> > similar.  Better yet, optimize the period :)
>
> > On Tue, Aug 4, 2009 at 5:44 PM, Eugene Kononov 
> > <[email protected]>wrote:
>
> >> Hmm, it does seem to do what I wanted. Thanks, Martin, much appreciated. I
> >> attached the chart that shows the effect. DepthCorrelation is the original
> >> indicated, and DepthCorrelation2 is the weighted version.
>
> >> On Tue, Aug 4, 2009 at 12:10 PM, MKoistinen <[email protected]> wrote:
>
> >>> Or more completely:
> >>> period is an input
> >>> double alpha = 2 / (period + 1);
>
> >>> ...
>
> >>>            n++;
> >>>            sumX  += alpha * (balance - sumX);
> >>>            sumXX += alpha * (balance * balance - sumXX);
> >>>            sumY  += alpha * (price - sumY);
> >>>            sumYY += alpha * (price * price - sumYY);
> >>>            sumXY += alpha * (price * balance - sumXY);
>
> >>>             if (n > period) { // wait for period minutes of data
> >>> before calculating
>
> >>>                double numerator = period * sumXY - sumX * sumY;
> >>>                double denominator = Math.sqrt(period * sumXX - sumX *
> >>> sumX) * Math.sqrt(period * sumYY - sumY * sumY);
>
> >>>                if (denominator != 0) {
> >>>                    value = 100 * (numerator / denominator);
> >>>                 }
> >>>            }
>
> >>> On Aug 4, 5:05 pm, MKoistinen <[email protected]> wrote:
> >>> > Have you tried using EMA-like processing to weight the most recent
> >>> > events higher?
>
> >>> > so
> >>> >             n++;
> >>> >             sumX += balance;
> >>> >             sumXX += (balance * balance);
> >>> >             sumY += price;
> >>> >             sumYY += (price * price);
> >>> >             sumXY += (price * balance);
>
> >>> > becomes:
> >>> >             n++;
> >>> >             sumX += alpha * (balance - sumX);
> >>> >             sumXX += alpha * (balance * balance - sumXX);
> >>> >             sumY += alpha * (price - sumY);
> >>> >             sumYY += alpha * (price * price - sumYY);
> >>> >             sumXY += alpha * (price * balance - sumXY);
>
> >>> > It seems like this should do the trick...
>
> >>> > On Aug 4, 4:22 pm, nonlinear5 <[email protected]> wrote:
>
> >>> > > I have a new indicator, called DepthPriceCorrelation. It's not in the
> >>> > > release yet, but it's in SVNhttp://
> >>> code.google.com/p/jbooktrader/source/browse/trunk/source/com/j...
>
> >>> > > The indicator is based on the idea that current price can be
> >>> > > considered "fair" when the correlation between market depth balances
> >>> > > and market prices is positive. This positive correlation occurs when:
>
> >>> > > -- high depth balances are accompanied by higher prices
> >>> > > or
> >>> > > -- low depth balances are accompanied by lower prices
>
> >>> > > When the correlation is negative, the prices are moving in the
> >>> > > direction opposite from the direction of depth balances, and I call
> >>> it
> >>> > > a "high tension" condition. This is when my strategy gets into a
> >>> > > position on the bet that the tension will ease and the correlation
> >>> > > will return to its "normal" positive value. Here is an example of
> >>> such
> >>> > > a strategy:
> >>>http://code.google.com/p/jbooktrader/source/browse/trunk/source/com/j...
>
> >>> > > Now, to calculate the correlation, the indicator simply updates the
> >>> > > running sums for prices and balances, and then uses a standard
> >>> > > correlation coefficient formula to come up with the result. This is
> >>> > > very efficient, and it works well. The problem is, sometime in the
> >>> > > second half of the trading session, the indicator becomes too
> >>> "stale",
> >>> > > because it uses all the data accumulated so far during the trading
> >>> > > session. So, at say, 2pm, the indicator would represent the
> >>> > > correlation between balances and prices based on all the data from
> >>> > > 9:30am to 2pm, while my strategy is looking for a shorter term
> >>> > > correlation, such as the last 2 hours. It's certainly possible to
> >>> > > recalculate the indicator based on this 2-hour moving window, but it
> >>> > > would be very computationally expensive, since every time, I would
> >>> > > need to loop through the last two hours of values, instead of simply
> >>> > > updating the running sums.
>
> >>> > > So, here is the question for the algorithmically inclined. How do I
> >>> > > *efficiently* calculate the correlation between X and Y in a moving
> >>> > > time window?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"JBookTrader" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/jbooktrader?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to