Mac/iPad/iPhone Flashcards

[OneEye]

Well, that's an odd way of interpreting what I said.

Here's why it works the way it does. Let's say you have 200 cards due in Anki. You answer them today and forget to sync. You answer them on a different platform tomorrow along with some other questions that have now become due. Some of the answers were different. Not to mention, you've now reviewed the 200 cards you answered yesterday too early, which is going to interfere with the spaced repetition algorithm. You now have two conflicting decks, and have to choose which one to keep. It's up to you how you want the program to handle it. You are controlling the program, I don't see how this can be the program controlling you. You just have to be smarter than the program. And learn to sync when you need to.

[feng]

Firstly I have been using Anki for a long time, forgetting to sync can and does happen so saying "just don't forget to sync" is not helping anyone (:

Secondly, Just say I do get into a situation where I have 2 hours worth of reviews on my iPhone, and a bunch of new cards and 1 hours worth of review on my Laptop. I would much prefer to just merge the two decks. If there is a conflict in the answer for a particular card, the card updated most recently obviously has the correct answer. ie

1. iPhone says forgotten, then Mac says remembered. mac is right

2. iPhone says remembered, then Mac says forgotten, mac is right.

Its not that complicated is it not. The most recent update is most likely to contain the information as to wether you have remembered or forgotten the card. Of course its not as good as if for example, both the iPhone and Mac were continually syncing with a "cloud" service, but its good enough for most peoples purposes I am sure.

[OneEye]

The problem comes in when you consider the way SRS works. The reason you got the card right the second time around could be that you saw it the day before on another platform and forgot to sync. Let's say you have a card that is currently at a 2 month interval, and you get it wrong today and the interval drops down to 1 day, but you forget to sync. Now, when you see it on the other platform tomorrow, it is still set at the previous interval of 2 months on that platform. You'll probably get it right since you just saw it yesterday, and so now the interval will go up to 4 months or whatever, rather than 2 days or so, because this platform doesn't know you got the card wrong yesterday due to you not syncing. That's a problem, because the card technically should have started over from scratch, or however you have Anki set to handle failed cards. This is why you have to choose which deck to keep, and I would say the most beneficial deck to keep in this case would be the one you forgot to sync in the first place. At least that would be the more conservative choice from an SRS/memory standpoint. Otherwise you have cards that are graded higher than they probably should be, because their scoring information doesn't account for the fact that you forgot the card.

Of course, if you want to always keep whichever version of the deck is most recent, that's certainly your choice. But the program gives you that choice to make rather than making it for you, .

[mikelove]

I'm very interested in this discussion since we're currently working on flashcard sync for Pleco (via iCloud) and trying to sort out what we should do in the case of conflicts like this. In theory iCloud syncs continuously and can avoid them altogether, but a lot of our users only connect their devices to the internet once or twice a day and so can still easily end up with a file conflict.

It seems like an intelligent system would need to look at the individual cards rather than just taking one deck over the other, because it's possible that you might have two partially-overlapping review sessions on the two different devices - even if everything is happening in strict order by due date, you might finish going through them on one device and only get partway through on the other. And if you only reviewed a card on one device since the last sync, that review should obviously take precedence.

But OneEye's post makes it clear that even for individual cards, simply going by which card was reviewed most recently isn't enough - it seems like what you really want to do (and I'm not even sure if Anki's database format allows for this, but I know ours doesn't yet) is combine both review histories since the last sync and come up with a result as if the card had been reviewed all of those times on the same device - admittedly, the card probably wouldn't have come up this soon if you'd synced more recently, but since a good SRS algorithm can deal with a card being reviewed ahead of schedule that shouldn't be too big a problem.

So basically, you roll the card's state back to what it was before the decks got out-of-sync, then you run it through the interval change calculations for all of the reviews that have happened since then and whatever you end up with is the new interval / E-factor / etc.

The one wrinkle in this is what you do if a user manually edited the interval at some point - it seems like in that case you'd probably want to take that edit as gospel, start from it and only apply the results of reviews that had happened since then.

Does that make sense or am I missing something?

[feng]

Hi Michael, Great to see you are thinking about this. My purpose of making a simplified example was to try and argue a point that at least at minimum, it would be possible to merge a "deck" based on individual cards, and the result would be better than just throwing away a whole deck.

I do have some thoughts on the algorithm for syncing things properly however, and it goes along the lines of this.

1) Each review of each card on each device gets logged, i.e. so you might have a card "table" and a "card review history" table.

2) The review history table tracks the cards old score/stats, and the users input. (so you could re-calculate the current score from the history.

3) The history table keeps review information for a limited time, i.e. 30 days. You teach the end users that merge conflicts are handled better if they bring their device online every 30 days.

4) If a card has NO history, it is new, it can just be copied to all other devices.

5) If a card does not exist, but has a history (i.e. it was deleted), then its deleted from all devices

6) If a card has had one or more reviews on both devices, an "algorithm" is used to merge the review history for both devices.

Keeping a card review history has an added bonus that you can do n-way syncing between more than two devices.

But I come back to my first example. Even if you don't want to do such a sophisticated algorithm such as above, then at least do the minimum, just take the newest answer from each card. It is not ideal, but its better than throwing a whole deck away!!!!

[roddy]

Thanks everyone for your suggestions! I've decided to try Anki out, and it can actually do what I want it to do with the "multiple sides" feature.

Lnoc, how are you getting on with Anki?

[Inoc]

roddy, thanks for asking! I'm still in the process of creating all of my flashcard decks. As I mentioned, each card has 4 components - simplified, traditional, pinyin, and definition. However, as I discovered, it's more helpful to have just a few of those components being shown when reviewing a card - say, when the card flashes simplified, then the other side will have pinyin and definition (but not traditional). Or, when the card flashes traditional, the other side will have simplified and pinyin (but not definition). So what I've been doing is duplicating each of my flashcard decks and then modifying each duplicate deck so that it will display the components that I want to review in that deck. In other words, I have a simplified/pinyin-definition deck, a traditional/simplified-pinyin deck, a definition/simplified-pinyin deck, and so on, but the underlying cards themselves are all the same. It's just the interface that's different. However, I don't know if this is the most efficient way to be going about this, so if anyone has a better suggestion, please do offer it!

[mikelove]

feng - thanks for your thoughts on this.

Keeping history information for a limited time makes a lot of sense, but an advantage to keeping it permanently would be that we can make much cooler graphs / statistics reports / etc that way, and provide the option to retroactively change the algorithm for every card if you come up with a new and better way to determine E-factors.

So the question is how much space it would use - a "dumb" system would store the timestamp plus card score for a total of 5 bytes per review (no need to give every review its own table record, just tack them onto a big BLOB record you keep for each card), but even that wouldn't be unreasonable on a modern smartphone - just a megabyte would be enough to store 210,000 reviews, or almost 3 years' worth if you average 200 cards per day. So it seems pretty workable. (and of course with data compression or more dense bit-packing you could probably improve considerably on that 5-byte figure)

Step 5 raises an interesting question of whether it's worth keeping history data around for deleted cards at all - might be helpful later for analyzing somebody's learning patterns, but it's potentially quite a lot of wasted space.

But yes, any sort of individual card merging would beat throwing out the entire deck.

[feng]

Regarding the amount of time a cards history is kept, its a tough question. I have also done the math with regard to keeping card history, and you are right, it does not require a lot of storage space.

My main issue with keeping the history is the sync speed over a mobile network. I don't think there is a right number. For a tool like Anki which likes to have a bajillion configuration options and where people might have massive decks, the option to choose how much history you keep might be useful.

[mikelove]

Well with an intelligent system, you can potentially limit uploads to only the changed parts of the database - even with a dumb app, iCloud keeps a copy of the last synced version of a file around and only uploads the changed parts to Apple's servers. But a few hundred KB every time you sync is still a lot if you're on a limited data plan with irregular access to WiFi, so making it configurable might be the smartest option.