Stoke Order Error in KanjiPad

[ChristopherJonJensen]

As of the last few days, I've noticed an odd behaviour in the KanjiPad, which I'm assuming must have been tied to a recent update, as it certainly wasn't happening before. Specifically, when I input a character with fewer than ten strokes, the stroke number is counted correctly on the KanjiPad itself (bottom half of the screen), but the list of candidate characters on the top half of the screen begins one short of the correct count. The user is then forced to scroll down (sometimes for quite a while) before finding the candidates with the correct number of strokes.

Oddly, this issue only occurs for characters featuring between 2-9 strokes. When a character with 10+ strokes is inputted, the candidate list begins in the correct position.

I am using an LG G3, with the latest version of AEDict and Android version 6.0 (Marshmallow).

[mvysny]

Thank you for letting me know. While fixing #662 I haven't realized the implications of the fix, which have now emerged.

The problem is as follows: with characters with less than 10 strokes, it is feasible (in terms of CPU) to also perform a fuzzy search which will also match characters with +-1 stroke. The characters are then sorted, closest matching first. Naturally, characters with less or more strokes are pushed at the end of the result list, because they are deemed inaccurate.

However, now that #662 is fixed, the list is post-sorted by the stroke number, and characters with one stroke less are now at the beginning of the list.

Perhaps I should show kanjis with expected stroke count first (say, if you draw a kanji with 5 strokes, I should show kanjis with 5 strokes first, then kanjis with 4 strokes, then kanjis with 6 strokes, then kanjis with 3 strokes and finally kanjis with 7 strokes). What do you think?

If you do not like this solution, I can also add an option to turn off the sort-by-stroke-number and to enable back the sort-by-accuracy. Please let me hear your opinion.

[mvysny]

Also please allow me to thank you for your kind support at Patreon - highly appreciated. Thanks.

[mvysny]

You can try the "old" algorithm on Aedict Online at https://aedict-online.eu - the sorting algorithm there has not yet been updated and still sorts based on accuracy only.

[ChristopherJonJensen]

Hi Martin,

Thanks for the prompt reply. Also, it's my pleasure to support AEDict on
Patreon, as it's a piece of software that I use every single day and that
has simplified my language learning process considerably.

As for the current issue, I think that your proposed solution of beginning
with the "correct" stroke count probably makes the most sense. Another
option would be to add "Sort by Stroke Order" checkbox or menu option, in
order to give users the ability to disable the new sorting feature.

Typically, I wouldn't have bothered you about such an issue, but I noticed
that it actually had a marked effect on my translation output. I'm working
on a pretty technical text right now, and having an additional 5+ seconds
added to each search (scrolling to find the correct stroke count) is
actually kind of non-trivial over hours of work and 10s or 100s of
dictionary look-ups.

Anyway, I appreciate the reply and the tireless work you've been investing
into AEdict.

Best wishes,
Chris
On May 4, 2016 4:14 PM, "Martin Vysny" notifications@github.com wrote:

Thank you for letting me know. While fixing #662
#662 I haven't realized the
implications of the fix, which have now emerged.

The problem is as follows: with characters with less than 10 strokes, it
is feasible (in terms of CPU) to also perform a fuzzy search which will
also match characters with +-1 stroke. The characters are then sorted,
closest matching first. Naturally, characters with less or more strokes are
pushed at the end of the result list, because they are deemed inaccurate.

However, now that #662 #662 is
fixed, the list is post-sorted by the stroke number, and characters with
one stroke less are now at the beginning of the list.

Perhaps I should show kanjis with expected stroke count first (say, if you
draw a kanji with 5 strokes, I should show kanjis with 5 strokes first,
then kanjis with 4 strokes, then kanjis with 6 strokes, then kanjis with 3
strokes and finally kanjis with 7 strokes). What do you think?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#665 (comment)

[nirdavo]

I was on the verge of reporting this very same behavior (which is kind of a nuisance :-)).
I propose a different solution: Rather than jumping though hoops to resort the stroke order 5-4-6-3-7, like you suggested), why not rather honour a checkbox that is already there?
I thought the '+- 2 strokes' checkbox was for exactly this purpose: If I want a fuzzy search, show me fuzzy results (with all implications that I would have to scroll), or if I want exakt stroke count matches, show only those.
While I agree that it might be a good idea to perform the fuzzy search anyway, just discard the 'wrong' stroke count kanji for display when the checkbox is unticked.
If my requested kanji is not shown, I can always tick the box (and get 'all' results) to see whether I actually did forget a stroke (or make an additional one).

[mvysny]

@nirdavo I like this idea a lot, because this makes the UI actually consistent with the search results. So, if the +- 2 strokes is unchecked, only the kanjis matching the exact stroke count will be shown. If the +-2 strokes is checked, the kanjis will be shown in the order of 5-4-6-3-7. @nirdavo @ChristopherJonJensen what do you think?

[ChristopherJonJensen]

Sounds like a comprehensive solution to the problem. Thanks, Martin!
On May 7, 2016 2:00 AM, "Martin Vysny" notifications@github.com wrote:

@nirdavo https://github.com/nirdavo I like this idea a lot, because
this makes the UI actually consistent with the search results. So, if the
+- 2 strokes is unchecked, only the kanjis matching the exact stroke count
will be shown. If the +-2 strokes is checked, the kanjis will be shown in
the order of 5-4-6-3-7. @nirdavo https://github.com/nirdavo
@ChristopherJonJensen https://github.com/ChristopherJonJensen what do
you think?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#665 (comment)

[nirdavo]

Yes, sounds good!

Am 07.05.2016 08:00 schrieb "Martin Vysny" notifications@github.com:

@nirdavo I like this idea a lot, because this makes the UI actually
consistent with the search results. So, if the +- 2 strokes is unchecked,
only the kanjis matching the exact stroke count will be shown. If the +-2
strokes is checked, the kanjis will be shown in the order of 5-4-6-3-7.
@nirdavo @ChristopherJonJensen what do you think?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub