zhaizhai
commented
8 years ago Regarding the first point: yes, it happened to me a few times that I got something wrong because it thought my stroke was an earlier stroke. But also, is there any reason to ever classify a stroke as something that was already drawn? Obviously that's not what the user wanted to do...
For the second one, sure, we can play around with the scoring parameters. I'm not sure exactly what it should be, but my feeling is that it makes sense for the stroke order penalty to be somewhat capped so that you don't get a terrible score for e.g. writing an entire radical correctly but out of order. But anyway, it's up to you how exactly you want to do it. The more important part of the change for me is that it doesn't give away (as a hint) the proper next stroke for a correct but out-of-order stroke. What do you think of that?
On Sun, Jun 12, 2016 at 9:23 PM, Shaunak Kishore notifications@github.com wrote:
I'm not sure whether we want ed33fd7 https://github.com/skishore/makemeahanzi/commit/ed33fd7afc2c91bd401458533dda020c854f5474
- whether or not this is a common failure mode is an empirical question and I don't think we have enough data. Is it something that you run into when you use the app?
For d5b8065 https://github.com/skishore/makemeahanzi/commit/d5b8065bc8c7004bdbf6a75309a6419365dfde80, I think we should have a stroke-order weight setting that users can set freely. As you saw, right now, the stroke order penalty is k * where k = 2. What do you think exposing k through a "stroke order strictness" setting that ranges from, say, 0 to 2?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/skishore/makemeahanzi/pull/4#issuecomment-225486707, or mute the thread https://github.com/notifications/unsubscribe/ACFAdyhgQUoF1hwXHuGOr_B9fdR-YdaOks5qLNsqgaJpZM4Iz-VA .
I'm not sure whether we want ed33fd7 - whether or not this is a common failure mode is an empirical question and I don't think we have enough data. Is it something that you run into when you use the app?
For d5b8065, I think we should have a stroke-order weight setting that users can set freely. As you saw, right now, the stroke order penalty is k * (recognized index - correct stroke index) where k = 2. What do you think exposing k through a "stroke order strictness" setting that ranges from, say, 0 to 2?