Okay, a further refinement. Instead of partitioning young/mature cards, a relative delay (RD) is calculated based on the card's initial interval, divided by the delay. This way, a delay of 1 day for a 10 day card should be the same as a delay of 5 days for a 50 day card.

fail=1 young=1 d=00.04 rd=00.00 i=00.00
fail=1 young=0 d=11.96 rd=00.76 i=09.09
fail=1 young=0 d=11.96 rd=01.49 i=17.84
fail=1 young=0 d=11.96 rd=02.34 i=28.01
fail=1 young=0 d=11.96 rd=03.96 i=47.34
fail=1 young=1 d=00.04 rd=23.60 i=01.00
fail=1 young=0 d=00.08 rd=228.00 i=18.53
fail=1 young=0 d=00.08 rd=302.00 i=24.11
fail=0 young=1 d=37.83 rd=00.08 i=03.21
fail=0 young=1 d=37.28 rd=00.09 i=03.28
fail=0 young=1 d=37.69 rd=00.09 i=03.35
[...]
fail=0 young=0 d=36.53 rd=00.82 i=29.84
fail=0 young=0 d=09.86 rd=00.83 i=08.18
fail=0 young=0 d=29.00 rd=00.84 i=24.51
fail=0 young=0 d=35.54 rd=00.87 i=30.85
fail=0 young=0 d=09.51 rd=00.90 i=08.53
fail=0 young=0 d=09.34 rd=00.93 i=08.71
fail=0 young=0 d=34.02 rd=00.95 i=32.39

This sounds really interesting. Do you look at any statistics across users? I would be curious to know if this new optimization (which sounds great to me btw) will actually have any noticeable memory benefit across the user base.

It has two useful properties:

- failed cards are given priority, even if other cards expire in the interim. you can close anki with a bunch of failed cards due within 10 minutes, and when you come back to it the next day, they will be displayed first
- it shows the cards with the largest relative delay first. this means that
a) cards will be displayed in the same order on the server and your local machine, regardless of deck order
b) it improves your chances of answering delayed cards - if you do a little a day, the cards which most need your attention will be displayed first

What statistics do you speak of? I would have thought the optimisation is quite logical. :-)

Sorry, your optimization is quite clear, it was me that wasn't

What I was referring to was a set of statistics that, for the sake of curiosity, would show how well the user base is remembering whatever it is studying both before and after you make the optimization. That would allow you to see what effect the change actually has on memory.

You're asking "do you have any stats to back up the assertion that cards with a longer delay in answering are less likely to be answered correctly?"

This seems obvious to me, so I'm not exactly keen to spend hours gathering and graphing statistics to try and back this up. Remember that this optimisation is mainly there to improve the handling of scheduling when you don't answer things on time. It's not about "having an effect on memory", it's just trying to ensure that the most urgent cards to review get shown first. In an ideal world, you'll answer all the cards in the same session. All this does is show the "oldest" cards first, where age is relative to the interval of the card.

resolve Wrote:You're asking "do you have any stats to back up the assertion that cards with a longer delay in answering are less likely to be answered correctly?"

No that's not it at all. Please don't take me the wrong way. I like what you are doing, really. I just think it would be neat to see the effect of changes and optimizations that is all. I find those sort of things interesting that is all. If it is really a bother to do it then by all means don't bother with it. I really am sorry if I have given you the wrong impression.

No need to apologize :-) Anyway, to see the results of this, pay attention to your global correct% after the next Anki release. It should increase a little if you don't always answer cards on time.

Of course I know about my own global percent correct and I watch that like a hawk. I was talking about stats across all users, in any case I think I have cluttered up the thread a bit too much trying to express this idea time to get back to studying. It really wasn't all that important.

Would it be possible to make the prioritising settings optional in one of the preferences windows?

why?

Hi Resolve,
I wasnt able to try your advice for a week but it appears to be working now.
I did step 3, but didnt have to do step four to run anki. (and I get version 3.6). Is this ok or am I gonna run into problems later.

Also a question. in step four (below), where does cd..; refer to? anki-0.3.6 folder and another folder?

4. cd ..; sudo python setup.py install

Thanks for a great product and all the support

cd .. takes you to the directory above where you are currently. So if you're in /home/anki-0.3.6/libanki and you cd .. , you'll be in /home/anki-0.3.6

uberstuber Wrote:cd .. takes you to the directory above where you are currently. So if you're in /home/anki-0.3.6/libanki and you cd .. , you'll be in /home/anki-0.3.6

Hey thanks for that.
However I did that and now anki takes about 7 mins to boot up. I dont know what the issue is now.
So, I tried to delete all anki related folders from home, where I untared, and started again from step one.
And now It still takes about 7 mins to start up.
What should I try now?

The server seems to be down right now, so maybe it's just trying to sync and timing out?

Right, I'm fed up with that router. I'll do something about it today.

(edit: server will be down for a while)

Using a new router now. Please let me know if any further problems occur.

what was your old router? what did you upgrade too?

Was it just getting swamped under the traffic? Or was it just old?

A "corega" router. When I bought it, it boasted a higher throughput than the other routers out there and was a bit more expensive, but it turned out to be crap. It randomly crashes (exacerbated by wireless use or heavy traffic, but random).

The Anki server has dual gigabit ethernet ports, so I switched over to that as my router. As a bonus, my connection speed has improved too :-)

shaydwyrm Wrote:The server seems to be down right now, so maybe it's just trying to sync and timing out?

That might have been it. Seems to work now.
Thanks

The phone interface feels quite a bit snappier now, too.

Quote:- old before new
- failed before correctly answered (provided the requisite 10 minutes has passed)
- cards in the initial state before mature cards
- cards ordered within a group (failed, young, mature) by overdue time, so that the cards which have been waiting longest are given priority. this applies to 'new' cards too, so that the first time you see them, they'll be displayed in the order they were added. this may be a bad thing when you've just added cards and test, but it'll also ensure if you take a long time to work through the pile, cards won't get stuck in the new card list forever

Could you please define the terms young, old, mature and initial?

new=not seen before
old=seen before
young=interval < 9 days
mature=interval > 9 days
in initial state=young

Thank you, that's great.

The reason that I asked for some of these settings to be made optional is because I think there may be an argument for not using the prioritising settings that you are outlining above. I realise that you've been thinking about this for a lot longer than I have so please bear with me if there are flaws in my reasoning.

Suppose that after answering a card, there is an ideal time to schedule it's next review. Too late and you will have forgotten it, too early and you lose efficiency. Suppose then that Anki does a reasonably good job of scheduling cards at these ideal times. For mature cards especially, it is probably the case that an interval rather than a point in time is ideal. This is captured with your concept of a relative delay.

If you prioritise cards with a high relative delay over ones with a short relative delay then you prioritise ones that have a higher probability of having been forgotten and are the furthest from their ideal review time. In order to maximise efficiency, would it not be better to do the opposite?

There's no way to tell for sure if a card has been forgotten but if you did know for sure then it wouldn't matter when you see it. The relative day measurement seems to measure the probability that a card will have been forgotten. If you have a list of cards ordered by the probability that they've been forgotten, then the urgent ones are the ones with the smallest probabilities. They're due for review so it's certainly not too early and you'd better review them before it gets too late and you forget. The ones with the higher probabilities are the ones that can be put to one side since you've probably forgotten them anyway.

The argument that is put forward for scheduling old cards over new cards (as I understand it) is that you you don't want to waste the learning that you've already done. Prioritising high relative delay cards over low relative delay cards seems that it might contradict this argument for the reasons in the previous paragraph. In addition, I think that failed cards are quite similar to new cards in that you don't know either of them very well. If you prioritise failed cards over correctly answered cards then this also seems that it goes against the argument for prioritising old ones over new ones.

Having said all of the above, I appreciate that the arguments you made for your methods aren't invalid at all. I think that some people may find different prioritising settings more effective than for other people and therefore optional settings might be appropriate.

I don't think that the old/new prioritization is really related to prioritizing high relative delay over low relative delay.

The reason that old cards are shown first is because it's important to review existing material before introducing new material. If you're overwhelmed by your workload, the last thing you want to do is introduce more work.

But prioritizing high relative delays is not introducing more work. You _need_ to answer all of the cards that are pending or you will forget them.

You argue that relatively large delays indicate a high percentage of forgetting, and thus the cards should just be given up on. I don't think giving up on them is appropriate. Say the chance of remembering a long-delayed card is 33%, and the chance of remembering a non-delayed card is 90%. If you prioritize the long-delayed cards, then you have successfully saved all the effort spent on 1/3rd of those cards up until now. The non-delayed cards are still quite strong in your memory, and by the time you get around to answering them, even if the new probability is 75%, you're getting a net gain. This is especially important if you have too much work to do, and can't finish the deck each session (instead, hacking at a little bit of it each time)

If you were to do the opposite, and prioritize cards that are near their ideal scheduling time, you may keep the recall ratio for those cards at the ideal 90%, but it becomes impossible to do a little a day. Any missed cards will keep getting pushed further and further away, and the only way to recover from that is to finish the entire deck.

(Remember here that the change in scheduling is to optimise the way we handle partial completions, delays and work overload. If you're regularly finishing the deck, this change won't have a big effect on you either way).

You also suggest that it may not be best to prioritize failed cards. Remember that one of the goals of a session is to finish with every card answered correctly and scheduled for at least a day in the future. This is the reason so many finish practicing and then wait the requisite few minutes for their expired cards to show up. If you have a review schedule which regularly leaves you with more than a few failed cards, you're probably doing something wrong.

"Can you make it configurable?" is usually not something a software author wants to hear. Different people want to tweak different things, and trying to make everyone happy results in a complicated, bloated application which in turn makes other people who like streamlined apps unhappy! It's pretty much impossible to make everyone happy all the time.

I'm all for configurability when it's appropriate, and Anki has a plugin system. With a few lines of python you could change the scheduling algorithm to whatever you wanted it to be. Any more support than that requires that I understand the reason for making something configurable, and believing that it will actually be useful. At this point I'm not really convinced that keeping the old system or allowing prioritization of on-time cards would be a good idea.

Thanks for the response. I'll try and argue the case a bit further if I may!

resolve Wrote:I don't think that the old/new prioritization is really related to prioritizing high relative delay over low relative delay.

The reason that old cards are shown first is because it's important to review existing material before introducing new material. If you're overwhelmed by your workload, the last thing you want to do is introduce more work.

What's the difference between a new card and a card you've forgotten? If I'm overwhelmed by the workload, I don't want to introduce new cards or forgotten cards because they're both the same amount of work.

resolve Wrote:You argue that relatively large delays indicate a high percentage of forgetting, and thus the cards should just be given up on. I don't think giving up on them is appropriate.

Not given up on, just given a lower priority.

resolve Wrote:Say the chance of remembering a long-delayed card is 33%, and the chance of remembering a non-delayed card is 90%. If you prioritize the long-delayed cards, then you have successfully saved all the effort spent on 1/3rd of those cards up until now. The non-delayed cards are still quite strong in your memory, and by the time you get around to answering them, even if the new probability is 75%, you're getting a net gain. This is especially important if you have too much work to do, and can't finish the deck each session (instead, hacking at a little bit of it each time)

It seems that what's critical here is what you believe the curve of chance of remembering against relative delay looks like. This curve would itself be a function of the interval as well (and maybe other things) so the argument actually hinges on the shape of a surface. If a card has a long relative delay (say for example a card with a one day interval that was scheduled for the first day of your one week holiday), then I think that 2% would probably be more appropriate than 33%. I believe that cards like these should definitely be given a back seat. I also think that the probability would drop very rapidly as the relative delay increases. It seems from your arguments that you don't.

resolve Wrote:If you were to do the opposite, and prioritize cards that are near their ideal scheduling time, you may keep the recall ratio for those cards at the ideal 90%, but it becomes impossible to do a little a day. Any missed cards will keep getting pushed further and further away, and the only way to recover from that is to finish the entire deck.

It wouldn't be impossible to do a little every day since you should finish after a few days. After all:

resolve Wrote:Remember that one of the goals of a session is to finish with every card answered correctly and scheduled for at least a day in the future.

You shouldn't be in a position where you always finish your review session after having completed only a fraction of the expired cards. What we're discussing is how to handle the temporary situations where this sometimes happens.

resolve Wrote:"Can you make it configurable?" is usually not something a software author wants to hear. Different people want to tweak different things, and trying to make everyone happy results in a complicated, bloated application which in turn makes other people who like streamlined apps unhappy! It's pretty much impossible to make everyone happy all the time.

I totally appreciate this, which is why I'm trying to argue my case. I'm afraid that I have absolutely no knowledge of python so I wouldn't know where to begin in writing a plug in.