unbalancing_factor calculations

[fohrloop]

I'm spinning this from your reply (thanks for pointing me to the calculations!)

In the layout_evaluation/src/metrics/bigram_metrics/movement_pattern.rs it shows

        let unbalancing_factor = 1.0
            + (self.unbalancing_factor
                * ((k1.key.unbalancing.0 - k2.key.unbalancing.0).abs()
                    + (k1.key.unbalancing.1 - k2.key.unbalancing.1).abs()));

If I understand correctly, the k1.key.unbalancing.0 and k2.key.unbalancing.0 refer to the to consecutive keys' (k1 and k2) unbalancing values from the keyboard configuration. For example from config/keyboard/chocolad.yml

  unbalancing_positions:
    - [[0, 0.5], [0,   0], [0,  0], [0, 0.5], [1,    1],                  [-1,    1], [0, 0.5], [0, 0], [0,   0], [0, 0.5]]
    - [[0,   0], [0,   0], [0,  0], [0,   0], [1,    0],                  [-1,    0], [0,   0], [0, 0], [0,   0], [0,   0]]
    - [[0,   0], [0,   0], [0,  0], [0,   0], [1,   -1],                  [-1,   -1], [0,   0], [0, 0], [0,   0], [0,   0]]
    - [                             [0,   0], [0,    0],  [0, 0], [0, 0], [0,   0],   [0,   0],                           ]

I understand, that if you have: k1: [0, 0.5] and k2: [1, 1], the cost would be:

1.0 + self.unbalancing_factor * (1+0.5)

and the self.unbalancing_factor is probably the unbalancing_factor from config/evaluation/default.yml, so this would be then

1.0 + 0.5*1.5  = 1.75

right?

Then a related question: Why the same finger bigram does not have cost? Is is somehow handled differently? I mean, there is

        if f1 == Finger::Thumb || f2 == Finger::Thumb || h1 != h2 || f1 == f2 {
            return Some(0.0);
        }

but how about the left index finger bigrams here:

If cost is 0.0 when f1 == f2, doesn't it not mean that the index finger bigrams also have no unbalancing_factor cost?

In addition, how important do you consider the unbalancing_factor as there's also key_costs in the keyboard configuration?

[dariogoetz]

I understand, that if you have: k1: [0, 0.5] and k2: [1, 1], the cost would be:

1.0 + self.unbalancing_factor * (1+0.5)

and the self.unbalancing_factor is probably the unbalancing_factor from config/evaluation/default.yml, so this would be then

1.0 + 0.5*1.5  = 1.75

right?

Yes, exactly. This part is supposed to evaluate how much hand movement is involved in hitting the bigram keys. In this exampe, the hand needs to move one unit to the right and half a unit up, totaling to 1.5.

Then a related question: Why the same finger bigram does not have cost? Is is somehow handled differently? [...]

The movement_pattern metric is only supposed to evaluate non-SFB bigrams. All SFB-bigrams are evaluated in the finger_repeats metric. There you will find another condition containing k1.key.finger != k2.key.finger.
You are right, however, that the finger_repeats metric does not make use of the unbalancing_keys. It might be a good idea to also incorporate them there.

In addition, how important do you consider the unbalancing_factor as there's also key_costs in the keyboard configuration?

The key_costs table in the keyboard configuration is mainly used by the corresponding unigram metric key_costs. It operates on different data than the movement_patterns metric (unigrams vs. bigrams) and therefore has different nuances.
Bigram metrics are more concerned with movement between keys, whereas unigram metrics are more concerned with overall difficulty of accessing a key. These effects are somewhat intertwined, of course, but imagine having to move from a left-most key (dragging the hand to the left) to a right-most key (dragging the hand to the right) for consecutive keys: It is more cumbersome doing that than when hitting other keys in between. This can be expressed in a bigram metric, but not in a unigram metric.

To which extent you consider this effect important can be encoded in the unbalancing_factor parameter of the metric. Set it to 0 to totally ignore this effect.

[fohrloop]

This is fascinating. Thank you for the explanation!

You're right it would make sense to add the unbalancing_factor also to the SFB/finger_repeats metrics.