Documentation of aggregation methods would be nice


Let me take another stab? If there was some possible universe in which I could get the comments for my aggday, I would have a good use for it.

My new Beelint goal is trying to track the number of goals that are in violation each day, and currently uses min to not fault you for violations that come up during the day. Sort of like how Gmail Zero works.

The problem is that I might go from A,B to B,C and it looks like those are both size 2, but C is new and shouldn’t be counted. I’d like to just count the problems that have been present ALL day. So what I’d really like is an aggday that looks like

lambda comments: len(set.intersection(*[set(c.split(',') if c else set()) for c in comments]))

If there’s no hope I can print/read a state file but I was hoping to keep my thingy stateless. :slight_smile:


skatesum : min(rfin, np.sum(x)), # only count the daily min

Can someone explain this one? What is rfin?


Per a daily beemail by @dreev

Thanks to user kyshoc for suggesting a new aggday method that turned out to be super easy to add to the list. I’m not sure I agree it’s a good idea but here’s the use case:

Auto-ratcheting (setting “max safe days”) to never let you accumulate safety buffer only prevents you from getting whole days off. Even set to zero, it still let’s you almost get a day off, like having just one more step to get the next day. This new aggday method prevents you from getting more safety buffer at all (than you already have). Like if your road is set to 100/day then anything more than 100 that you report for a day just doesn’t get plotted.

It’s kind of like using a binary goal of “did it or not” but letting you store the richer data about how much exactly you did. The reason I don’t like it is that the graph is not plotting your actual data. But I’ll be interested to hear if anyone else likes it.

It’s called skatesum because it’s used for auto-summing goals like do-more where all datapoints for a day are summed and the cumulative total is plotted, but then that daily sum is capped at the daily rate. So if you’re skating the edge of the road now (meaning the bare minimum due is the full daily average you have to maintain) then you’ll permanently be skating it.

PS: After explaining all that it occurs to me that the right way to do this is to improve and generalize the auto-ratchet feature. But skatesum is what we have in the meantime. If anyone requests it I can throw in a version for non-auto-summing roads.


Thanks! Also, can someone clarify how clocky works?

I’m thinking that if there are 2n or 2n + 1 data points from midnight to midnight, it returns sum over i from 1 to n of f(2i - 1) - f(2i) where f(x) is the xth data point, and just ignores f(2n + 1) to start again at g(1) the next day. (clock in, clock out pairs.)

Or does it include g(1) - f(2n + 1)? Then what does it do for the other g values?

Or does it just sum f(j + 1) - f(j) over j from 1 to m - 1, where there are m data points?


Thanks for asking for that clarification!

# Sum of differences of pairs, eg, [1,2,6,9] -> 2-1 + 9-6 = 1+3 = 4
def clocky(l):
  if len(l) % 2 != 0: l = l[:-1] # ignore last entry if unpaired
  return sum([end-start for [start,end] in partition(l,2,2)])

(The partition function turns a list into a list of pairs.)

Does that answer it? Do you agree with the answer?


You definitely answered my question. But the way it’s implemented will only work if you’re never clocked in at midnight. For instance, if I log the start and end time for every meditation session and use clocky to total the times, if I start meditating at 11:30pm and stop at 12:30am, the 11:30pm time will get ignored and the 12:30am time will be treated as a start time, making that day’s numbers inaccurate.

I’m not sure how easy that would be to fix - you’d have to either subtract 24 from any leftover entry and pass it to the next day’s list, or else, anytime a list has an odd number of entries, tack midnight on to the end of that list and start the next day’s list with a midnight entry as well (essentially clocking out at midnight minus epsilon and back in at midnight plus epsilon). Hopefully that can be done without needing to make a bunch of changes to the rest of the code.

My list of bugs and feature requests