How to create a debounce filter using timestamps

I'm creating filters to work on boolean timeseries data. We are talking about simple true or false values that switch over time. The data is many tens of thousands of elements long, but we only get "sparse" switching events, i.e. we don't see true change to false very often over time.

So I thought, how about I keep just the timestamps and process those, so I go from 10s of thousands of points per run, to just, say, 7.

Along the way I've created a debounce filter and come across a concerning result for debouncedTimeOn that I can't explain. For the full function (quite short, approx 4x the snippet below) and the inputs I used, see the attached files.

if isEven && ~onFirst
    % FFF
    % NNN
    % kkk
    keepDips = timeOn - timeOff > debounce;
    
    % FFF
    %  NNN
    % kkkk
    keepPeaks = cat(1, [1], timeOff(2:end) - timeOn(1:end-1) > debounce, [endTime - timeOn(end) > debounce]);
    debouncedTimeOn = timeOn(keepPeaks(1:end-1) & keepDips); %"Corrected" this but have no idea why not keepPeaks(2:end) & keepDips.
    debouncedTimeOff = timeOff(keepPeaks(1:end-1) & keepDips);
    return;
end

As you see, I'm keeping only on-times and off-times that are sufficiently spaced apart, and throwing away the rest. When I run this code, I get exactly the result I want, but probably for the wrong reasons. I had to change this line to get this result.

debouncedTimeOn = timeOn(keepPeaks(1:end-1) & keepDips); % What it is now
debouncedTimeOn = timeOn(keepPeaks(2:end) & keepDips); % What I think it should be. But doing it this way, the output cuts out too many on times, and results in an on-on, off-off result that makes no sense.

If any of you have explanations why this line should not be changed, that would be very helpful. Also, if you have any other comments about my general approach writing these filters myself. I have the DSP Toolbox, but haven't used it for this problem, because I figured writing filters this way I'd be able get faster performance, for this specific case where the switching signals are spread out sparsely over time. Plus I haven't really used the DSP Toolbox before, and it seemed like it wasn't suited for this kind of input data. Happy to take any suggestions.

[Ben Mahler]

BTW I forgot to explain the timeOn and timeOff data format. It is a modified posix epoch in seconds, with two variations due to us sending this data to imc FAMOS later. 1) the Epoch starts January 1, 1980 for FAMOS, not 1970 as in posix. 2) The times are not integers, because famos takes a float in seconds, so we have a decimal point to allow for milliseconds.

Answer 1

[Ben Mahler]

I've found the solution. MATLAB was implicitly converting timeOn (double) and timeOff (double) to integers on line 47 when concatenating with endTime (int). This was actually throwing all the times off and it was just a fluke that making the change on line 48 appeared to "fix" the problem.

This is just another reason why it's important to understand how your answer is being calculated, even if the output "looks" right. Also a reason why I'm a big fan of static typing over implicit conversion.