Streaks calculating incorrectly

[Randomname876]

Pre-submission checklist

• [y ] I am submitting a bug report, not a feature request.
• [ y] I have searched for similar issues, but did not find any matches.

Description

A clear and concise description of what the problem is.

The current behaviour for streak calculation appears to be that if the previous x days meet the frequency requirement (e.g. for 2/7, if there are 2 successes in the past 7 days) , then all those previous x days are marked as a streak. However, some of those previous x days may not pass this same test, and should actually cause broken streaks...

See screenshot for clarity. The screenshot is of a 2/7 frequency. It shows a long streak, however I have clearly not achieved a frequency of 2 successes EVERY 7 days. The success rate is actually 1/6, or 2/12. E.g. when the habit wasn't completed on the 29th, 30th, 31st, 1st, and 2nd, these days were originally a x and a broken streak. However when the habit was completed on the 3rd, all these days got overwritten to hollow ticks / a streak.

I believe the fix is to change streak determination (or hollow ticks) to a per day basis. E.g. each day should do the 'previous x days check'. This should not be overridden by the result of 'previous x days check' of future days.

Steps to reproduce: see screenshot for 2/7 frequency habit

System information

• Phone: [Google pixel 5]
• Phone Operating System: [Android 12]
• App version: [2.0.3]

Screenshots

If applicable, add screenshots to help explain your problem.

[hiqua]

Summary of how I understand it: if a day is within any d days interval in which there are n ticks, and the goal is n ticks in d days, then it's the user didn't have to do the habit for the streak to continue.

[Randomname876]

Hi Quentin

That is correct, it appears that is how the algorithm currently works.

However, this results in outcomes that ‘breaks’ the streak system and the theory of why streaks help change behaviour.

E.g. take a 2/7 frequency for example.

If you perform the habit on the 1st, and the 5th day, then you are on a streak until the 8th day regardless of whether you perform the habit on these days.

But if you do not perform the habit on the 8th day, then the streak is broken (you get a cross), because you have NOT performed the habit 2x times over the previous 7 days.

However, say if you then perform that habit on the 10th day, you are magically back on a streak for the whole period! (and the crosses change to ticks)

The problem with this is, say in the above example, when you reach the 8th day, and see that you need to perform the habit to maintain the streak, deep down you know this is actually not the case. E.g. you could just not do the habit, lose the streak (and get a cross), and then do the habit on the 10th and get the streak back (and the ticks).

This goes against the whole premise and power of the streak system.

I believe that once you have a broken streak / cross, this should not be able to be changed back to a tick.

An alternate way to look at:

Say the example above, currently once you do the habit a second time on the 5th day, you are on a 5 day streak.

I would argue that the streak has only started on the 5th day, once you have completed the second habit in a 7 day period.

So you would have a tick on the 1st, cross on the 2nd, 3rd, and 4th, a tick on the 5th, and ‘hollow ticks’ on the 6th and 7th.

By changing the algorithm to only ‘award’ hollow ticks into the future would fix the issue, and better represent the ‘streak’ system.

To put it into your words:

“Summary of how I understand it: if a day is within any HAS A PAST d days interval (INLUDING THAT DAY) in which there are n ticks, and the goal is n ticks in d days, then it's the user didn't have to do the habit for the streak to continue.”

By the way, excellent app. Way ahead of the habit app competition.

You should include a paid version.

I would definitely pay / donate for it, and I’m sure a lot of other would too.

Thanks, Luke.

From: Quentin Hibon @.> Sent: Friday, 8 July 2022 5:01 AM To: iSoron/uhabits @.> Cc: Randomname876 @.>; Author @.> Subject: Re: [iSoron/uhabits] Streaks calculating incorrectly (Issue #1426)

Summary of how I understand it: if a day is within any d days interval in which there are n ticks, and the goal is n ticks in d days, then it's the user didn't have to do the habit for the streak to continue.

— Reply to this email directly, view it on GitHub https://github.com/iSoron/uhabits/issues/1426#issuecomment-1178085863 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ6T4NARQ4L5B24V2BI4D43VS4SPHANCNFSM52452BIQ . You are receiving this because you authored the thread. https://github.com/notifications/beacon/AZ6T4ND426AFN7AJ2OWHM4TVS4SPHA5CNFSM52452BI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIY4CTZY.gif Message ID: @. @.> >

[hiqua]

But is this a problem that cannot be fixed by just increasing the number of ticks required? Say you're not happy because 2 out of 7 days is too lenient, then 3/7 or 4/7 should work?

[Randomname876]

Hi Quentin.

Yes, increasing the frequency will make it ‘harder’ to achieve a streak.

But the bigger problem here is the fact that crosses / breaking a streak can then later be magically changed back to a tick / streak reinstated under the current algorithm.

This significantly reduces the benefits of using a streak system and the behavioural positives that come with the ‘loss eversion’ of trying not to lose a streak.

I thought it would be a simple change to the algorithm (but I am not a coder!).

Luke.

From: Quentin Hibon @.> Sent: Friday, 8 July 2022 7:11 AM To: iSoron/uhabits @.> Cc: Randomname876 @.>; Author @.> Subject: Re: [iSoron/uhabits] Streaks calculating incorrectly (Issue #1426)

But is this a problem that cannot be fixed by just increasing the number of ticks required? Say you're not happy because 2 out of 7 days is too lenient, then 3/7 or 4/7 should work?

— Reply to this email directly, view it on GitHub https://github.com/iSoron/uhabits/issues/1426#issuecomment-1178235098 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ6T4NC4P5UJYKTA6XSURKLVS5BVFANCNFSM52452BIQ . You are receiving this because you authored the thread. https://github.com/notifications/beacon/AZ6T4NEWKV7YGV44HNCEF43VS5BVFA5CNFSM52452BI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIY5HBWQ.gif Message ID: @. @.> >

[Randomname876]

Hi Quentin

I was just wondering whether this is a change you are considering?

Luke.

From: @. @.> Sent: Friday, 8 July 2022 9:11 AM To: 'iSoron/uhabits' @.>; 'iSoron/uhabits' @.> Cc: 'Author' @.***> Subject: RE: [iSoron/uhabits] Streaks calculating incorrectly (Issue #1426)

Hi Quentin.

Yes, increasing the frequency will make it ‘harder’ to achieve a streak.

But the bigger problem here is the fact that crosses / breaking a streak can then later be magically changed back to a tick / streak reinstated under the current algorithm.

This significantly reduces the benefits of using a streak system and the behavioural positives that come with the ‘loss eversion’ of trying not to lose a streak.

I thought it would be a simple change to the algorithm (but I am not a coder!).

Luke.

From: Quentin Hibon @. @.> > Sent: Friday, 8 July 2022 7:11 AM To: iSoron/uhabits @. @.> > Cc: Randomname876 @. @.> >; Author @. @.> > Subject: Re: [iSoron/uhabits] Streaks calculating incorrectly (Issue #1426)

But is this a problem that cannot be fixed by just increasing the number of ticks required? Say you're not happy because 2 out of 7 days is too lenient, then 3/7 or 4/7 should work?

— Reply to this email directly, view it on GitHub https://github.com/iSoron/uhabits/issues/1426#issuecomment-1178235098 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ6T4NC4P5UJYKTA6XSURKLVS5BVFANCNFSM52452BIQ . You are receiving this because you authored the thread. https://github.com/notifications/beacon/AZ6T4NEWKV7YGV44HNCEF43VS5BVFA5CNFSM52452BI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIY5HBWQ.gif Message ID: @. @.> >

[hiqua]

I think that's unlikely that we directly change this, but I'm also not the one deciding.

One thing I think we should do: instead of retrofitting the notions of weeks and months into our previous model (which only considered days as you've realized), implement them properly, so that users can say "2 times per week" and get the behavior you expected. Right now "2 times per week" is really "2 times every 7 days" which is not really the same (the first is a fixed window, e.g. from Monday to Sunday, while the second is a moving one).

That's a rather big feature though so unlikely no promise it'll come anytime soon.

[exanrauzer]

I agree with Luke in the sense, that magically filling past days is not we expected to have. The algorithm shouldn't have to 'look into past'. In the video below I think we can agree that this is not what we would like to see.

https://youtu.be/t_m8M4AhLbQ

It takes a lot of thought and probably won't be an easy algorithm. This is a technical as well as cgnitive issue - both aspects should be combined and resolved.

[Randomname876]

Hi Exan.

Yes your video shows clearly the behaviour I was trying to describe. (I should have also just done a video!)

I’m not a coder, but it appears that the algorithm is checking if the criteria is true (e.g. 2 TRUES in seven days) both forward OR backwards in time – and then giving the day a ‘hollow tick’ if it meets the criteria.

Could this just be changed to only check whether the criteria is true backwards in time? (remove the OR).

Anyway, thanks everyone for getting back to me, great customer service!

Again, well done on the great app.

Luke.

From: Exan Rauzer @.> Sent: Friday, 29 July 2022 6:16 PM To: iSoron/uhabits @.> Cc: Randomname876 @.>; Author @.> Subject: Re: [iSoron/uhabits] Streaks calculating incorrectly (Issue #1426)

I agree with Luke in the sense, that magically filling past days is not we expected to have. The algorithm should have to 'look into past'. In the video below I think we can agree that this is not what we would like to see.

https://youtu.be/t_m8M4AhLbQ

It takes a lot of thought and probably won't be an easy algorithm. This is a technical as well as cgnitive issue - both aspects should be combined and resolved.

— Reply to this email directly, view it on GitHub https://github.com/iSoron/uhabits/issues/1426#issuecomment-1199004858 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ6T4NCKSVBDDDOR76MYZMDVWOHNPANCNFSM52452BIQ . You are receiving this because you authored the thread. https://github.com/notifications/beacon/AZ6T4NGNZZCVEHXNRS5CHZLVWOHNPA5CNFSM52452BI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOI53VZOQ.gif Message ID: @. @.> >

[exanrauzer]

I am sorry - I made a typo. The algorithm should shouldn't have to 'look into past'. In the video below I think we can agree that this is not what we would like to see.

[exanrauzer]

I was thinking about this. I have been making tests and have some Interface recordings - I will drop them later this day.

Yes, the issues is bounded between past and future (as everything in this Universe). Let's take a 3/7 example. I will go straight to the point - forgive me the lack of thought process:

When I got THREE days already marked in the past, then the algorithm should focus only on LAST TWO and should provide hollow checkmarks in future days as far as streak can be uplifted till last day of this chance.

All history before the last two marks is irrelevant and should not be modified. Counting should take place only into future.

I would be happy explain it other way - please - join this discussion.

[exanrauzer]

So, being consistent -- if you have a 2/7 mode and only ONE day (first in all history) checkmarked, then the algorithm should give you the hollow checkmarks since the first day of your checkmark till the last day of the chance to continue the streak.

I am deeply aware that this changes everything.

[Randomname876]

Hi Exan.

Hopefully you don’t mind me jumping in here….

But I actually see it a little differently.

With the behaviour you are describing below, we would still be left with the same undesirable outcome that if the second tick never happens (e.g. only ever got one tick), then all the hollow ticks would later ‘magically change’ back to crosses.

I believe forward projected hollow ticks should only be awarded once you are ‘on’ a streak.

E.g. if you have satisfied the requirement, such as getting two ticks in the previous seven day stretch.

The duration of the hollow ticks would be all days between the last tick and n-1 days after the first tick. (n is the frequency / 7 days in this instance)

In the below 2/7 example, the streak only commences once you have achieved 2 ticks in the previous 7 days, on Thursday.

This awards 3x future hollow ticks, because all these days satisfy the condition that 2 ticks have been achieved in the previous 7 days.

The habits needs to be completed on the second Monday, otherwise the streak will be broken and a cross awarded, because if the habit is not completed then that day does not satisfy the requirement of achieving 2 ticks in the previous 7 days. (only 1 tick was achieved in the previous 7 days)

I have also continued the example for more clarity:

I hope this makes sense.

Luke.

From: Exan Rauzer @.> Sent: Wednesday, 3 August 2022 2:50 AM To: iSoron/uhabits @.> Cc: Randomname876 @.>; Author @.> Subject: Re: [iSoron/uhabits] Streaks calculating incorrectly (Issue #1426)

So, being consistent -- if you have a 2/7 mode and only ONE day (first in all history) checkmarked, then the algorithm should give you the hollow checkmarks since the first day of your checkmark till the last day of the chance to continue the streak.

— Reply to this email directly, view it on GitHub https://github.com/iSoron/uhabits/issues/1426#issuecomment-1202979908 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ6T4NACL6S5EVN7ISQ75CDVXFGRZANCNFSM52452BIQ . You are receiving this because you authored the thread. https://github.com/notifications/beacon/AZ6T4NFP5XOSC22BRFMPOS3VXFGRZA5CNFSM52452BI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOI62AIRA.gif Message ID: @. @.> >

[iSoron]

Thanks for the bug report, @Randomname876. In your original screenshot (where you have ticks on May 22, 28, June 3, 9, 15, 21 and 27), what days do you think should receive hollow ticks?

If you perform the habit on the 1st, and the 5th day, then you are on a streak until the 8th day regardless of whether you perform the habit on these days. But if you do not perform the habit on the 8th day, then the streak is broken (you get a cross), because you have NOT performed the habit 2x times over the previous 7 days. However, say if you then perform that habit on the 10th day, you are magically back on a streak for the whole period! (and the crosses change to ticks)

If you have ticks on July 1, 5 and 10, the app adds hollow ticks on June 29 to July 11 because each of these days belongs to 7-day interval which has two ticks in it. To be more specific, we have two intervals in this example: June 29-July 5 (which generate the hollow ticks on June 29, 30, July 2, 3, 4) and July 5-11 (which generate hollow ticks on July 6, 7, 8, 9 and 11).

We are aware that only one of these intervals should generate hollow ticks, but it is hard to determine which one of these should be considered and which one should be discarded, so the app errs on the side of being too generous, and adds ticks for both.

But the bigger problem here is the fact that crosses / breaking a streak can then later be magically changed back to a tick / streak reinstated under the current algorithm. This significantly reduces the benefits of using a streak system and the behavioural positives that come with the ‘loss eversion’ of trying not to lose a streak.

The app does this to support, for example, habits that are performed on different week days every week, or other irregular schedules. For example, if the user has a weekly habit and performs it on June 1 (Fri) then June 9 (Sat), then the app will initially add a cross on June 8 (Fri). If the user, however, then performs the habit on June 15 (Fri), it becomes clear to the app that the weekly schedule is actually alternating between Fridays and Saturdays, so the app replaces the cross on June 8 by a hollow checkmark. If the app were not allowed to modify the past, then we would not be able to support this important use case.

[iSoron]

I'm converting this issue into a discussion, since the app is behaving as the developers expect.