wk1984 / ccf-homogenization Goto Github PK

Following the initial call to splitmerge in ucpmonthly, the Fortran code 
executes a segment of code which finds changepoints which are within (parameter 
minlen) months of each other and runs some tests to try to consolidate them 
into a single changepoint (typically the earliest one or the one which 
minimizes its BIC).

This process needs to be implemented in mw2009.splitmerge.

Again in chgptmodel.kendalltheill(), there is a bug on line 2339. Starting 
here, we over-write the medians we found in both lists, and use the second  
segment for all our computations! I reproduce that behavior here by using the 
generic range_med and data_med values for rXmed and rYmed. This needs to be 
fixed by computing residuals in each segment with respect to the median from 
that segment.

Change documentation to describe process more than anything else.

Another instance where we do not handle the case of an even number of values 
when computing the median, top of KTHTPR1

MW2009 code in chgptmodels.kendallthiell, line 2229 starts the 'j' index at 
ibeg2+1. This corresponds to 1 here. Above in the firstsegment and in 
kth_line(), it starts the 'j' index right where 'i' left off.

Need to replace print statements throughout mw2009 with a logging functionality.

"...in the kendallthiel() subroutine. I hadn't thought about this earlier, but 
in the portion you comment "remove missing data from incoming arrays", we have 
a big question - is this right? In a nutshell, you strip out all the missing 
values in rYdata and generate a set of predictor values which is ultimately the 
order of the good Y data as it was encountered. For example ->

rXdata = [1,2,3,4,5,6]
rYdata = [10,-9999,-9999,-9999,-9999,4]

becomes, with your method

rX = [1,2]
rY = [10,4]

This example is constructed to be particularly egregious and illustrate a point 
Nick made. Computing the slope between (1,10) and (2,4) is very different than 
the one between (1,10) and (6, 4). Should we be preserving the spacing between 
Y values or do we really intend to consider the good values equally spaced and 
*totally* ignore the missing values?

As a point of interest, in kthline() you do something very different - you 
effectively find pairs of valid x and y values, so our example above becomes

rX = [1,6]
rY = [10,4]"

Another instance where we do not handle the case of an even number of values 
when computing the median; KTHTPR1

In splitmerge, when a null domain is detected (changepoints which have 
amplitude changes of opposite signs), the x,y data between interim changepoints 
is supposed to be totally removed. Write now, the removal is accomplsihed for 
re-computing the test statistics at the target earliest interim changepoint, 
but the reference to the original seg_x and seg_data remains clean.

This can only be fixed by re-engineering how seg_x and seg_data is computed. 
Version .2 of code or major splitmerge re-write.