Experimental scheduler

Damien Elmes's Avatar

Damien Elmes

14 Jan, 2018 10:48 AM

Please use this thread to discuss the experimental scheduling changes.

Showing page 2 out of 2. View the first page

  1. Support Staff 31 Posted by Damien Elmes on 24 Apr, 2019 03:27 AM

    Damien Elmes's Avatar

    The review behaviour could possibly be made customisable in the future. For now, you can still use the regular scheduler in 2.1.

  2. 32 Posted by lovac42 on 27 Apr, 2019 04:00 AM

    lovac42's Avatar

    @Martin: Subdeck limit: https://ankiweb.net/shared/info/1460733408

    @DAE: Any projected dates or are you just throwing ideas out there? I abhors project conflicts.

  3. Support Staff 33 Posted by Damien Elmes on 27 Apr, 2019 11:48 PM

    Damien Elmes's Avatar

    If you're in a hurry to see it implemented, feel free to send me a patch that adds the old review deck ordering as an optional alternative in the preferences - it will need to only show when the v2 scheduler is enabled.

  4. 34 Posted by Jian on 30 May, 2019 05:38 AM

    Jian's Avatar

    I'm using desktop 2.1.13 and iOS 2.0.48 and turned the experimental scheduler on a day or two ago. I finished all of my cards for today (no more "Due" or "New") on iOS and synced up with the desktop app, but noticed that the desktop still has a number of "Due" and "New" cards:

    - A small number of cards appear as "Due" in the desktop app. These are related to cards that were already answered today, which is why they were (correctly) not showing up in iOS.
    - In all decks which still have new cards, there is a new count in the desktop, even though I had already learned the maximum number of new cards in iOS
    - In decks which have review cards beyond the daily limit, the desktop app still displays cards as due. For example, in a certain deck I have a 100-card review limit, studied 100 cards today in iOS, but still see another 100 cards due in desktop.

    These differences persist after multiple syncs on both clients.

  5. 35 Posted by Jian on 30 May, 2019 05:42 AM

    Jian's Avatar

    After another sync on iOS, the Due and New counts for a parent deck have now reset to 100/20 (the max limits) even though they were previously at 0/0.

    Another bug: Cards which were studied in custom study (forgotten) do not show up in the Review Count/ Review Time statistics (yellow bards) of either client.

  6. Support Staff 36 Posted by Damien Elmes on 30 May, 2019 09:29 AM

    Damien Elmes's Avatar

    The first issue sounds more like some syncing issue - I'd suggest you force a one way sync to get all clients back into a known state, then see if it happens again.

    The forgotten custom study option does not reschedule cards, and when rescheduling is disabled, no record of the card views is kept.

  7. 37 Posted by Jian on 31 May, 2019 03:37 AM

    Jian's Avatar

    This comment was split into a new discussion: Due counts not syncing

    > I'd suggest you force a one way sync to get all clients back into a known state, then see if it happens again.

    I forced a one-way sync and the problems persisted.

    Then, after another day of reaching the daily limits on iOS, syncing the iOS client, and then syncing the desktop client, I still see more cards to be learned and reviewed on the desktop client.

  8. 38 Posted by dgbeecher on 31 May, 2019 07:06 PM

    dgbeecher's Avatar

    Question regarding this sentence in the experimental scheduler documentation:

    Upgrading to a new beta: To minimize the chance of problems, please disable the new scheduler prior to upgrading, and enable it again after you have upgraded.

    Does this refer to AnkiMobile betas? Or just Anki Desktop betas? If the latter, does this recommendation still apply now that Anki 2.1 is out of beta, if I'm not on the beta track?

    (This recommendation, to disable/enable the new scheduler prior to upgrading, is what prevented me from trying it out for a long time. Seems like quite a hassel, considering I'd need to clear cards in learning each time I upgrade.)

  9. Support Staff 39 Posted by Damien Elmes on 01 Jun, 2019 06:16 AM

    Damien Elmes's Avatar

    I've removed that text - if it is necessary in the future I'll mention it in the change notes.

  10. 40 Posted by Alex on 11 Jun, 2019 01:09 AM

    Alex's Avatar

    Problem with "learning" cards, after they are reviewed in filtered deck, return to their parent decks (after the filtered deck is emptied) showing that they haven't been review...

    Explanation:

    I put both learning cards and review cards in a filtered deck, using the filter of "is:due", did them all (both learning and due review), then hit rebuild to see what would happen. Just the learning cards that I did went back into the filtered deck. Did them again, since there weren't a lot of them and just sped through. Then hit empty deck and went to main screen. Saw that the learning cards went back to their original parent decks and showed up as due again (just the learning cards). I noticed that the cards went up in steps during each time I did the cards (my steps are 20 1 3 6 15 30); eg. One of the cards that had 6 days in the filter deck went up to 30 days once they went back to their parent deck

    I have schedule v2 on.
    "reschedule cards based on answers" is turned on for the filtered deck

    The "Experimental scheduling" page says that "filtered decks no longer reset (re)learning cards when they are built of emptied, and reviews and learning cards will show up in the correct queue instead of the new queue". This is true, but why if I did a "learning" card review in the filtered deck, it goes back into their main deck (when filtered deck is emptied) as showing not having been reviewed?

    Is there something I'm fundamentally missing here? Thank you

  11. 41 Posted by Alex on 11 Jun, 2019 01:13 AM

    Alex's Avatar

    I guess I understand that the card will go up a step (which is connected to the card), and then that same progress of the card will be transferred back to the parent deck. Is there a way where I can do the learning step in a filtered deck, then return it back to the parent deck having showed that it's already been done i.e. it won't show up in the "due" category for the parent deck?

  12. Support Staff 42 Posted by Damien Elmes on 11 Jun, 2019 06:23 AM

    Damien Elmes's Avatar

    A fix for that issue is in the latest beta - please give it a try.

    https://apps.ankiweb.net/docs/beta.html

  13. 43 Posted by Alex on 11 Jun, 2019 04:38 PM

    Alex's Avatar

    Thank you! Seems to work perfectly! I even tried it mixing learning cards from two different decks with different learning steps, and it seemed the cards went to their respective next step accurately. Again thanks

  14. Support Staff 44 Posted by Damien Elmes on 17 Jun, 2019 07:53 AM

    Damien Elmes's Avatar

    To the users who were asking for an option to mix new cards from child decks, Lewis has proposed a solution that should perform acceptably, and will ensure the limits of the child decks are preserved. It works by showing new cards based solely on the due order - the earliest due comes first, regardless of which child deck it's in. Mixing will thus depend entirely on how the due numbers are distributed in the child decks - if deck X has all the small due numbers, cards will come only from deck X until deck X's daily limit is reached. If each child deck has a mix of smaller and larger due numbers, the cards would appear in a more mixed order.

    I'd be interested to hear what people think. The associated pull request is at https://github.com/dae/anki/pull/313

  15. 45 Posted by Alphyn on 17 Jun, 2019 04:30 PM

    Alphyn's Avatar

    I don’t think this is a very good implementation. If I understand this correctly, this will require an almost unfulfillable condition to work: the due numbers of the new cards of each of the subdecks will need to be synchronized. It will be very hard to do and losing the synchronization will be very easy, just set different new card limits for the subdecks, and the due numbers will go out of sync instantly. I don’t see the practical application of this. I would prefer the things they are right now because at least I can change the daily new limits freely, and even if it’s not possible to alternate the new cards from different decks, it’s possible to change the priorities by renaming the decks. Reordering multiple decks at once and keeping them in sync seems very inefficient to me. A simple random number generator to select the next deck to draw a new card from would do a much better job, if there were a way to implement it in a performance-friendly way.

    Regarding the performance, It’s great that Lewis put a lot of effort in benchmarking the performance, but with 2000 decks 1000 cards each, it will take 100 years to go through all the new cards learning 55 new cards per day. But if you try really hard and use Anki 24/7 without any breaks, view every card only once, never fail a card, never review a card and only learn new cards and spend no more than 15 seconds on each card, it will only take a year of non-stop ankiing. After you’re done, you can go sleep for 3000 hours and eat 2000 pounds of food. My point is, it looks like a bit of overkill, and I think it would make sense to do the benchmarking with more realistic numbers. I think any user who uses more than 200 subdecks is an extreme case. I, naturally, don’t have statistics at hand, but my intuition tells me that 99% of Anki users have fewer than 100 decks and fewer than 50000 cards. I think hypothetical people with thousands of subdecks would have performance issues regardless of how the new cards are handled.

    I would also want to discuss the way the due numbers currently work. In fact, I’ve been thinking about this lately. I understand that changing this would be very difficult from the compatibility point of view, but I wish the due numbers had their own column in the card browser as opposed to sharing it with the review cards’ due dates and learning card steps (I don’t exactly know how this works in the database, so I’m talking from the user’s point of view). Another issue with the due number is that sometimes Anki changes them by a lot. The order within a deck persists, but the due numbers can unexpectedly increase by a few thousand. I think checking the database causes this, but I may be mistaken. This also makes Lewis` implementation unreliable. I wish the due numbers were persistent, so that only user could change them, I wish they were not replaced by the due dates and it was possible to sort the review cards by their original due numbers in the card browser. It would make managing and sharing the order-critical decks much easier. There is currently a workaround that many people use – an invisible field that is only used for sorting purposes. But it remains a workaround and it has major disadvantages: you can’t use the reorder command on a field and you need to fill the field manually or use a third-party spreadsheet software in conjunction with importing and exporting. This isn’t a big issue but It would be cool to see something done about it eventually.

  16. 46 Posted by Lewis on 18 Jun, 2019 06:52 AM

    Lewis's Avatar

    Hi Alphyn

    I just want to understand what you're saying about synchronizing subdecks a little better so maybe I can input. What is the synchronizing that needs to happen between subdecks? Do you mean that if subdeck_1 = {a,b,c}, subdeck_2 = {d,e,f}, subdeck_3 = {g,h,i}, then the due numbers would have to be something like a=1,d=2,g=3,b=4,e=5,... and that you would have to manually maintain that order when you add cards?

    I'll let you confirm, but on the assumption it is, that is not how I saw it working. Rather you would open the parent deck in the browser, select all the new cards, and then in the menu "Cards" > "Reposition" and check the "Randomize order" checkbox. Now when you study the chance of each new card to be shown being from a deck will be proportional to how many new cards each deck has. Of course, your daily new limits on a deck can ensure not too many cards from a single deck are shown.

    Of course the other option is not to shuffle the due numbers of the new cards, in that case new cards will be shown in the order that you created them. So if you create a new card in subdeck "zzz" it won't be buried until after you've completed the new cards from every other deck. I'd rather see my "older" new cards first.

    But really, the idea is that you have all the flexibility of the due numbers to achieve whatever you want the same as on decks without subdecks. You can randomize all the cards but then decide maybe there's a dozen you need to shift up to be first. You can then do everything you can on a normal (without subdecks) deck to get the order you want without the scheduler getting in the way. You have the choice to "Study Now" on the top-level deck and have it behave exactly like a normal deck with all the cards together.

    Regarding the benchmarking, this change has nothing to do with increasing the peformance. It was only to make sure that there wouldn't be a degradation of performance for users who have a lot of subdecks. For the program in the background this method of scheduling new cards is still a lot slower than the existing method. But it won't be noticeable to anyone with a realistic number of cards.

    I hope what I've said helps?

  17. 47 Posted by Alphyn on 18 Jun, 2019 10:08 AM

    Alphyn's Avatar

    Hi, Lewis!

    Yes, that’s exactly what I meant when I talked about synchronizing. I’d like to explain what I meant by desynchronizing, though. Correct me if I’m wrong, but your approach will impose some major limitations, namely, you’ll need to have the exact same new card limit for each of the subdecks. If you have one deck with 10 cards per day and another deck with 5 cards per day and you distribute the due numbers randomly, the first deck will go through the lower due numbers twice as fast as the second one, and even by day 2 the master deck will start showing you the new cards from deck 2 earlier than the cards from deck 1 because they’ll have lower due numbers. That’s what I meant by desynchronizing. You can circumvent this limitation by carefully and manually crafting the new card queue, taking into account the ratios between the new card limits of different subdecks. This approach doesn’t look practical to me either because it will be increasingly harder to do with the increase in the number of the subdecks; you can’t take into account the buried and suspended cards; it will be much harder to randomize the cards. The biggest problem with a pre-made new card queue is that you won’t be able to change the new cards limits dynamically when you need it. For example, when I was on the train today, I reduced the new card limit on one of my decks to 0 and doubled the limit on another deck. If my decks had a common due numbers, the order would be ruined. Not being able to do this, in my opinion, defeats half the purpose of having subdecks to begin with.

    It looks like we just have different approaches to organizing the learning material. I, for example, would never randomize the order of the cards within the decks, because, being a language learner, I want to learn more common and useful words first. However, I would still enjoy seeing the HoochiePapa approach on mobile, even though I rather got used to the current approach after using the V2 scheduler for several months.

    I’m not saying that your approach shouldn’t be implemented just because I won’t use it, but It does seem a bit too niche with the limitations I mentioned.

  18. 48 Posted by Lewis on 18 Jun, 2019 03:41 PM

    Lewis's Avatar

    Ah yes! I understand what you're saying now Alphyn. Thank you!

    What if we approach it from this direction... Scheduling new cards based on due order provides add-ons with a backdoor into doing the scheduling on mobile. Of course, it requires running the add-on on your desktop so it can put your cards in order according to whatever algorithm suits and then syncing you collection with AnkiWeb, but then at least that ordering would be available on your mobile. Depending on things like what you said about changing the new card limits on the fly, you may have to re-run your add-on on the desktop regularly, but it gives an option at least. What do you think?

    It's of course not possible for the same scheduling method to work for everyone but that's why I prefer the single approach of using due number which everyone can then have control over. I see it as removing a quirk that with subdecks that gets overridden.

    For what it's worth, my typical use case is that I add notes as I study material, so generally the automatic due numbering is good for me because I want them to be learnt in that order so that no card is being left too long between my study and then having it as part of my reviews. Sometimes, there's difficult or less important cards so I will push them to the end of the new card queue. Neither of these things work with subdecks. I get forced to learn whatever deck happens to be first alphabetically. I use subdecks because it's more natural for me to organise things hierarchically rather than as a flat structure with tagging.

  19. Support Staff 49 Posted by Damien Elmes on 24 Jun, 2019 01:42 AM

    Damien Elmes's Avatar

    Add-ons that regularly change the due numbers are not without cost - they will result in longer syncs.

    Tags don't need to be flat - you can use "::" just like on decks if you wish to denote structure in the tags.

  20. Support Staff 50 Posted by Damien Elmes on 27 Jun, 2019 12:41 AM

    Damien Elmes's Avatar

    2.1.14 is now available, and I'd recommend people using the experimental scheduler to update, as it fixes two bugs related to learning cards.

  21. 51 Posted by Tobias Predel on 12 Jul, 2019 05:31 PM

    Tobias Predel's Avatar

    Word document contains probably a macro virus. DO NOT OPEN!!!

  22. 52 Posted by stephenl on 12 Jul, 2019 08:22 PM

    stephenl's Avatar

    I apologize. I didn’t send that email. I’m not sure how it happened. I have a private commercial email provider. Unfortunately you are not the only one to receive this message.

    Stephen

  23. Support Staff 53 Posted by Damien Elmes on 14 Jul, 2019 01:22 AM

    Damien Elmes's Avatar

    Thanks Tobias, I have removed the posts. Stephen: your machine may be infected, I'd suggest running an antivirus program to check it.

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:

»

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac