UI design

Some of the time during last week I've dedicated to the DTW related research and UI design: I was thinking about laying out the workspace for the DTW analysis since after all it suppose to be somehow interactive and iterative. It's very important that UI must be responsive and keep user focused on the analysis aspects. By following the UI-First Software Development principle I've spend about 10-20 minutes just drawing the draft of UI laying out information blocks and parameters at the left screen "control panel".
.
The function which is underlying under UI design is pretty simple, and I outlined three major steps on my drawing:

1. User sees the input time-series statistics and two accompanying plots: one for the raw timeseries data with gaps and non-normalized peaks representing the data collected from the sensors and second one, with normalized series and gaps filled accordingly to the telemetry type.


2. Based on the provided information and visualization user selects specific DTW options and actually fires the timeseries alignment action.


3. Once trajectories aligned, the third plot showing aligned warped timeseries and alignment statistics updated. After evaluating analysis results user makes a decision to alter parameters and run alignment again or just accepts the alignment results.

Currently I'm altering the Wicket application code, HTMLs and CSS styles to implement the UI.

Some issues with DTW I'm working on.

In couple of previous posts (except one about precision) I was discussing two issues in pattern matching which are apparently similar in the speech recognition (utterance matching) and in the software metrics matching analysis. I read the article by
Rabiner, L.; Rosenberg, A.; Levinson, S., "Considerations in dynamic time warping algorithms for discrete word recognition," Acoustics, Speech and Signal Processing, IEEE Transactions on , vol.26, no.6, pp. 575-582, Dec 1978 and trying to rephrase the reasoning applying it to the software metrics alignment.

• Most recently discussed issue: the assumption that the telemetry time series should be the same length. In my opinion this constraint is very strong and we should not consider this in the most cases. Whether or not waterfall or agile processes are considered there are certain activity patterns (phases) already identified. What is not canonized is the length of each of the phases and we should be considering an "open-ended" alignment algorithm to match those process features.


• The second issue discussed before is the allowable changes in the warping function. By adjusting this allowances we basically adjusting the sensitivity of the algorithm to recognize peaks of activities as the independent events. Question is what is the range of optimal allowances?


• The last issue I was thinking of is whether or not there are some hidden preferences in the choice of the "query" or "template" time series. So far I would say that there are no difference, but I would work on the experimental proof that the warping function is symmetric (or not?).

While researching, I discovered this book, which potentially is the greatest answers source for my questions. Readings in Speech Recognition By Alex Waibel, Kai-Fu Lee

I've seen the following figure in the article and in the book and it seems to be illustrating two first questions I am asking here: first two plots are illustrating the effect of allowances in the warping function, while the third plot (UELM) illustrates the "open-ended alignment" approach.

Open-ended alignment.

So... precision errors... Once I've made through this I hit another bump: in my previous tests I was always comparing time-series of the exact same length, 15 days. Meanwhile the Trajectory interface allows you to select time series of arbitrary length and moreover to introduce indent before data, which more likely makes time-series lengths different. :). For example like this:



What would happen once I'll hit the Do DTW Analysis button? Right - Exception, due to the difference in length.



While I can restrict users to do only the same length time-series analysis, it is very strong constraints. It would require huge amount of the eye-matching before actually going into the DTW. ...

To be continued later today.

Precision errors....

If you were following my posts you might have noticed that there is significant difference in the appearance of the plots after DTW between the R implementation and my Java implementation. It was a point of my frustration for the couple of weeks. I spent hours trying to extract the underlying numbers and debug what is going on. Guess what? Precision errors contribute to that.

Example: how DTW works 3 peaks and 2 peaks.

A simple example of DTW algorithm for two trajectories, one has three peaks, while the second one two peaks. In my opinion two trajectories are distinct enough to consider them non-similar: clearly, trajectory #1 has two minor activity peaks by sides of major activity peak while trajectory #2 has two similar peaks of activity during the time trajectory #1 is idle. The task of this exercise is to explore the DTW toolkit which prevents this trajectories from aligning. In particular, I'd like to try the Sakoe-Chuba Band and Itakura Parallelogram as shown at Figure 4 of Salvador, Stan and Philip Chan. FastDTW: Toward Accurate Dynamic Time Warping in Linear Time and Space, Intelligent Data Analysis, 2007

The original data plotted

Time series

Naive DTW DP in action

Before and After DTW

My Java DTW implementation finally works within the ProjectBrowser

During last week I've fixed my DTW Algorithm implementation in Java. Next two screenshots are showing the reference R implementation at the left side and my Java implementation at the right side. They both happened to be identical before DTW and after DTW.





And the immediate effect on the Trajectory tool visualization:

Placeholder for the Monday, September, 22

Basically it's about 10:32PM (MST) and I am late with posting my entry. Just found why my DTW implementation doesn't follows the reference one: I was not averaging points which were merged during the DTW along with NOT interpolating ones which happen at gaps. The bug is understood, but I am not feeling like patching it right now: it requires writing tests and altering some code. Will update this blog entry tomorrow. Meanwhile I went through the "spaghetti code" sections and some telemetry artifacts remaining in my code and cleaned it up, however I think that the sequence of events to get three plots as in the previous entry is still far from the perfect. Also I am working on the DTW panels UI and cleaned up the streams statistics from some junk along with introducing a little DTW statistics panel. See you a little later :).