The Fun of being Busy
This morning it's been a hectic morning - lots of things to dig into, fix, write up, explain... it's been a blast. Nothing major, but it's like a wonderful little buffet of things to keep my mind working - and in some cases, exercising my patience as well.
Athens Exchange Acting Up Again
Seems every so often the Athens exchange is acting up from Reuters. Today we didn't get the clearing of the earlyClose.flag and that meant that things were not ticking as the price was based on the earlyClose.price and not the incoming ticks. Once I cleared that up, things started working better. My favorite support guy in the price feed group is going to look into this and try and see why we missed it yet again.
Looking to Filter Ticks by Historical Data
There are problems with the data coming from the exchanges - no doubt about it, but when it comes like it did today, it's a significant pain in the rear, and there's a significant push to try and find a solution for this problem. Today there was an option that was sending a quote (bid/ask) of 0.3/1.2 - creating a price of 0.75. Then a quote of 0/150 would come in making the price 150. One of these is clearly wrong, but is there an objective way to determine that? Not really.
We need to somehow look at the historical data for this instrument and determine if it's correct or not. If the last n ticks have averaged 0.75 with a tight grouping, then the 150 is bad. But it's also possible that the reverse is true. We need to look at the data in a larger sense. However, this isn't easy. The rules you start to make are hard to pin down with any accuracy. You end up making artificial judgements (limits) like 200%, and such. It's not logical, it's experimental.
So I sent out an email asking if now is the time to look at this - or do we want to put this off for later. It's going to take some time as the prices coming from some exchanges are not always clear and complete. Some have CLOSE, for instance, some do not. So we have to make complex rules for all this. And then there's the training process. It's not easy... or quick. It's going to take some time.
So we'll see if this is that time.
Fixed a Few Bugs
Hey... everyone makes mistakes, and this morning I had to fix up a few of mine. This was my gotcha based on the fact that some fields were not getting populated consistently. I had to make special cases for the different ways they got populated, and that fixed the problem. Shucks.
Worked Around Changed Behavior in VantagePoint
In the BKTimeSeriesViewer, the init() method was blowing up with an exception in the hiding of the non-existant points on the graph. It turns out that in the latest cut of VantagePoint, the method getVariables() will return a null of there's nothing on the graph to show. In the past, it returned an empty int[]. This null was caught and we had the problem. So... what was the solution?
Turns out it's pretty simple - allow the null. The method getColumnsOnGraphOnSecondaryY() in the BKBaseGraph was the problem, and if we model it after VantagePoint, then it's simple to say that if there is a null returned from getColumnsOnGraph() (as it calls the VantagePoint method), then it's reasonable to return that from getColumnsOnGraphOnSecondaryY() as well. The rest of the code handles it nicely, so it was a simple change.
Gave this to the developers asking for it and all was well.