In my expirience D&C doesnt have accurate estimate.... it decreases exponentialy. at least for me
On Aug 4, 6:57 pm, MKoistinen <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
