New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stoke Order Error in KanjiPad #665

Closed
ChristopherJonJensen opened this Issue May 4, 2016 · 9 comments

Comments

Projects
None yet
3 participants
@ChristopherJonJensen

ChristopherJonJensen commented May 4, 2016

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.
aedict 5 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.
aedict 10 strokes

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

@mvysny

This comment has been minimized.

Show comment
Hide comment
@mvysny

mvysny May 4, 2016

Owner

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.

Owner

mvysny commented May 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mvysny

mvysny May 4, 2016

Owner

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

Owner

mvysny commented May 4, 2016

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

@mvysny

This comment has been minimized.

Show comment
Hide comment
@mvysny

mvysny May 4, 2016

Owner

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.

Owner

mvysny commented May 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ChristopherJonJensen

ChristopherJonJensen May 5, 2016

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)

ChristopherJonJensen commented May 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nirdavo

nirdavo May 6, 2016

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).

nirdavo commented May 6, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mvysny

mvysny May 7, 2016

Owner

@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?

Owner

mvysny commented May 7, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@ChristopherJonJensen

ChristopherJonJensen May 7, 2016

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)

ChristopherJonJensen commented May 7, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nirdavo

nirdavo May 7, 2016

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

nirdavo commented May 7, 2016

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

@mvysny

This comment has been minimized.

Show comment
Hide comment
@mvysny

mvysny May 8, 2016

Owner

Thank you for confirmation, fixed in Aedict 3.39.18

Owner

mvysny commented May 8, 2016

Thank you for confirmation, fixed in Aedict 3.39.18

@mvysny mvysny closed this May 8, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment