Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maintain the downward trend of review load when applying Easy Days #372

Open
user1823 opened this issue Feb 25, 2024 · 8 comments
Open

Maintain the downward trend of review load when applying Easy Days #372

user1823 opened this issue Feb 25, 2024 · 8 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@user1823
Copy link
Contributor

user1823 commented Feb 25, 2024

Almost every day, my Future Due graph looks like the following.
image
Here, you can see a downward trend in the number of due cards. But my daily review load remains roughly constant. This is because I do some new cards daily and fail some review cards. These cards get short intervals and increase the review load on the subsequent days, causing it to become roughly equal to that today.

In short, my review load remains constant despite not using the load balancing feature of the add-on.

But, if I apply Easy Day to a specific date (say, 3rd March) with a review percentage of say, 80%, I get a Future Due graph like the following:

image

Look how it has "postponed" many cards so that the review load remains roughly equal on all days in the range. You can see that even the number of cards due in 1 month has decreased. So, some cards are postponed even beyond a month (they must have a large fuzz range though).

This graph gives the impression that the add-on has balanced my review load, but it has not. Once I do some new cards or fail some cards, the cards due on future days (say, a week later) would become greater than the next few days (say, 3 days from now).

If you are wondering what happens if I apply Easy Day to tomorrow, this is what happens:
image

This is not a significant problem if I were using the load balancer every day because it would continuously adjust the number of due cards to keep them roughly constant (it is still wasteful, though). However, if I use it just once (say, to apply Easy Days to a specific busy day), the load balancer "unnecessarily" postpones many of my reviews, causing a high workload in the future.

The following drawing summarizes what I want the load balancer to do:
image

When Easy Days is applied, it can do something like this:
image

@user1823 user1823 added the enhancement New feature or request label Feb 25, 2024
@L-M-Sherlock
Copy link
Member

Because apply easy days to specific date only reschedules a set of cards due in a fixed time windows.

@user1823
Copy link
Contributor Author

user1823 commented Feb 27, 2024

Because apply easy days to specific date only reschedules a set of cards due in a fixed time windows.

Sorry for the late reply.

There are two issues here:

  1. The load balancer is trying to flatten the curve, which is not ideal. It should just try to smoothen it rather than flattening it (as shown in my drawing).
  2. When Easy Days on specific date is applied, the above issue causes the Future Due graph to take a weird shape because only some cards are rescheduled.

Firstly, let me show that the problem exists even when ALL the cards are rescheduled.

My Future Due graph today looks like the following:
image

If I press "Reschedule all cards" after enabling load balancer, it looks like the following:
image

You can see that the load balancer reduced my tomorrow's review load from 148 reviews to 95 reviews because it "thinks" that the load is more balanced now. But actually, it is the opposite as I explained in my previous comment (when I do more new cards and fail some review cards, the future due count will increase).

By the way, the rescheduling changed my burden in FSRS Stats from 149 to 140. This also suggests that I should be doing around 140 reviews per day, not just 95 reviews.

Frankly speaking, I think that the current load balancer is useless because of this behavior. Something like https://github.com/lune-stone/anki-addon-limit-new-by-young may benefit the users more (thank you @aleksejrs for linking it above).

Now, let's come to the issue of Easy Days. The above behavior of the load balancer is directly responsible for causing weird Future Due graph when Easy Days are applied to specific dates. To correct this, an approach similar to my drawing in the previous comment can be used.

@L-M-Sherlock
Copy link
Member

The mechanism of load balance is to reschedule each card to the day within their fuzz range that has the fewest reviews. When you reschedule all cards, the fuzz ranges of cards are slightly overlapped. Due to the tendency of decreasing of reviews in the future, the result of load balance is more like smoothen instead flatten. However, when we apply easy days to the specific dates, the cards in the time windows is likely to be rescheduled out of the time windows, but the cards out of the window cannot be rescheduled into it. It's the main cause of current issue. But I have no idea to solve it without coming up with a new method for load balance.

@user1823
Copy link
Contributor Author

But I have no idea to solve it without coming up with a new method for load balance.

Then, let's add a Help Wanted label to attract more people who can give their inputs.

@d-jason32
Copy link

I can work on this.

@user1823

This comment was marked as outdated.

@user1823 user1823 changed the title [Enhancement] Maintain the downward trend of review burden when applying Easy Days Maintain the downward trend of review burden when applying Easy Days Aug 6, 2024
@user1823 user1823 changed the title Maintain the downward trend of review burden when applying Easy Days Maintain the downward trend of review load when applying Easy Days Aug 6, 2024
@L-M-Sherlock
Copy link
Member

With the new implementation of load balance and easy days, I guess this issue has a solution: apply a weight decay over time on this line of code:

final_weights = [w * m for w, m in zip(weights, mask)]

or here:

expected_distribution = [p * (total_actual / sum(percentages)) for p in percentages]

What do you think of this idea? @user1823

@user1823
Copy link
Contributor Author

Looks like a good idea. But, how to calculate what decay should be applied?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants