Same Finger Skipgrams (SFS) and other skipgrams? (=secondary_bigrams?)

[fohrloop]

I'm looking for a way to calculate cost for Same Finger Skipgrams (SFSs). What I mean by those is that for example DE is a same finger bigram (SFB) in QWERTY, but D_E is a Same Finger Skipgram where _ can be any key on any other finger than left middle, for example DIE.

I see that the finger_repeats takes care of the SFB's together with manual_bigram_penalty which may be used to penalize the 2u vertical and/or diagonal SFBs even more than what's available in finger_repeats.

In addition, there is nice support for Full (and Half) Scissor Bigrams ("scissors") with manual_bigram_penalty.

I'm looking for the best way to:

• Use existing config for finger_repeats to get similar skipgram costs calculated based on trigrams (just omit the middle character of each trigram)? Perhaps by using some weight of 0.7 for skipgrams (compared to bigrams).
• Use existing config for manual_bigram_penalty to get similar skipgram costs in a similar fashion?

Is it exactly what the trigram metric secondary_bigrams was designed to solve? If so, which defines the collection of bigram metrics to be evaluated (the list of bigram metrics in the used evaluation config yaml or something else, like list of all bigram metrics defined in the source code?). This seems to be enabled by default but has really small weight (0.1) compared to other metrics; what's the reason for the small default weight?

[dariogoetz]

The secondary_bigrams metric takes every trigram and evaluates the first and last symbol as a bigram, so it should exactly be the "skipgrams" that you mention.

All bigram metrics that implement the "individual_cost" function are evaluated and their result summed up.

Regarding the weight, it was the result of a long series of trial and error and personal preference.

Note also, that the finger_repears metric already takes into account the "distance" of the repeat, i.e. the 2u has double the cost than a 1u repeat. Also diagonals are accounted for with a parameter lateral_factor.

[fohrloop]

secondary_bigrams: selected bigram metrics

Yeah that's great! The secondary_bigrams is really what I was after, then!

It would be nice to be able to specify explicitly which bigram metrics the secondary_bigrams handles. Do you think it would be difficult to add? I mean, something like:

  secondary_bigrams:
    enabled: true
    ...
    params:

      metrics: ["finger_repeats", "manual_bigram_penalty"] # added

?

[fohrloop]

secondary_bigrams: weights

Yeah I actually did some back-of-an-envelope calculations and noticed only then that the weight of each bigram is actually used internally in layout_evaluation/src/metrics/trigram_metrics/secondary_bigrams.rs, which makes 0.1 about the right order of magnitude for secondary_bigrams (less than 1.0 to make skipgrams less important than bigrams, and if it's 0.1 it's not too small to make them not affect the outcome). I would not have asked if I would saw the bigram weights being used there before :)

About finger_repeats distance metrics

Note also, that the finger_repears metric already takes into account the "distance" of the repeat, i.e. the 2u has double the cost than a 1u repeat. Also diagonals are accounted for with a parameter lateral_factor.

Thank you for the suggestion. My problem was that I did not want to use linear scale penalty; meaning that if 1u is getting cost of 1.0, I would not want 2u SFB's get penalty of 2.0, but higher; for example 4.0. This is not possible currently with just the finger_repeats . It would be possible, if there was some distance_exponent parameter (default: 1.0), which would make:

metric_cost = finger_factor * (same_key_offset + direction_factor*dist_in_line + lateral_factor*dist_lateral)

to be

metric_cost = finger_factor * (same_key_offset + direction_factor*(dist_in_line**distance_exponent) + lateral_factor*(dist_lateral**distance_exponent))

but now I'm just using a workaround with the manual_bigram_penalty and listing all 2u (or larger) SFB's to add extra penalty :D

[dariogoetz]

For some time, I actually used distance squared :) At some point I figured, linear would suffice, though.

If you are not afraid of modifying the code, you could just square it in the metric. Or even introduce a distance_exponent parameter. It's not very complicated!

[dariogoetz]

Selecting only some metrics should be possible by comparing with the name() method of the metrics. This is meant to be used as a label for the results summary, but you can also use it fir filtering.