New Keyboard Layout Project: Another Cost and a Strange Development
I added another fitness element. If the curve follows the natural roll of the hand, then it should be supported. I made it cheaper to change rows if the row changes were (QWERTY positions) DV/VD, FE/EF, MK/KM, or IJ/JI. After adding that and running the program once, I got this strange result:
, p h d k j c u l y a n o t m g s e r i q b . f z v w ; x '
It looks so different from the other results that I don’t entirely trust it. But h and o on the same finger? What? But perhaps surprisingly, it actually has very low same finger.
I ran a comparison, and it turns out that it is actually not the best layout for the score set. Apparently, adding that extra fitness criterion caused the program to take longer to converge upon the best layout.
MTGAP 3.5 k c f g b j h u w . o s a t d l n e r i q v , p z ; m y x ' Fitness: 18.99 Distance: 1822.85 Inward rolls: 7.50% Outward rolls: 5.27% Same hand: 22.29% Same finger: 0.85% Row change: 9.89% Home jump: 0.30% To center: 3.16% MTGAP 3.6 , p h d k j c u l y a n o t m g s e r i q b . f z v w ; x ' Fitness: 19.49 Distance: 1864.59 Inward rolls: 8.67% Outward rolls: 6.06% Same hand: 24.29% Same finger: 0.76% Row change: 11.67% Home jump: 0.23% To center: 2.92%
3.6 has better same finger, but 3.5 is a good deal better overall. How could this happen? At this time, I have no idea. I will probably not be using the additional criterion, since it makes the convergence rate so slow.