Skip to content

Show combined costs of bigram pairs when evaluating the layout - #97

Open
SolidAlloy wants to merge 1 commit into
dariogoetz:masterfrom
SolidAlloy:combined_bigrams
Open

Show combined costs of bigram pairs when evaluating the layout#97
SolidAlloy wants to merge 1 commit into
dariogoetz:masterfrom
SolidAlloy:combined_bigrams

Conversation

@SolidAlloy

Copy link
Copy Markdown
Contributor

When a layout is evaluated, the most frequent bigrams are shown, and a reversed bigram is treated as a separate one. For example, "ng" can be shown in the list, but "gn" may not. The issue is that there may be a bigram that seems more important when considered separately. For example, a bigram "oa" with a cost of 1.2. "ng", on the other hand, may have a cost of 0.8 and may not even be shown in the list. However, if we sum up "ng" and "gn", the combined cost becomes 1.4, putting it in the first place, above "oa". In my opinion, this is more important when considering which key positions to tweak.

The bigram metrics after the change look like this:
1.94 Sfbs | Worst: йо/ой (10.10%), юо/ою ( 9.32%), юу/ую ( 7.48%); Worst non-fixed: йо/ой (10.10%), юо/ою ( 9.32%), юу/ую ( 7.48%)
1.21 Lsbs | Worst: нк/кн (16.58%), кл/лк (15.24%), лг/гл ( 7.16%); Worst non-fixed: нк/кн (16.58%), кл/лк (15.24%), лг/гл ( 7.16%)

The reason this is a pull request without an issue opened is that I already changed the code to be able to see the combined bigrams. If you don't agree with the change or would like to implement it yourself, feel free to close this one.

@dariogoetz

Copy link
Copy Markdown
Owner

First of all, thank you for your contributions (also the other ones :) ).

Either I don't understand your argument or I disagree with it. The "direction" of the bigrams matter very much. Their frequencies in the corpus may be very different (e.g. "ng" being much more frequent than "gn"). Also, the resulting finger movement can be different (e.g. going inwards vs. going outwards).
This means that one specific direction of the bigram can have high cost (because it is very frequent or badly placed or both) while the other one plays a minor role in total.

@SolidAlloy

Copy link
Copy Markdown
Contributor Author

I indeed missed an important detail when considering this feature. Yes, the direction matters when you consider how harmful a bigram is. For example, whether it can be raked down. And my change makes it unclear which of the two possible directions is more frequent. At the same time, when the user considers which keys need to change places because of frequent SFBs, the combined frequency of both directions is important, don't you think? I could change the output to have the following look:
Worst combined: ne/en (10.10%), ... ; Worst individual: ne (7.45%), wa(4.35%), en (5.75%) ... ; Worst non-fixed: ...

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants