An alternative (more objective) Scoring System

[kjoetom]

Hello

I have thought a lot about how to score layouts in the last few weeks and would like to share my thoughts with you. This post will probably be a bit longer and I hope that I don't annoy anyone with it or I would like to ask for your understanding in advance.

To create good language-specific layouts, we basically need 2 things. On the one hand, we need to know which bigrams occur in which frequency in a language (fortunately, these are available for some languages). On the other hand, we also need an evaluation of the writing movements as objectively as possible with respect to their speed and flow.

So far, we have included subjective assessments of how good or pleasant it is to "write" the motion sequences between the individual positions on the layout. In principle, this is a good approach.

However, the risk here is that small deviations in the judgments can potentially have a big impact on the final "best" layout.

The idea was therefore to develop a scoring system that is as objective as possible.

The following part of this paper will only deal with the connection between two positions on the 8-VIM layout, i.e. that part of the scoring which is independent of the languages and their bigram frequency. I would therefore like to call this part of the score the bi-position score (BiPos score) and clearly distinguish it from the final bigram score.

By the way, this is my definition of positions, which I will always refer to in the following:

The following criteria should be considered in the score:

• objective duration of the "writing" of positions
• objective duration of the "writing" of their respective connection (transition)
• definition of individual movement flow disturbances
• diacritical signs can also be quantified and taken into account in scoring

My principle thought was: if we can describe the movements somehow mathematically, then we know the distances and so we can compare and evaluate all movement sequences with regard to their distances. But this was a mistake in my thinking (more about this later).

So I came up with the following model to be able to describe every movement with only 3 elements:

• a small arc of a quarter circle (red), in the following expressed as "c
• a large arc of a quarter circle (green), in the following expressed as "U".
• a straight line (yellow), hereafter expressed as "I".

All letters or "written positions" start at one of the four black dots in the circle (α, β, γ, δ), then run outside the circle with a right turn (clockwise) or left turn, and end again at one of the black dots in the circle.
The transition from the first to the second position occurs inside the circle and can be described with the same three elements. However, it soon becomes clear that in addition to the pure path distances, there are also interfering factors that must be taken into account.

And this is how the model looks like:

There is nothing new at all. I just tried to put everything on a more objective basis and make it mathematically describable.

A position in layer 1 can be described with "ccc" or one in layer 3 with "cc IUI cc".
The bi-position connection "F-->T" (starting at the "γ" point) is therefore "ccc II cc IUI cc" or "7c + 4 I + 1U", respectively.
The bi-position connection "B-->C" (starting at the "α" point) is therefore "ccc ccc" or "6c", respectively.
(Obstacles of the transition are not considered yet in these examples.)

When I now checked how well the path lengths correlate with the actual writing times, it immediately turned out that I had made a mistake in thinking here. In practice, the 3 elements are obviously written at different speeds, which actually is not really surprising.

This now meant that I had to find out the actual duration of the elements by measuring numerous representative movement sequences in time and then correlating them with the elements.

But before you can do that, you have to think about the disturbances that can occur during the transition between the positions (inside the circle), so that you can include them in the correlation.

I came up with several variants and in the end one turned out to be useful. According to this, there are 2 interfering factors - rotation change and forced stop, which can occur in different combinations:

• the rotation direction changes 1 time, because the first and second position (letter) have a different rotation direction
• a "c" connection between two "likewise rotating positions" requires a brief counter-rotation (the direction of rotation changes 2 times)
• a movement must stop because the first position ends at the same point where the second position starts (forced stop). In addition, there may also be a change in rotation.

So there were 5 variables that went into the "mathematical model" (ok, that's kind of an exaggeration):

• c (small quarter arcs)
• I (short straight connections)
• U (large quarter arcs)
• R (rotation changes)
• F (forced stops)

E.g. the full expression for the F-->T connection mentioned above in the model is "7c + 4 I + 1U + 0R +0F".
And the full expression for the B-->C connection would be "6c + 0 I + 0U + 1R + 1F"

I also specified 4 connection qualities, which must be reflected in the results as different durations. Bad connections must prove to be longer lasting than better ones. This was then also confirmed. The following graphic gives an overview of these 4 connection qualities (the black dashed line marks the end of the first position):

• very good (green)
• good (blue)
• less good (violet) <-- here the direction of rotation changes 2 times (let's call this a RcR-Transition)
• bad (red) <-- these are the forced stops (or fullstops)

And these are the resulting times of the model:

The numbers are currently milliseconds, based on my own write speed. But for comparability, we'd need to think about some standardization (e.g., the duration of writing a particular connection). Also, we would need to use the reciprocals when multiplying by the bigram frequencies.

• c (small quarter arcs) = 97 ms
• I (short straight connections) = 13,3 ms
• U (large quarter arcs) = 113,4 ms
• R (rotation changes) = 96,7 ms
• F (forced stops) = 212,6 ms

And for the positions/letters of the 4 layers, this results in the following 4 write durations:

• L1 = 290,9 ms
• L2 = 414,5 ms
• L3 = 527,9 ms
• L4 = 641,3 ms

And for the duration of the specified 4 connection qualities

• very good = 26,6 ms and 97,0 ms
• good = 123,2 ms and 193,6 ms
• less good = 290,3 ms
• bad = 309,6 ms and 406,3 ms

Tabular overview for calculating the BiPos-Scores:

The BiPos score for the connection "F-->T", for example, is calculated as follows: 290.9 + 26.6 + 527.9 = 845.4 ms
The BiPos score for the connection "B-->C" is then: 290.9 + 309.3 + 290.9 = 891,1 ms

[kjoetom]

I wanted to try out what optimal layouts would result based on this alternative score when using @Glitchy-Tozier's script. But as it turned out unfortunately, the score is not directly transferable into this script.

While the duration for the transition and the writing of the 2nd position can easily be entered, I don't know how one could consider the duration of the first letter.

[Edit 13.3.2022:]
On closer inspection, one possibility would be to sum the duration of the transition and the duration for the first position and then enter this value as "flow_evenPos_xx". The duration for the second position could be entered in "Lx_comfort".
The script would then simply add the two values and calculate the total duration of a bi-Pos connection (if layerVsFlow = 0.5).

But this total duration of a biPos connection would then have to be included in the bigram score calculation as the reciprocal value. And we can't just take the reciprocals of the two values and add them together, because "1/a + 1/b ≠ 1/a+b".

[kjoetom]

Hello @Glitchy-Tozier,
if I provided a list in which all position combinations are assigned to their respective scores (similar to the file with the bigram frequencies), could this be integrated into the script as an (alternative) scoring basis without much effort?
Besides the fact that we could try out this new score, an additional advantage would be that in the future "asymmetric scores" could be taken into account, i.e. differences that arise when the layout is rotated.

Thanks,
kjoe

[Glitchy-Tozier]

Hi @kjoetom, I haven't had the energy to read all of your post, but let me answer anyways :p

I think it should be doable. There's two functions where cost is calculated (both do the same thing, with one being used regularly while the other one only is used when multiprocessing)

1. https://github.com/Glitchy-Tozier/8vim_keyboard_layout_calculator/blob/main/8vim_keyboard_layout_calculator.py#L744-L770
2. https://github.com/Glitchy-Tozier/8vim_keyboard_layout_calculator/blob/main/8vim_keyboard_layout_calculator.py#L822-L847

In those places, two things happen:

1. We get the letters's positions

firstLetterPlacement = asciiArray[ord(bigram[0])]
secondLetterPlacement = asciiArray[ord(bigram[1])]

Compared to the layout in the original post (By the way, this is my definition of positions, which I will always refer to in the following:), the numbering is the following:

• F = 0
• G = 1
• A = 2
• B = 3
• …
• E = 7
• N = 8
• O = 9

2. We calculate the scores[k] from

1. bigramFrequency[j]
2. The two letters's positions

Instead of the if-tree, you could simply add your own rating-system instead of the if-tree found here.
Does that answer your question? I'd be happy to receive a Pull-Request. Alternatively, if you are scared of coding, you could also precisely explain to me exactly what I need to do with the two letters's positions to arrive at your final score.

[kjoetom]

Hi @Glitchy-Tozier, thank you for the quick reply.
To be honest, my "coding" knowledge ended with Basic (in about 1980) ;-) and a little bash shell scripting now. With python I have no experience at all and your script is kind of complex. In other words - I am scared.

Would it be doable to add a setting within the script defining, whether der script-internal scoring is used or a script-external scoring given in an external file...

... let's say a subfolder "extra_scores" in 8vim_keyboard_layout_calculator-main/

... and a file "extra-score-1.txt" containing the scoring information for all 1024 Pos-Pos-Connections like this

AA 1,47324352124221
AB 1,28959796656949
AC 1,64368682817761
AD 1,41834021625637
AE 1,1466620649946
...
87 0,628159997394774
88 0,668766573784948

or

L1-2_L1-2 1,47324352124221
L1-2_L1-3 1,28959796656949
L1-2_L1-4 1,64368682817761
L1-2_L1-5 1,41834021625637
L1-2_L1-6 1,1466620649946
...
L4-8_L4-0 0,628159997394774
L4-8_L4-1 0,668766573784948

... whatever better fits the needings of the script.

I could e.g. shift "my Positions" in a way that A is the first letter (A = 0) and so on.

Btw., I think I do not understand the concept of pull requests - what would I need to do for that. Last time you wrote PR I was thinking this means Personal Response ;-)

[Edit]
Ah, I think I get it now:

3-3 1,47324352124221
3-4 1,28959796656949
3-5 1,64368682817761
3-6 1,41834021625637
3-7 1,1466620649946
...
26-25 0,628159997394774
26-26 0,668766573784948

[Glitchy-Tozier]

To be honest, my "coding" knowledge ended with Basic (in about 1980) ;-) and a little bash shell scripting now. With python I have no experience at all and your script is kind of complex. In other words - I am scared.

Would it be doable to add a setting within the script defining, whether der script-internal scoring is used or a script-external scoring given in an external file...

Weren't you the guy that created an excel-script that immediately found amazing layouts?
Anyways, all I need (I think) is you to list the position-scores a certain way. I think the most performant would be a list of lists of scores.

• The overarching list would contain 32 lists, one for every first-letter-position
• Those 32 lists would themselves contain the 32 scores, one for every second position

This would result in me being able to efficiently grab the score like this: score = scorelist[firstLetterPosition][secondLetterPosition].

As an example, this is the list that would be created for a layout that only has 4 positions:

# The first score (3.309) is letter 1 = pos 0, letter 2 = pos 0
# The first score (2.933) is letter 1 = pos 0, letter 2 = pos 1
scores_list = [
    [3.309, 2.933, 0.889, 0.099] # A list of all possible scores after the 0th position
    [4.949, 9.994, 8.909, 1.090] # A list of all possible scores after the 1st position
    [3.393, 4.748, 0.320, 2.780] # A list of all possible scores after the 2nd position
    [1.319, 2.944, 3.389, 3.202] # A list of all possible scores after the 3rd position
]

Does that make sense?

Btw., I think I do not understand the concept of pull requests - what would I need to do for that. Last time you wrote PR I was thinking this means Personal Response ;-)

I also only learned about it a few months ago, and I'm also no expert, but this is roughly how it goes:

1. You copy my project by clicking on the fork-button (which is next to the star-button)
2. You make a local clone of your copy (you do that by running git clone https://github.com/kjoetom/8vim_keyboard_layout_calculator.git or using an IDE)
3. You edit that local clone
4. You somehow synchronize it back to your github-copy (the fork)
5. Github will promt you to create a PR, which is a request to update my project so that I incorporate the changes you made to your copy (the fork)

That being said, you can simply send me the list via a comment and I will add it to the project.

[Glitchy-Tozier]

By the way, I think you don't even need to make a local copy of the fork. You might be able to simply edit the file within GitHub.

1. Go to my repository
2. Find the file you want to edit
3. Click on the edit-button, edit, and save
4. GitHub will ask you whether you want to create a PR.

[kjoetom]

Hello @Glitchy-Tozier,

thank you for your great support. I really appreciate this and I know that so much support is not something to take for granted.

Attached you will find a zip file with the following content (--> score-lists.zip):

1. the file "check_overview-position-connections_in-the-score", which shows an overview, in which order I have entered the single scores. This is only to check if I have understood your suggestion correctly.

2. the file "bipos-score-list_GlitchyTozier", in which I have entered your score (hopefully correctly). With this you can quickly check, if the score of a layout with the new procedure comes to the same result as the one, which was already included in the script by you.

3. and finally the file "bipos-score-list_kjoe", which contains my "new bipos-score"

I hope that this new score also provides really good layouts (although I'm not sure about that yet).
My goal is that all parties involved can agree as soon as possible on a good German layout (or also for other languages), which can then be used in this form from now on, so that no one has to relearn in the future. In the end it doesn't matter on which basis the layout was developed. It should simply feel good and fluent in the respective language.

If we have several good layouts, we can then include the diacritical marks in the overall scoring. But i wouldn't bother with the script for that. For that, an excel-based approach might be easier to handle.

By the way, I am the guy with the LO calc script that generates passable layouts using the non-linear solver (they are all better than the original 8pen layout). But the quality is not at all comparable to that of your layout generator.

kjoe

[Glitchy-Tozier]

Update: It seems like the files are structured correctly.
If you're interested, you can compare the original output to the one generated by "bipos-score-list_GlitchyTozier":

Old log:

#######################################################################################################################
#######################################################################################################################
                                                The top 5 BEST layouts:


      ⟍  ▓                k ⟋
      z ⟍  x            g ⟋  ▓
        q ⟍  p        u ⟋  y
          c ⟍  r    n ⟋  m
            t ⟍     ⟋  s
                ⟍ ⟋
                ⟋ ⟍
            o ⟋     ⟍  a
          f ⟋  e    i ⟍  l
        v ⟋  d        h ⟍  w
      ▓ ⟋  j            b ⟍  ▓
      ⟋  ▓                ▓ ⟍
ailhwb-- eodfjv-- trcpqxz- nsumgyk-
AILHWB-- EODFJV-- TRCPQXZ- NSUMGYK-
─────────────────────────────────────────────> Layout-placing: 1
─────────────────────────────────────────────> Score: 3425053010.0    ~91.01 %


      ⟍  ▓                k ⟋
      ▓ ⟍  f            b ⟋  ▓
        j ⟍  p        u ⟋  y
          c ⟍  r    n ⟋  m
            t ⟍     ⟋  s
                ⟍ ⟋
                ⟋ ⟍
            o ⟋     ⟍  a
          g ⟋  e    i ⟍  l
        v ⟋  d        h ⟍  w
      ▓ ⟋  x            z ⟍  ▓
      ⟋  q                ▓ ⟍
ailhwz-- eodgxvq- trcpjf-- nsumbyk-
AILHWZ-- EODGXVQ- TRCPJF-- NSUMBYK-
─────────────────────────────────────────────> Layout-placing: 2
─────────────────────────────────────────────> Score: 3425001203.07    ~91.01 %


      ⟍  ▓                z ⟋
      ▓ ⟍  f            k ⟋  ▓
        j ⟍  p        u ⟋  y
          c ⟍  r    n ⟋  m
            t ⟍     ⟋  s
                ⟍ ⟋
                ⟋ ⟍
            o ⟋     ⟍  a
          g ⟋  e    i ⟍  l
        v ⟋  d        h ⟍  w
      ▓ ⟋  x            b ⟍  ▓
      ⟋  q                ▓ ⟍
ailhwb-- eodgxvq- trcpjf-- nsumkyz-
AILHWB-- EODGXVQ- TRCPJF-- NSUMKYZ-
─────────────────────────────────────────────> Layout-placing: 3
─────────────────────────────────────────────> Score: 3424649630.38    ~91.00 %


      ⟍  ▓                k ⟋
      z ⟍  f            b ⟋  ▓
        q ⟍  p        u ⟋  y
          c ⟍  r    n ⟋  m
            t ⟍     ⟋  s
                ⟍ ⟋
                ⟋ ⟍
            o ⟋     ⟍  a
          g ⟋  e    i ⟍  l
        v ⟋  d        h ⟍  w
      ▓ ⟋  j            x ⟍  ▓
      ⟋  ▓                ▓ ⟍
ailhwx-- eodgjv-- trcpqfz- nsumbyk-
AILHWX-- EODGJV-- TRCPQFZ- NSUMBYK-
─────────────────────────────────────────────> Layout-placing: 4
─────────────────────────────────────────────> Score: 3424505238.9    ~90.99 %


      ⟍  ▓                k ⟋
      ▓ ⟍  f            b ⟋  ▓
        z ⟍  p        u ⟋  y
          c ⟍  r    n ⟋  m
            t ⟍     ⟋  s
                ⟍ ⟋
                ⟋ ⟍
            o ⟋     ⟍  a
          g ⟋  e    i ⟍  l
        v ⟋  d        h ⟍  w
      ▓ ⟋  j            x ⟍  ▓
      ⟋  q                ▓ ⟍
ailhwx-- eodgjvq- trcpzf-- nsumbyk-
AILHWX-- EODGJVQ- TRCPZF-- NSUMBYK-
─────────────────────────────────────────────> Layout-placing: 5
─────────────────────────────────────────────> Score: 3424393679.9    ~90.99 %
#######################################################################################################################
#######################################################################################################################
                                                    Custom layouts:

Example Layout:
ghopwx-- abijqryz cdklst-- efmnuv--
GHOPWX-- ABIJQRYZ CDKLST-- EFMNUV--
───────────────────────────────────> Score: 2873233944.5    ~76.35 %

Old / original 8VIM layout:
nomufv-w eilhkj-- tscdzg-- yabrpxq-
NOMUFV-W EILHKJ-- TSCDZG-- YABRPXQ-
───────────────────────────────────> Score: 3224051311.8    ~85.67 %
#######################################################################################################################
#######################################################################################################################
                                                    General Stats:
Time needed for the whole runthrough: 134.39 seconds.
Amount of bigrams that can be written with the letters used in this layout (without factoring in flow or layer-penalty):
4324127906 out of 4324127906  ( ~100.00 %)
#######################################################################################################################
########################################### 8vim Keyboard Layout Calculator ###########################################
#######################################################################################################################

New log:

#######################################################################################################################
#######################################################################################################################
                                                The top 5 BEST layouts:


      ⟍  ▓                k ⟋
      z ⟍  x            g ⟋  ▓
        q ⟍  p        u ⟋  y
          c ⟍  r    n ⟋  m
            t ⟍     ⟋  s
                ⟍ ⟋
                ⟋ ⟍
            o ⟋     ⟍  a
          f ⟋  e    i ⟍  l
        v ⟋  d        h ⟍  w
      ▓ ⟋  j            b ⟍  ▓
      ⟋  ▓                ▓ ⟍
ailhwb-- eodfjv-- trcpqxz- nsumgyk-
AILHWB-- EODFJV-- TRCPQXZ- NSUMGYK-
─────────────────────────────────────────────> Layout-placing: 1
─────────────────────────────────────────────> Score: 3425053010.0    ~91.01 %


      ⟍  ▓                k ⟋
      ▓ ⟍  f            b ⟋  ▓
        j ⟍  p        u ⟋  y
          c ⟍  r    n ⟋  m
            t ⟍     ⟋  s
                ⟍ ⟋
                ⟋ ⟍
            o ⟋     ⟍  a
          g ⟋  e    i ⟍  l
        v ⟋  d        h ⟍  w
      ▓ ⟋  x            z ⟍  ▓
      ⟋  q                ▓ ⟍
ailhwz-- eodgxvq- trcpjf-- nsumbyk-
AILHWZ-- EODGXVQ- TRCPJF-- NSUMBYK-
─────────────────────────────────────────────> Layout-placing: 2
─────────────────────────────────────────────> Score: 3425001203.07    ~91.01 %


      ⟍  ▓                k ⟋
      ▓ ⟍  x            g ⟋  ▓
        z ⟍  p        u ⟋  y
          c ⟍  r    n ⟋  m
            t ⟍     ⟋  s
                ⟍ ⟋
                ⟋ ⟍
            o ⟋     ⟍  a
          f ⟋  e    i ⟍  l
        v ⟋  d        h ⟍  w
      ▓ ⟋  j            b ⟍  ▓
      ⟋  q                ▓ ⟍
ailhwb-- eodfjvq- trcpzx-- nsumgyk-
AILHWB-- EODFJVQ- TRCPZX-- NSUMGYK-
─────────────────────────────────────────────> Layout-placing: 3
─────────────────────────────────────────────> Score: 3424955715.13    ~91.01 %


      ⟍  ▓                k ⟋
      z ⟍  ▓            g ⟋  ▓
        j ⟍  p        u ⟋  y
          c ⟍  r    n ⟋  m
            t ⟍     ⟋  s
                ⟍ ⟋
                ⟋ ⟍
            o ⟋     ⟍  a
          f ⟋  e    i ⟍  l
        v ⟋  d        h ⟍  w
      ▓ ⟋  x            b ⟍  ▓
      ⟋  q                ▓ ⟍
ailhwb-- eodfxvq- trcpj-z- nsumgyk-
AILHWB-- EODFXVQ- TRCPJ-Z- NSUMGYK-
─────────────────────────────────────────────> Layout-placing: 4
─────────────────────────────────────────────> Score: 3424465539.58    ~90.99 %


      ⟍  ▓                k ⟋
      z ⟍  x            m ⟋  ▓
        j ⟍  u        g ⟋  y
          c ⟍  r    n ⟋  p
            t ⟍     ⟋  s
                ⟍ ⟋
                ⟋ ⟍
            o ⟋     ⟍  a
          f ⟋  e    i ⟍  l
        v ⟋  d        h ⟍  w
      ▓ ⟋  ▓            b ⟍  ▓
      ⟋  q                ▓ ⟍
ailhwb-- eodf-vq- trcujxz- nsgpmyk-
AILHWB-- EODF-VQ- TRCUJXZ- NSGPMYK-
─────────────────────────────────────────────> Layout-placing: 5
─────────────────────────────────────────────> Score: 3424351564.72    ~90.99 %
#######################################################################################################################
#######################################################################################################################
                                                    Custom layouts:

Example Layout:
ghopwx-- abijqryz cdklst-- efmnuv--
GHOPWX-- ABIJQRYZ CDKLST-- EFMNUV--
───────────────────────────────────> Score: 2873233944.5    ~76.35 %

Old / original 8VIM layout:
nomufv-w eilhkj-- tscdzg-- yabrpxq-
NOMUFV-W EILHKJ-- TSCDZG-- YABRPXQ-
───────────────────────────────────> Score: 3224051311.8    ~85.67 %
#######################################################################################################################
#######################################################################################################################
                                                    General Stats:
Time needed for the whole runthrough: 135.28 seconds.
Amount of bigrams that can be written with the letters used in this layout (without factoring in flow or layer-penalty):
4324127906 out of 4324127906  ( ~100.00 %)
#######################################################################################################################
########################################### 8vim Keyboard Layout Calculator ###########################################
#######################################################################################################################

They should give us exactly the same scores if we test the same layouts.

THAT BEING SAID, in addition to adding a different way to score layouts (our new, big lists), I have changed the getPerfectLayoutScore-function. The perfect layout score now is guessed more accurately, making it bigger, thus making all future percentages slightly lower (the layout-scores will stay be the same):

New log (still not using your rating-system):

#######################################################################################################################
#######################################################################################################################
                                                The top 5 BEST layouts:


      ⟍  ▓                k ⟋
      z ⟍  x            g ⟋  ▓
        q ⟍  p        u ⟋  y
          c ⟍  r    n ⟋  m
            t ⟍     ⟋  s
                ⟍ ⟋
                ⟋ ⟍
            o ⟋     ⟍  a
          f ⟋  e    i ⟍  l
        v ⟋  d        h ⟍  w
      ▓ ⟋  j            b ⟍  ▓
      ⟋  ▓                ▓ ⟍
ailhwb-- eodfjv-- trcpqxz- nsumgyk-
AILHWB-- EODFJV-- TRCPQXZ- NSUMGYK-
─────────────────────────────────────────────> Layout-placing: 1
─────────────────────────────────────────────> Score: 3425053010.0    ~80.47 %


      ⟍  ▓                k ⟋
      ▓ ⟍  x            g ⟋  ▓
        z ⟍  p        u ⟋  y
          c ⟍  r    n ⟋  m
            t ⟍     ⟋  s
                ⟍ ⟋
                ⟋ ⟍
            o ⟋     ⟍  a
          f ⟋  e    i ⟍  l
        v ⟋  d        h ⟍  w
      ▓ ⟋  j            b ⟍  ▓
      ⟋  q                ▓ ⟍
ailhwb-- eodfjvq- trcpzx-- nsumgyk-
AILHWB-- EODFJVQ- TRCPZX-- NSUMGYK-
─────────────────────────────────────────────> Layout-placing: 2
─────────────────────────────────────────────> Score: 3424955715.13    ~80.47 %


      ⟍  ▓                k ⟋
      z ⟍  ▓            g ⟋  ▓
        j ⟍  p        u ⟋  y
          c ⟍  r    n ⟋  m
            t ⟍     ⟋  s
                ⟍ ⟋
                ⟋ ⟍
            o ⟋     ⟍  a
          f ⟋  e    i ⟍  l
        v ⟋  d        h ⟍  w
      ▓ ⟋  x            b ⟍  ▓
      ⟋  q                ▓ ⟍
ailhwb-- eodfxvq- trcpj-z- nsumgyk-
AILHWB-- EODFXVQ- TRCPJ-Z- NSUMGYK-
─────────────────────────────────────────────> Layout-placing: 3
─────────────────────────────────────────────> Score: 3424465539.58    ~80.46 %


      ⟍  v                z ⟋
      ▓ ⟍  x            g ⟋  ▓
        q ⟍  p        u ⟋  y
          c ⟍  r    n ⟋  m
            t ⟍     ⟋  s
                ⟍ ⟋
                ⟋ ⟍
            o ⟋     ⟍  a
          f ⟋  e    i ⟍  l
        k ⟋  d        h ⟍  w
      ▓ ⟋  j            b ⟍  ▓
      ⟋  ▓                ▓ ⟍
ailhwb-- eodfjk-- trcpqx-v nsumgyz-
AILHWB-- EODFJK-- TRCPQX-V NSUMGYZ-
─────────────────────────────────────────────> Layout-placing: 4
─────────────────────────────────────────────> Score: 3424362645.4    ~80.45 %


      ⟍  ▓                k ⟋
      z ⟍  x            m ⟋  ▓
        j ⟍  u        g ⟋  y
          c ⟍  r    n ⟋  p
            t ⟍     ⟋  s
                ⟍ ⟋
                ⟋ ⟍
            o ⟋     ⟍  a
          f ⟋  e    i ⟍  l
        v ⟋  d        h ⟍  w
      ▓ ⟋  ▓            b ⟍  ▓
      ⟋  q                ▓ ⟍
ailhwb-- eodf-vq- trcujxz- nsgpmyk-
AILHWB-- EODF-VQ- TRCUJXZ- NSGPMYK-
─────────────────────────────────────────────> Layout-placing: 5
─────────────────────────────────────────────> Score: 3424351564.72    ~80.45 %
#######################################################################################################################
#######################################################################################################################
                                                    Custom layouts:

Example Layout:
ghopwx-- abijqryz cdklst-- efmnuv--
GHOPWX-- ABIJQRYZ CDKLST-- EFMNUV--
───────────────────────────────────> Score: 2873233944.5    ~67.51 %

Old / original 8VIM layout:
nomufv-w eilhkj-- tscdzg-- yabrpxq-
NOMUFV-W EILHKJ-- TSCDZG-- YABRPXQ-
───────────────────────────────────> Score: 3224051311.8    ~75.75 %
#######################################################################################################################
#######################################################################################################################
                                                    General Stats:
Time needed for the whole runthrough: 125.14 seconds.
Amount of bigrams that can be written with the letters used in this layout (without factoring in flow or layer-penalty):
4324127906 out of 4324127906  ( ~100.00 %)
#######################################################################################################################
########################################### 8vim Keyboard Layout Calculator ###########################################
#######################################################################################################################

To get your layouts (for whatever language you want), I suggest you do some optimizing yourself.
I have enabled your rating-system as the default. If you ever want to test how the layouts would be rated using my original system, change from score_lists import KJOETOM_SCORE_LIST as SCORE_LIST to from score_lists import ORIGINAL_SCORE_LIST as SCORE_LIST.
The score-lists are placed in this file.

[kjoetom]

You are just great, @Glitchi-Tozier -
thank you so much for adapting your script to use alternate scores and especially for doing it so quickly.

I was only able to give everything a quick try because currently I'm not at my own PC. The script works wonderfully - I even have the impression that it is now a bit faster.

As far as I can tell now, I also need to adapt my score - I was not satisfied with the first layouts. Fortunately, it seems to improve dramatically when I scale the individual scores so that they are distributed over the entire spectrum between 0 and 1 (currently the lowest value is 0.382) - so more "punishment" for unfavorable connections is obviously helpful here.

Maybe tomorrow I can present german layouts based on the new score, so you can get an impression of it.

kjoe

[Glitchy-Tozier]

@kjoetom Turns out I made a pretty bad mistake a while ago, which resulted in only one layout getting fully optimized. The other ones still got some treatment, but always were missing at least 2% of what they could have been.

I have fixed the self-introduced bug now. Unfortunately, fixing the bug resulted in the script getting slowed down.

[kjoetom]

Oh well, that explains why my old PC was so blazing fast. ;p

The alternative scoring system does not seem to be good at all. I only get ~86.64 % with it, although I don't know if you can compare the percentages between different scoring systems.

  ⟍  ▓                x ⟋
  ▓ ⟍  f            w ⟋  ▓
    p ⟍  u        b ⟋  z
      o ⟍  n    r ⟋  d
        s ⟍     ⟋  i
            ⟍ ⟋
            ⟋ ⟍
        a ⟋     ⟍  e
      l ⟋  t    h ⟍  g
    y ⟋  m        c ⟍  k
  ▓ ⟋  v            j ⟍  ▓
  ⟋  ▓                q ⟍

ehgckj-q tamlvy-- snoupf-- ribdwzx-
EHGCKJ-Q TAMLVY-- SNOUPF-- RIBDWZX-
─────────────────────────────────────────────> Layout-placing: 1
─────────────────────────────────────────────> Score: 663558447.13 ~86.64 %

Since I didn't set a fixed letter, I only got rotated variants from before. For the sake of comparison, here is the version with the "e" in the usual position.

  ⟍  ▓                ▓ ⟋
  ▓ ⟍  y            p ⟋  ▓
    v ⟍  l        o ⟋  f
      m ⟍  a    s ⟋  u
        t ⟍     ⟋  n
            ⟍ ⟋
            ⟋ ⟍
        h ⟋     ⟍  r
      c ⟋  e    i ⟍  b
    j ⟋  g        d ⟍  w
  q ⟋  k            z ⟍  x
  ⟋  ▓                ▓ ⟍

I doubt if this can really be better. Here for the purposes of comparison the best result of Glitchy's original score:

  ⟍  ▓                ▓ ⟋
  ▓ ⟍  f            v ⟋  ▓
    y ⟍  m        o ⟋  j
      l ⟍  n    s ⟋  b
        t ⟍     ⟋  r
            ⟍ ⟋
            ⟋ ⟍
        a ⟋     ⟍  u
      c ⟋  e    i ⟍  g
    p ⟋  d        h ⟍  w
  ▓ ⟋  k            z ⟍  x
  ⟋  q                ▓ ⟍

uighwzx- eadckpq- tnlmyf-- srobvj--
UIGHWZX- EADCKPQ- TNLMYF-- SROBVJ--
─────────────────────────────────────────────> Layout-placing: 1
─────────────────────────────────────────────> Score: 711366381.9 ~90.77 %

[Glitchy-Tozier]

Oh well, that explains why my old PC was so blazing fast. ;p

Mine is really slow as well. 🙈
It's kind of sad. I thought i made speed improvements while in reality I prevented all but one layouts from being tested...

The alternative scoring system does not seem to be good at all. I only get ~86.64 % with it, although I don't know if you can compare the percentages between different scoring systems.

Remember,

1. The percentage changed, meaning the old best layout (with the old scoring system) now, too, has a worse percentage.
2. What's more important than the score is how happy you are with the actual characteristics of the layouts.

• The score simply is a measure with which to compare layouts within one configuration ("See, our optimized layouts are better than the original 8pen-layout!")
• The characteristics of the (new) best layouts are the actual result of your score.

What do you think about the writing-behaviour of your new best layout compared to the old best one?

Since I didn't set a fixed letter, I only got rotated variants from before. For the sake of comparison, here is the version with the "e" in the usual position.

Sounds like this rating-system doesn't care about the layout's rotation. If this is the case, you should add a letter ("e"?) to staticLetters.

[Glitchy-Tozier]

Hi @kjoetom!
I'm not in the scoring headspace anymore, so I'd like to ask you for a favor.

I'm trying to create an explanation.md file for the optimizer, and I'd like to add an explanation of how scoring works.
Could you summarize how the system behind the scores workes? (I forgot...)

The most important points might be

1. The basics of the system (stuff like "higher number → better position")
2. How each position in the list relates to a position in the actual layout?

If there's some discussion or some excel-file you posted somewhere, which aid in diectly understanding/creating scores, feel free to add a link to that material. For example, I remember you once posted a comment describing how you ended up at the scoring we're currently using. :)

[kjoetom]

Hi @Glitchy-Tozier,

I'm afraid I'm also not in the scoring headspace anymore.

It's been a while since I last delved into the topic of "scoring", and unfortunately, a lot of the details and ideas that I had considered have slipped away pretty quickly. I remember that I tried out various methods to improve my writing speed and efficiency, taking into account factors like the:

• "distance covered while writing",
• "changes in direction"
• "changes in rotation", and
• the "actual time it takes to write a bigram" (measured by myself).

For instance, I noticed that I personally could execute up-down movements faster than left-right movements, which is why my proposed layouts often have the letter "e" placed in a different spot than the original 8-vim layout (and many others).

I attempted to weigh these factors differently and derive different scoring tables that could be used to optimize the letter arrangement on the 8-vim keyboard, depending on the frequency of letter pairs in the target language. Many of my considerations can be found here in the discussions of the 8-vim repository.

Therefore, none of this was based on strict scientific research, but rather on my own theories and assumptions, and trial and error ;-).

Overall, I am convinced that shorter writing distances and times, smooth and continuous movements without changes in direction or rotation, were the most effective methods for improving my writing speed.

In my opinion, the real problem lies in the correct weighting, which for me always remained a matter of intuition and often turned out to be wrong. I never found a scoring system that I was convinced was "the one true and best system".

It can be frustrating to think about how much time and effort I put into those attempts. But it was also fun, and I would like to express my gratitude once again for your creation of the 8vim_layout-calculator. It was instrumental in converting the scores into layouts, and I greatly appreciate your making it available.

There is a Libreoffice Calc file that I apparently used in calculating the different scores. However, it is unfortunately poorly documented (because I kept changing it over and over again) that I can no longer trace the individual steps. Apparently, I relied on my own measured and calculated times for writing individual sections. But the way I weighted them became so confusing that I can no longer reconstruct it. So it doesn't make sense to upload it here. However, I can send it to you if you'd like.

kjoe

[kjoetom]

You are right, the scoring system does not care about rotation.

As far as the writing experience is concerned, I can't see any preference at the moment. I have already thought about whether we could use more objective criteria in this case, e.g. in what percentage there are full stops or also taking in account diacritic letters.

Since the "new score" is based purely on writing time, it might be possible to improve it by adding penalties for full-stops. I already tried that (but before you corrected your script) and ended up with very strange layouts with empty spaces in the 3rd layer.

Unfortunately I'm abroad for the next few days, so I won't have much time to try out new solutions and ideas for the rest of the week.

[Glitchy-Tozier]

or also taking in account diacritic letters.

Warning: Unless there's some really easy way to incorporate this, I probably won't add this myself, as it might get really messy.

and ended up with very strange layouts with empty spaces in the 3rd layer.

Sounds really funny, actually! 😆

Also, small heads-up: When you return (and when you decide to do some optimizing), make sure to fetch the newest version from GitHub! During the last two days, I worked on (slightly) speeding up the script and removing some crashes.

[kjoetom]

Hello all (and of course also @Glitchy-Tozier),

I've tried different score variations in the meantime and have to say that despite different results, there hasn't been one where I could say that one of them feels like the right one. I got the impression that larger differences in the individual score numbers within a layer may lead to less fluent results.

Therefore, I wanted to try out what happens if I don't consider the flow at all and only use the duration of the individual letters for the score (as measured by myself). In doing so, I unfortunately ran into a problem: the script starts with the 1st cycle and gets stuck after the first layer (even though pypy3 keeps running in the background). I suspect this has to do with the fact that there might not be a "best layout" for layer 1 if all positions have the same score. This can be worked around by slightly changing the numbers in the score list. But then there will be the same getting stuck when layer 4 is calculated.

If I make the numbers sufficiently different (but as close as possible to the desired values) that the script just doesn't get stuck, I get results that are not inferior to a more complex score and for me even feel better.

Have we made a mistake in thinking about scoring? Is it perhaps the case that the letters are distributed most optimally according to their frequencies if they are not influenced too much by complex scores?

The getting stuck can be reproduced, at least for me, if you use the score "KJOETOM_SCORE_LIST_2" from this score list (score_lists.py.zip).

I would be happy if the cause of the script getting stuck could be fixed.

By the way, the script now seems to run faster again - thank you for that.

kjoe ;-)

[Glitchy-Tozier]

I unfortunately ran into a problem: the script starts with the 1st cycle and gets stuck after the first layer (even though pypy3 keeps running in the background). I suspect this has to do with the fact that there might not be a "best layout" for layer 1 if all positions have the same score.

Oh nooooo!!
The "There is no best layout" may really be an issue! I'll investigate tomorrow.

Have we made a mistake in thinking about scoring? Is it perhaps the case that the letters are distributed most optimally according to their frequencies if they are not influenced too much by complex scores?

1. I can't give you a smart reply – you're the score-scientist :P
2. Just to reiterate:
   • The score does not matter. It's a fun number. What matters is what layouts are considered best, so your "…for me even feel better." is the most important factor.
   • If you want the letter's layer-placement (1st layer to 4th layer) to not be influenced by flow, you can just place the letters in the appropriate layers and then remove all letters from VAR_LETTERS. No need to do anything to the score.

By the way, the script now seems to run faster again - thank you for that.

Thank you for noticing! :)
I did my best to optimize...the optimizer. Let's hope the speedup isn't the result of another bug I created!

[Glitchy-Tozier]

1. The bug is fixed. The inkling you had was correct.
2. There's still something weird going on within the greedyOptimization. Not sure how to fix this rn, I'll take a look during the following days.

[kjoetom]

The script getting stuck is now fixed. Thanks for that.
What is really noticeable is that the gready optimization takes no time at all.

kjoe

[Glitchy-Tozier]

Yep, that was the result of another speed-optimization backfiring. It was almost the same place as where the "there is no best layout"-bug took place.
It's fixed now. greedyOptimization is back to taking some time, but you should get slightly better layouts now (even without using greedyOptimization).

[kjoetom]

Thank you @Glitchy-Tozier,

I have run your script with different score variants of the KJOETOM_SCORE. In the German layout thread I uploaded a comparison image of your best layout with 3 results based on my score (see here). I am curious if or which comments there are from users of the german layout.

[Glitchy-Tozier]

@kjoetom I have added the ability to optimize for multiple languages (or just display how good each layout is for each language).
Check it out and tell me what you think (and whether you encounter any bugs)! :)

I recommend something like 70% German 30% English when optimizing for German.

[kjoetom]

Hello again everyone,

I think I've finally managed to find a score that matches my expectations.

This new score is still based on the Duration of the Bi-Positions (= writing time for two-position-combinations), but in addition it also accounts for different movement qualities when writing these Bi-Positions.

"bad" Position-Connections are:

• whenever a Position in Layer 4 is involved
• whenever the movement includes a forced stop (as defined above)
• optionally also: whenever the rotation direction has to be changed 2x between positions (<-- that I consider in a second, extended score)

"good" are all the other Position-Connections.

For the new score the inverse Duration of the Bi-Positions is used. Therefore, Bi-Positions with longer writing times result in smaller values.

These values are then scaled down depending on whether it is a "good" or "bad" connection to maximally reach a value ...
... of 1 in case of a "good" connection (values then range from 0.382 to 1.0)
... of 0.382 in case of a "bad" connection

This procedure ensures that bad connections always have lower scores than good connections and that no overlaps can occur which in the past score versions seemingly was the reason for completely distorted "best layout results".

So, based on the duration times I've measured and calculated at the beginning of this thread (#260), one can calculate the new Score for any Bi-Position (two-position-combination) as follows:

1. determine the Movement-Quality of the Bi-Position ("good" or "bad")
2. in case of a "good" Bi-Position calculate: Score = 1.644 / writing time
3. in case of a "bad" Bi-Position calculate: Score = 0.382 x 1.644 / writing time

The new score is included in a score list usable by the 8vim keyboard layout calculator of Glitchy-Tozier (#138 (comment))

[Glitchy-Tozier]

Maybe that's what you've done though, and I'm just misunderstanding. It's obviously not possible to make a gradual scale out of a yes/no criterion like "is there a forced stop".

Assuming the criteria have the sa.e, correct polarity (0-1) you might be able to do sth like this: ((ps=partial score))

score = ps1*0,3 + ps2*0,3 + ps3*0,4

---

Btw, as you mentioned that some scores don't follow the higher=better, you could transform them by subtracting all values from 1.

well-poled = 1 - reverse-poled

[kjoetom]

I failed miserably with this method of combining. This sometimes even resulted in layouts that had blanks in layer 3 and layer 2 as well.

Therefore I calculated this way:

Score =

• if the movement can be rated as "good"

• then use the "inverse writing time" and scale it down so that the maximum possible value is "1"
  (this also gives a minimum possible value (namely for the longest writing time) of about 0.382)

• else use the "inverse writing time" and scale it down so that the maximum possible value is "0.382"

[Glitchy-Tozier]

Could adding a "layer-penalty" fix your issue? It's what I used in the original layout.
L1 1.0
L2 0.7
L3 0.3
L4 0.0

[kjoetom]

I have integrated the "layer-penalty" in the score in 2 ways

• L4-positions pre-categorize a movement as "unwanted / bad".
• L2 and L3 positions need more time to write and lead therefore to lower score-values

I think that when you sum up partial scores you always have the problem that you can't objectify the weighting and that unpredictable overlaps between the partial scores are gonna happen.

[Glitchy-Tozier]

I failed miserably with this method of combining. This sometimes even resulted in layouts that had blanks in layer 3 and layer 2 as well.

I'll let you do your thing, but just so you know my thoughsI, this sounds like you needed to weight writing-speed more strongly 🤔