2006 Dec 05 - Tue

Finding Local Peaks in Quote/Trade Streams

Just about any book on technical analysis you open will have a number of charts showing the usual peaks and valleys of a instrument's trading range. Many trading strategies are designed around the specific arrangement of peaks and valleys. I thought, up till now, that these peaks and valleys could only be determined through studies through the use of the good old Mark I Eyeball.

However, after reading Bollinger's book entitled Bollinger on Bollinger Bands, in which he discusses computer aided determination of those peaks and valleys, I set out to work on an algorithm to do the same.

The C# PeakMatch Code Segment is my first attempt at peak and valley pattern matching.

It is implemented as a state machine in order to make it easy to determine, during live streams, whether the stream is going up or down. You can use various summary statistics from quotes, trades, or even bars as input values.

The variable dblPatternDelta is the grey zone used for determining when the pattern flips. This variable will need to be adjusted on an instrument by instrument basis. In addition, further tuning is necessary if you wish to capture small nuances or just large swings in the trading value. As such, determining the peak is a problem of lag. Sigh, so much for having a magical realtime signal for determining when the top or bottom of a range. The variable dtPatternPt1 holds the DateTime of the last determined peak. When a change of direction of determined, then that peak/valley attribute is stored in dsPattern.

dsPattern can then be used within a sliding window of pattern analysis. I'll show an implementation of Arthur Merrill's patterns in another article.

Further information on choosing a good value for dblPatternDelta can be found in Bollinger's book.

[/Trading/SmartQuant/Articles] permanent link

Google Webmaster Tools

I cover a number of different topics in my blog. I'm interested in finding out how people arrive on those pages. From a Google perspective, they have a convenient tool for analyzing some of this information.

Google has a site called Google Webmaster Central. On that page is a link for Webmaster Tools (including Sitemaps). I've added my web site to the tool. As part of that process, they generate a verification key. I've installed the verification key in the footer file that gets included on all generated webpages on my site. This verification key is part of a script that talks to Google each time a web page is rendered by a web browser.

As part of each rendering, information is sent to Google that logs the queries used to get to the specific page. Google summarizes this information and reports this to me each time I visit the Google Webmaster Tools.

I've also uploaded a simple site-map so Google knows which pages to visit.

Now that I've provided some basic information to Google, I can now get an idea of how pages are crawled, when they are crawled, and how the pages are ranked within Google's system.

I also have the ability to download a spreadsheet of queries Google has recorded for reaching each page set. This will help me to optimize the keywords in each document. It also gives me an idea of people's interests, and thereby provide additional content focussed to those topics of interest.

I have a Google search tool at the top of my pages. The searches entered in that box are also recorded so I can tell for what people are searching once they reach my site.

There is also a set of index statistics provided which include: the pages indexed by Google, sites that Google knows that link to my site, and presents a list of sites related to my site so I can have an idea of who my competition might be.

I've found the Google 'link:' not quite as detailed as I think it should be. Google has maybe twelve sites showing information for link:www.oneunified.net. On the other hand, Alexa shows around 74 sites linking.

Anyway, for a high level view of what GoogleBot thinks about my site, Google Webmaster Central provides a good summary.

[/Personal/SoftwareDevelopment/HTML/Findability] permanent link

NTP for Callmanager

Since Cisco generally recommends that the Callmanager server not be a member of an Active Directory domain, is is unable to make use of the time distribution protocols normally available to member servers and computers. As background, I think Cisco's stance is understandable, and reflects the quantity of testing Cisco performs with each upgrade and service pack install. If a server is a member of a domain, it is entirely possible that registry entries, dlls, or applications coulds be modified through Group Policies that may affect the reliable functioning of the phone server.

As an alternative to Microsoft's time distribution protocol, the industry standard NTP (Network Time Protocol) can be used. The Callmanager installation automatically installs an NTP client, but does not turn it on.

To turn it on is quite simple. Obtain an address of an NTP server, either on your network or an external one. Using the one that drives the Active Directory domain controllors would be best. As a last resort, an address from pool.ntp.org could be used.

Edit the file C:\WINNT\system32\drivers\etc\ntp.conf and apply the ip address to the server line. Save the file. Bring up Microsoft's Services management application. Set the Network Time Protocol service to Automatic and start it up.

The Event Log will record startup and synchronization messages for your reference.

Be aware that with each Callmanager upgrade you perform, the service may be turned back to Manual and the ntp.conf file may be overwritten. You may want to make a backup of the configuration file so you can easily re-apply after your next upgrade.

[/Cisco/Callmanager] permanent link