2.0.1 Beta 2 Bug Report / Feedback Thread

[mikelove]

sinoreen - I double-checked this duplicate bug and I think it's actually just a problem of character sets; it's natural when creating a user dictionary entry to only include simplified or traditional but not both (I did it myself when testing for this bug), but Pleco will only consider a card a duplicate if both of those fields match. This is to deal with the cases where a given simplified character might have more than one traditional variant with the same pronunciation - if we rejected them as duplicates because their simplified variants matched, it would be impossible to create separate cards for 干/幹/乾 for example.

 

[daniel123]

Actually it looks like there already is a check to make sure that the difficulty isn't changed if the score isn't changed - I'd completely forgotten that was in there, but it is and has been since something like 2.0 Beta 5 or Beta 6. So there must be something else wrong here - are you sure that the change-once-a-day setting is actually active? And that the difficulty actually did go down? (since the scores were already at 100, it could be easy not to notice that you'd accidentally disabled that once-a-day option)

I see the same behaviour here: in spite of "change-once-a-day setting" is configured the difficulty changes every time repeating a flashcard. I also wondered about that but it didn't disturb me very much.

 

[sinoreen]

when in Oxford E-C and looking up an english word that has separate entries for the same headword, only one result is found. Example: there are two entries in Ox E-C for "order" (one for the noun and one for the verb - noun is order1 and verb is order2). However, when you look up the word only the second entry is found and the entry list also starts with this entry. but when I tap on the ↑ in the entry list then I find the order1 (noun) just right before the verb entry. also when I tap on the toggle list mode button to look at 果，only one result is shown, namely order2 (the verb). I have no other specific example for you right now, but I know it happened with other words too. I'm not sure though, whether this happens in other dicts too.

By the way, the thing with duplicate cards for existing FCs from User dicts now is clear to me too. thanx

 

[marsch]

Re "only change score once a day" again. Yes, all my profiles have that clicked, and yes, the difficulty did go down twice within one day.
Could there be a difference in how you evaluate the profile for setting the checkbox vs. when you're calculating scores? I think I had a problem in an earlier beta of 2.0 when a checkbox was apparently ticked but didn't have an effect, so I unticked it, ticked it again and then it worked. At that time I blamed it on switching to a new beta and thought maybe data wasn't correctly shifted over... Just a guess...

 

[mikelove]

daniel123 / marsch - I'm looking at the code carefully and there's just no way that the difficulty could be changing if the change-once-a-day check fails. However, as with the regular score changes, the score and difficulty could decrease twice in one day if there was an increase in between - if you answer the card incorrectly, then correctly, then incorrectly again, you'll see both of those incorrect answers reflected in the score / difficulty. And that's by design; if we didn't do it that way, but simply changed the score / difficulty once and refused to change it again regardless of what happened that day, you wouldn't be penalized at all for answering a card incorrectly as long as you'd answered it correctly within the past day, which doesn't really make sense.

To be honest, I'm not sure if the Automated scoring algorithm is such a good idea for Frequency-adjusted tests anyway - it's really designed more for Repetition-spaced ones, for frequency changes we'd probably be better off with something else that was much more gradual - perhaps something to consider in 2.1. The two new "scale" options improve matters somewhat but obviously there's a lot more we could do.

sinoreen - that's a longstanding problem, actually, but I'm nervous about fixing it because of the unintended consequences it might have on other E-C searches - it took us a long time to get that algorithm right and fixing an easy-to-work-around issue like this isn't worth causing severe problems in other searches in the process. Definitely something we'll fix eventually but it's probably too late to do anything about it in 2.0.1.

 

[mikelove]

sinoreen - I checked again it turns out there was actually an easily-fixable bug at work in that particular "order" case - won't help with every single instance where that happens, but the fix should get rid of quite a few of those errors at least.