Welcome, Guest. Please login or register.
Did you miss your activation email?
2020-Sep-28 17:35

Login with username, password and session length

Recent

Shoutbox

break:
May. 09 2020 - 10:02am
Awesome, happy to be back on the forums !
I hope everyone is in good health.
ADMIN:
May. 01 2020 - 6:54pm
new domain: ieants.cc
Den:
Mar. 20 2020 - 2:40am
possible delay of service
break:
Mar. 14 2020 - 1:05pm
@Den
Hey, had some issues opening the Worksheet in the new MS-Excel. Made a topic about it.
break:
Mar. 07 2020 - 12:19pm
@Den 
You are awesome, this helps a lot !  Really appreciate your help.
Den:
Mar. 07 2020 - 4:07am
.tbl file and translation program
break:
Mar. 05 2020 - 10:44pm
@Den Wow friend, you are blazing with these updates ! Question, how did you edit the names of things ?
Den:
Mar. 03 2020 - 1:21am

Author Topic: [BEAKL] Balanced Effortless Advanced Keyboard Layout  (Read 349321 times)

moesasji

  • Valued Member
  • ***
  • Posts: 68
    • View Profile
Re: [BEAKL] Balanced Effortless Advanced Keyboard Layout
« Reply #1900 on: 2020-Sep-06 07:39 »
Just a question you have probably already thought about, but how do you intend to weigh the popularity of a language in this analysis? Essentially there will a lot more people writing Javascript, C/C++, Python than something like ZX spectrum basic or COBOL.

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: [BEAKL] Balanced Effortless Advanced Keyboard Layout
« Reply #1901 on: 2020-Sep-06 08:50 »
Just a question you have probably already thought about, but how do you intend to weigh the popularity of a language in this analysis? Essentially there will a lot more people writing Javascript, C/C++, Python than something like ZX spectrum basic or COBOL.

Yes I did think about it, and decided that RosettaCode had to some degree done that step for me. They've got hundreds of tasks that people can solve, the more popular languages have more tasks solved, and more solutions per task.

I don't think it would be fair to just focus on what is on top of the Tiobe list this month.

People outside of corporateland are sometimes surprised at how much code is in non-trendy languages....

https://skeptics.stackexchange.com/questions/5114/did-cobol-have-250-billion-lines-of-code-and-1-million-programmers-as-late-as-2

When I was in a Corp back in the 90s (financial services) we did everything in IBM360 assembler. We did try some stuff in COBOL but it ran too slowly. Every now and then the IBM salesmen would convince the suits to try some fancy code-gen system but they never lived up to the hype.

So no, not going to try and weight things for now. Will see how the resulting frequency vs layouts plays out, then we can discuss.

Screenshot shows tasks per language, but not solutions per task.

Cheers, Ian


« Last Edit: 2020-Sep-06 08:55 by iandoug »

moesasji

  • Valued Member
  • ***
  • Posts: 68
    • View Profile
Re: [BEAKL] Balanced Effortless Advanced Keyboard Layout
« Reply #1902 on: 2020-Sep-06 09:13 »
Yes I did think about it, and decided that RosettaCode had to some degree done that step for me. They've got hundreds of tasks that people can solve, the more popular languages have more tasks solved, and more solutions per task.

I don't think it would be fair to just focus on what is on top of the Tiobe list this month.

I fully agree on not focusing on the Tiobe list, but I'm a bit skeptical that RosettaCode does this for you as some of it is driven by nostalgic memories seeing how many of the tasks have been completed for ZX Spectrum Basic for example. In any case looking forward to see what comes out of your analysis!!

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: [BEAKL] Balanced Effortless Advanced Keyboard Layout
« Reply #1903 on: 2020-Sep-06 13:55 »
Okay done cleaning up the code. Went faster once I let the power of Regex loose on the files.. was reluctant to do that before because I wanted to be careful about how and where what got fixed.

Still having some issues with the tab character.

Attached shows final code letter frequency, as well as some English .. The Reuters corpus, and the four better folders from the British National corpus.

Next up is to clean up the UseNet corpus, which should be much faster than the code.

Cheers, Ian


iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: [BEAKL] Balanced Effortless Advanced Keyboard Layout
« Reply #1904 on: 2020-Sep-07 15:23 »
Next up is to clean up the UseNet corpus, which should be much faster than the code.

Me and my big mouth... should have looked deeper first. :-)

First problem is that it is 36.8 GB big... which is a different animal to the other corpus files which are under 100 MB each. I've got a cleanup program running on it, nearly 24 hours, and only about 91% done. It's 695 MILLION lines of text.

Even though this is the "cleaned up" version, there are still issues... some easy to fix, like message separators, placeholders for EMAIL and URL, and excessive blank spaces and lines.

Some are more problematic, like this extract:


On Jun 13, 3:55=A0pm, Dragonblaze < <EMAILADDRESS> > wrote: ered? do e ,  in s nd d
=93T =93 ( spies interrupt =96 have noting to do with this situation. I did not grew up with that Person. I am not bounded by any relation. I do not know what you want. Because you did not speak with me you believe in some myth. I was a victim during communist era and during the war ( documented) . Please properly communicate with Senator Norton, who is like new born baby on this earth regarding what the issues behind, she is fully misinformed. You be too if you talk to offenders only. All offenders degrade the victims STOP ABUSSES.
0-1667400761-1213984186=:54610 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
This is directly for Senator Voynowicz, =A0 =A0 =A0=A0 C O N F I D E N T I A L =A0 Dear Senator Voynowicz, =A0 =A0 Please be kind to help Barbara Boxer transit or remove her from Ehtics. =A0 She has a problem with sending me invitation letter after I most kindly giv= en all referenced information. I AM ELECTED US PRESIDENT AS YOU REMEMBER AN= D I REMEMBER YOU. =A0 She is a crazy as to claim that because I have killed FDR who also happen t= o serve in thecurrent senate under assume neame Allen, she will be stealing= my assets. =A0 I was never served any papers, and certainly=A0I do not kils anyone.=20 =A0 Barbara is far of the line. If paper not served Barbara is in no position t= o claim=20 anything of the sort that she will not rEly to my return. I aM elected President returning first time undr the same law that applies = that president=20 Eisenhauer was able to come and go as pleased ( he that was) after the kidn= apping with battery , from the office of President. =A0 International community and me and my sons ( who are captured and hostages = , admitedly of CIA) demand to be fre citizens. =A0 You have some lose wires there. =A0 You take over and send me inviatation. =A0 SKHE MOST LIKELY MADE THAT UP TO STEAL MY ASSETS AND THESE WHO DISTRIBUTEAS= SETS UNDER ME. =A0 I DI SEND YOU A MOSRE TRASFFUL LETTER THAN. WHAT HAPPENED. BARBARA ETHGICALLY KICKED YOU OUT OF ETHICS COMITTEE? =A0 You need me, that is painfully obvieus, even if you yourself resist. =A0 Barbara should not represent any business for public now, whether private o= r public. I am expert witnes in State courts and i know what I am talking about.=20 =A0 Judge Breyer does to. =A0 lease do not fix world problem until youfix this one. Preferebly today. Me = and my son are held hostage. This one is not Judge bryer deficiency. Might = be his arogance. =A0 You must release us from hostage now. You neglecting the duty while not def= icient in brain. That is criminal. =A0 =A0 Please be forewarned. =A0 Thank you. =A0 E =A0 C: Senate =A0 =


which is just a mess and does not belong in a corpus trying to simulate manual typing.

There's also stuff like this:


That=92s it, folks!
kangarooistan ==========
=93I don't know who set the fire,=94 he said.
=93When they are sure, I believe more and more will volunteer to return.=94
=D0=9F=D0=B5=D0=B4=D0=BE=D1=84=D0=B8=D0=BB
p=C3=A9dophile
p=C3=A6dophile
ped=C3=B3filo
P=C3=A4dophile
=E5=B0=8F=E5=85=90=E6=84=9B=E8=80=85
=D8=A8=DA=86=D9=87 =D8=A8=D8=B2
=D0=B1=D3=99=D1=87=D1=87=D0=B8=D0=B2=D0=B0=D0=B7
=E0=B8=81=E0=B8=B2=E0=B8=A1=E0=B8=A7=E0=B8=B4=E0=B8=95=E0=B8=96=E0=B8=B2=E0= =B8=A3=E0=B8=9B=E0=B8=A3=E0=B8=B0=E0=B9=80=E0=B8=A0=E0=B8=97=E0=B8=8A=E0=B8= =AD=E0=B8=9A=E0=B9=80=E0=B8=94=E0=B9=87=E0=B8=81
=E0=B8=9E=E0=B8=A7=E0=B8=81=E0=B8=81=E0=B8=B2=E0=B8=A1=E0=B8=A7=E0=B8=B4=E0= =B8=95=E0=B8=96=E0=B8=B2=E0=B8=A3=E0=B8=9B=E0=B8=A3=E0=B8=B0=E0=B9=80=E0=B8= =A0=E0=B8=97=E0=B8=8A=E0=B8=AD=E0=B8=9A=E0=B9=80=E0=B8=94=E0=B9=87=E0=B8=81
=E6=81=8B=E7=AB=A5=E7=99=96=E8=80=85
=E5=85=B1=E7=99=BC=E7=8F=BE 1 =E7=AD=86=E9=97=9C=E6=96=BC [pedophile] =E7= =9A=84=E8=B3=87=E6=96=99
p=C3=A6dofil
p=C3=A4dophiler Mann
=CF=80=CE=B1=CE=B9=CE=B4=CE=B5=CF=81=CE=B1=CF=83=CF=84=CE=AE=CF=82
ped=C3=B3filo


Again, more mess.

Last issue is the sheer size of the file, it dwarfs everything else put together, and will likely distort character frequencies adversely.

So I think I'm going to leave it out for now, and instead focus on better-written things like the books, Wikipedia, and the "Web" corpus.

Cheers, Ian

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
C, H and all that
« Reply #1905 on: 2020-Sep-07 17:07 »
Dunno if Snarfangel is still around here .. he posted attached on Geekhack.

It scores well on KLATest. Thought it interesting because of recent discussions about rolls with "H" and "C" on pinky ....

Cheers, Ian

moesasji

  • Valued Member
  • ***
  • Posts: 68
    • View Profile
Re: C, H and all that
« Reply #1906 on: 2020-Sep-08 04:23 »
It scores well on KLATest. Thought it interesting because of recent discussions about rolls with "H" and "C" on pinky ....

Definitely interesting as I see the same strange thing in it. Putting the "c" and "w" on the same pinky gives a lot of movement as both are common in common words, yet it scores well. I see the same for combining "r" and "w" and that can't be right in my books.

btw) I've promised myself to stop tweaking having settled on the one below

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Wikipedia as corpus
« Reply #1907 on: 2020-Sep-10 07:35 »
hi

Just an update on the "get corpus from Wikipedia" process... so far:

1. got xml dump from Wikipedia, 73.7 GB

2. used 3rd-party python script to extract plain text. There are various such things floating around eg on Github. This one also stripped out the tables/sidebars/etc to produce reasonable plain text. It also seems to have done some cleanups (I see things like () , which I assume once had text in), and adds ":" after title and period after subheadings. Reduced size down to 12.9 GB in one file.

3. Wrote a program to "articlise" it, and selected the 4054 articles that were longer than 10,000 words. Then wrote the first 2000+ words of each article to separate files, one per extract.

4. Now busy running cleanup on those files... remove diacritics, delete foreign words and phrases, assorted typographical things, etc. About a quarter of the way.

But... the letter frequency is not coming out as it should. These are mostly stable:

Code: [Select]
orshldcumfpg

but the order is wrong.

The main letters are even worse:

Code: [Select]
⍽eatni

Now I dunno if this is because of the style of writing, or because many of the articles are about non-English people/places/events. But it is "curious" in the Spock sense.

The actual counts for the first are
Code: [Select]
    [ ] => 4635676
    [e] => 2768178
    [a] => 1958970
    [t] => 1948132
    [n] => 1727624
    [i] => 1726144
    [o] => 1642154
    [r] => 1512026
    [s] => 1410404
    [h] => 1077580
    [l] => 936252
    [d] => 900066
    [c] => 711064
    [u] => 588456
    [m] => 541350
    [f] => 485604
    [p] => 430156
    [g] => 428386
    [w] => 351400
    [y] => 346944
    [b] => 299238
    [,] => 293272
    [v] => 227700
    [.] => 215776
    [⮠] => 124098
    [k] => 119102

So "a" and "t" are in the same ballpark, as are "i" and "n", but "o" is really out of place.

Change over time screenshot attached.

moesasji

  • Valued Member
  • ***
  • Posts: 68
    • View Profile
Re: Wikipedia as corpus
« Reply #1908 on: 2020-Sep-10 09:40 »
That is weird. According to http://letterfrequency.org/ it is: e t a o i n s h r d l c u m w f g y p b v k j x q z

Very different, but it must be said that they don't specify how they determined it!

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Current state of getting corpus for keyboard evaluation
« Reply #1909 on: 2020-Sep-12 16:55 »
Hi

Finally finished ( I think/hope/pray) working through the WikiPedia corpus. Ended up with two:

1. Original one I posted before, which was articles > 10k words, cleaned up. I wanted the longer articles on the assumption that they were "mature" and well-edited to be good English.

2. But this was a long, tedious and boring process (program detects and fixes some things, other fixups done manually). So I modified the "extract articles" program to instead select articles > 2100 words, which were already keyboard-compatible. These just needed some relatively simple auto cleanups. Will check tomorrow if there is any overlap in the two sets.

The letter frequency of the main letters came out the same for both groups.
⍽etaniorshldcumfpg
I guess that "There's Something About WikiPedia."

Current analysis of where I am is attached. I think there may still be a bug with the handling of the "tab" character... it certainly should be in the Rosetta corpus.

Cheers, Ian


iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Final English corpus
« Reply #1910 on: 2020-Sep-13 11:39 »
Hi

Okay I'm done with this phase of the exercise, comparison between previous reference corpus and new one attached.

The order eventually became "correct" for the first 15 characters when I added extracts from the Web Corpus.
The following were catted into one file to analyse: (BNC == British National Corpus)

Code: [Select]
  80931913  BNC-Folder-A-cleaned.txt
 101741950  BNC-Folder-C-cleaned.txt
  39813802  BNC-Folder-E-cleaned.txt
  46387957  BNC-Folder-F-cleaned.txt
 135948339  Gutenberg-extracts.txt
   1491992  Reuters-cleaned.txt
  27793038  WebCorpus-extract.txt
  49622335  Wikipedia-ANSI-cleaned.txt
  49748221  Wikipedia-nonANSI-fixed.txt

For Gutenberg, there were over 61k books. I selected those which were "ANSI-friendly" from line 200, for 2,000 words. That reduced it down to 19+k.

But there are many weird books (eg lists of chess moves, or the contents of a list of butterfly species), so I limited the selection further to those that scored 70 or more on the Top 15 test,  to eliminate such books. We can argue if this is cherry-picking or being pragmatic. Despite that, the combined file only got 73/120 for the top 15, which is not good.

The Web corpus consisted of 408 files ranging from 7 to 70 MB each. I took a similar approach ... by taking a 20,000 word "ANSI-friendly" extract from the beginning of the files. That produced 224 clean files.

This corpus is both broader (in terms of British/American English and type of content) than the previous. One thing I noticed is that the single quote ranks higher the the double quote... which is likely correct.

I did take another look at the "open" version of the American National Corpus, but the spacing (line breaks and spaces) is all over the place and will require a lot of manual editing to fix. A major part of it is the 9/11 report, and I'm not sure that that's representative of "English".

Anyway, here's the actual counts. "i" and "n" are close, and were swapped before including the web corpus.

Code: [Select]

    [⍽] => 155976752
    [e] => 92951452
    [t] => 66746140
    [a] => 60386686
    [o] => 56255022
    [i] => 53359184
    [n] => 53334218
    [s] => 47899576
    [r] => 46904830
    [h] => 38381172
    [l] => 30924224
    [d] => 29058834
    [c] => 22468134
    [u] => 20412350
    [m] => 17658918
    [f] => 16561554
    [p] => 14609274
    [g] => 14400664
    [w] => 13236000
    [⮠] => 13018308
    [y] => 12846008
    [b] => 10596296
    [,] => 9450322
    [.] => 8030840
    [v] => 7655594
    [k] => 4808796
    ['] => 3451252
    [T] => 2882430
    [I] => 2648456
    [-] => 2305734
    [A] => 2228858
    [S] => 2199910
    [C] => 1756500
    ["] => 1521356
    [x] => 1507316
    [1] => 1493952
    [M] => 1461842
    [B] => 1440628
    [H] => 1287100
    [E] => 1209628
    [P] => 1201828
    [0] => 1163708
    [R] => 1061378
    [W] => 1052984
    [N] => 970604
    [D] => 943406
    [L] => 929858
    [G] => 872958
    [O] => 871534
    [F] => 846344
    [9] => 807174
    [j] => 759624
    [q] => 753342
    [2] => 728064
    [)] => 643288
    [(] => 638128
    [z] => 570002
    [8] => 506388
    [J] => 505698
    [;] => 504744
    [5] => 471204
    [3] => 452550
    [U] => 442992
    [4] => 406356
    [7] => 381746
    [:] => 380202
    [6] => 379676
    [K] => 358204
    [?] => 322308
    [Y] => 318522
    [V] => 294112
    [!] => 180328
    [_] => 138202
    [/] => 91646
    [Q] => 69080
    [X] => 68056
    [%] => 65234
    [Z] => 54954
    [$] => 52290
    [[] => 45930
    []] => 44944
    [&] => 41202
    [*] => 36688
    [=] => 12682
    [+] => 11376
    [|] => 10766
    [>] => 7504
    [#] => 5176
    [`] => 3992
    [<] => 3934
    [{] => 3158
    [}] => 3136
    [\] => 1938
    [⭲] => 1528
    [@] => 816
    [~] => 488
    [^] => 388
« Last Edit: 2020-Sep-13 11:45 by iandoug »

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: [BEAKL] Balanced Effortless Advanced Keyboard Layout
« Reply #1911 on: 2020-Sep-14 13:54 »
But the weightings per finger look like this, from left pinky to right pinky and both thumbs:

$fingermultiplier = array(
"1" => 3.67,
"2" => 2.9,
"3" => 2,
"4" => 1.85,
"5" => 1,
"6" => 1,
"7" => 1.85,
"8" => 2,
"9" => 2.9,
"10" => 3.67,
"11" => 1
);

Stumbled upon my spreadsheet where I calculated those ... still need to find the paper I took the left and Right values from.

Attached.

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Useless trivia you don't need to know
« Reply #1912 on: 2020-Sep-14 14:15 »

As you may know, I've been sticking my nose into Giza, and there is an interesting connection between the pyramids and our keyboards...

The Egyptians used a length called the (royal) cubit, which for our purposes was 52.36 cm long. (The experts are still arguing about this exact value, because if they accept that value, they need to explain why it is π/6 metres. And that will rewrite history.)

Anyway, they divided this into 28 "fingers" or "digits". Why 28? We don't know, might be related to lunar cycle or female cycle or something else.

So 52.36 / 28 gives a digit of 1.87 cm or 18.7 mm... which is basically the size of a Cherry-style key cap ... the switches are centred 19mm apart, so key caps are fractionally smaller.

Thus endeth today's lesson. :-)

Bonus trivia ... Golden ratio x pi / e  = φπ/e  ≈ .... 1.87 .... go figure ...

Cheers, Ian

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Keyboard geometries
« Reply #1913 on: 2020-Sep-15 16:51 »
Hi

I did ask Google, the answer is something along the lines of "It's there in them thar DLLs", but you need an advanced degree in the dark arts to make sense of them... plus copyright issues.

Basically I'm looking for some files which define the various physical keyboards. XKB has "geometry" files, but they're not terribly current ... the Microsoft file only has Microsoft Natural and Microsoft Natural(R) Keyboard Elite, both of which are decades old.

The style is readable but deciphering in a program looks to be a bit messy. Here's the PC102 layout:

Code: [Select]
xkb_geometry "pc102" {

    description= "Generic 102-key PC";
    width= 470;
    height= 180;

    shape.cornerRadius= 1;
    shape "NORM" { { [ 18,18] }, { [2,1], [ 16,16] } };
    shape "BKSP" { { [ 38,18] }, { [2,1], [ 36,16] } };
    shape "TABK" { { [ 28,18] }, { [2,1], [ 26,16] } };
    shape "BKSL" { { [ 28,18] }, { [2,1], [ 26,16] } };
    shape "RTRN" {
        { [0,0], [28,0], [28,37], [5,37], [5,18], [0,18] },
        { [2,1], [26,1], [26,35], [7,35], [7,16], [2,16] } };
    shape "CAPS" { { [ 33,18] }, { [2,1], [ 31,16] } };
    shape "LFSH" { { [ 25,18] }, { [2,1], [ 23,16] } };
    shape "RTSH" { { [ 50,18] }, { [2,1], [ 48,16] } };
    shape "MODK" { { [ 27,18] }, { [2,1], [ 25,16] } };
    shape "SPCE" { { [134,18] }, { [2,1], [132,16] } };
    shape "KP0"  { { [ 37,18] }, { [2,1], [ 35,16] } };
    shape "KPAD" { { [ 18,37] }, { [2,1], [ 16,35] } };

    shape "LEDS" { cornerRadius= 0, { [ 75 ,20 ] } };
    shape "LED"  { cornerRadius= 0, { [  5,  1 ] } };
    solid "LedPanel" {
shape= "LEDS";
top=  22;
left= 377;
color= "grey10";
    };

    indicator.onColor= "green";
    indicator.offColor= "green30";
    indicator.top= 37;
    indicator.shape= "LED";
    indicator "Num Lock"     { left= 382; };
    indicator "Caps Lock"    { left= 407; };
    indicator "Scroll Lock"  { left= 433; };
    text.top= 25;
    text.color= "black";
    text "NumLockLabel" { left= 378; text="Num\nLock"; };
    text "CapsLockLabel" { left= 403; text="Caps\nLock"; };
    text "ScrollLockLabel" { left= 428; text="Scroll\nLock"; };

    section.left= 19;
    row.left= 1;
    key.shape= "NORM";
    key.gap=  1;
    section "Function" {
top= 22;
row {
    top= 1;
    keys {  { <ESC>, "TABK", color="grey20" },
    { <FK01>, 10 }, <FK02>, <FK03>, <FK04>,
    { <FK05>, 11 }, <FK06>, <FK07>, <FK08>,
    { <FK09>, 11 }, <FK10>, <FK11>, <FK12>,
    { <PRSC>, 8 }, <SCLK>, <PAUS>
    };
};
    }; // End of "Function" section

    section "Alpha" {
top= 61;
row {
    top= 1;
    keys { <TLDE>, <AE01>, <AE02>, <AE03>, <AE04>,
   <AE05>, <AE06>, <AE07>, <AE08>, <AE09>,
   <AE10>, <AE11>, <AE12>,
   { <BKSP>, "BKSP", color="grey20" }
    };
};
row {
    top= 20;
    keys { { <TAB>, "TABK", color="grey20" },
   <AD01>, <AD02>, <AD03>, <AD04>, <AD05>,
   <AD06>, <AD07>, <AD08>, <AD09>, <AD10>,
   <AD11>, <AD12>, { <RTRN>, "RTRN", color="grey20" }
    };
};
row {
    top= 39;
    keys { { <CAPS>, "CAPS", color="grey20" },
   <AC01>, <AC02>, <AC03>, <AC04>, <AC05>,
   <AC06>, <AC07>, <AC08>, <AC09>, <AC10>,
   <AC11>, <BKSL>
    };
};
row {
    top= 58;
    keys { { <LFSH>, "LFSH", color="grey20" },
    <LSGT>, <AB01>, <AB02>, <AB03>, <AB04>, <AB05>,
    <AB06>, <AB07>, <AB08>, <AB09>, <AB10>,
    { <RTSH>, "RTSH", color="grey20" }
    };
};
row {
    top= 77;
    key.shape= "MODK";
    key.color= "grey20";
    keys { <LCTL>, { <LALT>, 20 },
   { <SPCE>, "SPCE", color="white" },
   <RALT>, { <RCTL>, 21 }
    };
};
    }; // End of "Alpha" section

    section "Editing" {
top= 61;
left= 312;
key.color= "grey20";
row {
    top= 1;
    keys { <INS>, <HOME>, <PGUP> };
};
        row {
    top= 20;
    keys { <DELE>, <END>, <PGDN> };
};
row {
    top= 58;
    left= 20;
    keys { <UP> };
};
row {
    top= 77;
    keys { <LEFT>, <DOWN>, <RGHT> };
};
    }; // End of "Editing" section

    section "Keypad" {
top= 61;
left= 376;
row {
    top= 1;
    key.color= "grey20";
    keys { <NMLK>, <KPDV>, <KPMU>, <KPSU> };
};
row {
    top= 20;
    keys { <KP7>, <KP8>, <KP9>, { <KPAD>, "KPAD", color="grey20" } };
};
row {
    top= 39;
    keys { <KP4>, <KP5>, <KP6> };
};
row {
    top= 58;
    keys { <KP1>, <KP2>, <KP3>, { <KPEN>, "KPAD", color="grey20" } };
};
row {
    top= 77;
    keys { { <KP0>, "KP0" }, <KPDL> };
};
    }; // End of "Keypad" section

    alias <AC00> = <CAPS>;
    alias <AA00> = <LCTL>;

}; // End of "pc102" geometry

If something like KLA could read these files (or a different format that encapsulates the same info) then we could evaluate all different types rather than the 3/4 we can do now...

There is a project on Github that is trying to create a multi-use layout description format but he's still got a way to go ...

https://github.com/ellisgl/keyboard-schema

There's also KLE json but that's not particularly pleasant either.

Anyone know of any other projects along these lines? Especially with many already defined.

Thanks, Ian

Den

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1356
  • Selina is my Superstar
    • View Profile
    • Amuseum
Re: Keyboard Geometries
« Reply #1914 on: 2020-Sep-19 22:25 »
the saying goes like "trying to create a universal perfect standard to replace all other imperfect standards, is only creating another standard that no one uses." (from xkcd maybe? )



(That said, VSV is the superior format.)

Rather than create new format, better to create a general parser that accepts various well known formats. isn't xkb open source? should be easy to locate its parser.
« Last Edit: 2020-Sep-19 22:36 by Den »
Support me on Patreon

I saw. I conquered. I came.

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: Keyboard Geometries
« Reply #1915 on: 2020-Sep-20 03:46 »
Rather than create new format, better to create a general parser that accepts various well known formats.

Yeah, a multi-converter has been percolating in the back of my head probably for years now. But it's not trivial, especially if something like QMK is in the mix.

Then there's other things like KLE supporting 12 glyphs per key, and KLA (default) only 4.

isn't xkb open source? should be easy to locate its parser.

A while back you said you need to be somewhere on the austistic spectrum to understand xkb... :-)

I have a basic understanding of parts of it (user side, not code side) but could still not add my current layout "cleanly", so ended up hacking the Colemak layout instead. I did manage to do it before so dunno what I did wrong / overlooked this time, unless some update introduced a subtle change somewhere.

In theory I would agree with you, but it kinda reminds me of what I learnt in the recent exercise to get plain text out of Wikipedia... WikiMedia is open source, but the parsing routine is apparently one 5,000 line PHP function, with unpleasant code.

I did actually writing a KLE to KLA converter which at the moment only handles simple ANSI layouts, but that's the bulk of the use cases for alternate layouts. I have different proggie that takes KLA json and populates a blank keyboard png with appropriate glyphs (rather than trying to write out KLE json). This handles ANSI/Ergodox/Matrix/Ergolinear.

Speaking of ErgoLinear, I think I'm going to retire the format and convert them to Matrix ... will help to debloat KLA and from an analysis perspective they're the same ,,,

Cheers, Ian


iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: Keyboard Geometries
« Reply #1916 on: 2020-Sep-23 07:21 »
Yeah, a multi-converter has been percolating in the back of my head probably for years now. But it's not trivial, especially if something like QMK is in the mix.

The basic idea of course was to read in any of the existing 14 inferior standards, convert them to the superior, flexible 15th standard, and write out either that, or one of the 14 others (for some value of "14").

I did actually writing a KLE to KLA converter which at the moment only handles simple ANSI layouts,

Actually have both kle2kla and kla2kle json converters, according to comments handles ansi104, iso105 and applewireless. Did it more than 2 years ago ....

Extending for Ergodox and Kinesis was on ToDo list. Will have to make a Matrix layout and persuade KLE author to include it in templates.

I do have separate program that populates blank layouts with glyphs from KLA json.

I don't know if vsv is appropriate format for this ... I'm not a JSON fan (it falls under Bracket Soup category, and is messy to find missing brackets and/or comma visually).

I did consider YAML but have same issues with that as with Python ... mess up the spacing and things break. But does the world need a better JSON? :-)

Maybe other editors than Kate handle Json errors better / more dramatically?

FWIW I tested KLA json with 2 different online converters, some lines from each :

Code: [Select]
label: nirvana.en.matrix.test
fingerStart:
  '1': 25
  '2': 26
  '3': 27
  '4': 28
  '5': 56
  '6': 59
  '7': 31
  '8': 32
  '9': 33
  '10': 34
  '11': -1
  'false': -1
keyboardType: matrix
author: Ian Douglas
authorUrl: ''
moreInfoUrl: 'http://keyboard-design.com'
moreInfoText: Keyboard Design
keys:
  - primary: 27
    shift: -1
    finger: 1
    id: 0
    altGr: -1
    shiftAltGr: -1
    numpad: -1
  - primary: 52
    shift: 91
    finger: 1
    id: 1
    altGr: 96
    shiftAltGr: -1
    numpad: -1

Code: [Select]
label: "nirvana.en.matrix.test"
fingerStart:
 1: 25
 2: 26
 3: 27
 4: 28
 5: 56
 6: 59
 7: 31
 8: 32
 9: 33
 10: 34
 11: -1
 false: -1
keyboardType: matrix
author: "Ian Douglas"
authorUrl: ""
moreInfoUrl: "http://keyboard-design.com"
moreInfoText: "Keyboard Design"
keys:
 -
   primary: 27
  shift: -1
  finger: 1
  id: 0
  altGr: -1
  shiftAltGr: -1
  numpad: -1
 -
   primary: 52
  shift: 91
  finger: 1
  id: 1
  altGr: 96
  shiftAltGr: -1
  numpad: -1

Also discovered YAML supports brackets-based syntax .... learn something new every day :-)

But KLE json not so pleasant:

Code: [Select]
- backcolor: '#d7ebe3'
  name: Nirvana 0.5
  author: Ian Douglas
  radii: 45px
  switchMount: cherry
  switchBrand: cherry
  switchType: MX1A-G1xx
  plate: true
- - 'y': 0.45
    x: 7.4
    c: '#95bfe8'
  - |-

    Print Scrn
  - |-

    Scroll Lock
  - |-
    Pause
    Break
- - 'y': -0.34999999999999987
    x: 17.55
  - |-

    All
  - |-
    Redo
    Undo
  - c: '#6ca29d'
  - |-
    Bksp
    Del
  - x: 0.34999999999999787
    c: '#93c9b7'
  - |-

@Den, what would vsv look like?

« Last Edit: 2020-Sep-23 07:35 by iandoug »

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Fixed and variable costs
« Reply #1917 on: 2020-Sep-23 07:49 »
At the moment KLA adds up cost of typing a character as

(finger penalty) × (distance), for each finger involved.

This is a variable cost based on which finger, and distance.

I'm pondering if we also need a fixed cost for number of fingers used.

To take extreme example of character on Shift-AltGr:

Current: (finger penalty for actual char) × (distance) + (finger penalty for shift) × (distance) + (finger penalty for AltGr) × (distance)

Should it be?: ((finger penalty for actual char) × (distance) + finger charge 1) + ((finger penalty for shift) × (distance)  + finger charge 2) + ((finger penalty for AltGr) × (distance) + finger charge 3)

And if so, should the finger charges vary by finger?

Or maybe this is already encapsulated in the finger penalty?

Nitpicking welcome :-)

moesasji

  • Valued Member
  • ***
  • Posts: 68
    • View Profile
Re: Fixed and variable costs
« Reply #1918 on: 2020-Sep-23 15:19 »
Should it be?: ((finger penalty for actual char) × (distance) + finger charge 1) + ((finger penalty for shift) × (distance)  + finger charge 2) + ((finger penalty for AltGr) × (distance) + finger charge 3)

Personally I think that it should be the above version to properly reflect that each key-press has a cost associated with it; my logic for this is that the idea that two key-presses is the same as three as long as AltGr is under your thumb (or on the home-row) as implied by the first formula can't be right.

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: Fixed and variable costs
« Reply #1919 on: 2020-Sep-23 16:00 »
Personally I think that it should be the above version to properly reflect that each key-press has a cost associated with it; my logic for this is that the idea that two key-presses is the same as three as long as AltGr is under your thumb (or on the home-row) as implied by the first formula can't be right.

That is true for KLA original, which is why Den 1 and later also includes the vertical distance (4mm down, 4 mm up).

But I dunno if that is enough or not.

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Went back to the drawing board ....
« Reply #1920 on: 2020-Sep-24 17:00 »
I've been using the layout in https://ieants.cc/smf/index.php?topic=89.msg3072#msg3072 for the last few weeks. Still have to look at keys to type, else muscle memory kicks in and I type QWERTY... I did swap C and W to make the CH bigram more comfortable.

However.... a database I work on daily has numerous fields with "number" in their name, and that MB on same finger was annoying me ... so I tried to fix it.

When basic 2-letter swaps did not get a better-scoring layout, it was time for more drastic action .... and as usual, one thing led to another ... which led to attached layout.

It scores VERY well at English on KLAtest (input-dependent as always). For code, you need to press the numlock button and switch it to "programmer" style, where the numbers become shifted and the punctuation not, in order to compete with x1-b13-final and BEAKL Arr 29k 1.

In truth I am still busy trying to optimise the punctuation layout, so that's still a "work in progress:. But I think English is good for now.

Changes compared to previous:

1. We lose the "way cool" TH, SH, CH and WH left hand bigrams, but instead gain NG, and HE, HI and HA. In truth, this is better... Here's the list of top 31 bigrams from the recent "Corpus" exercise (excluding those with space or comma), and SH, CH and WH do not feature, but NG, HE, HI and HA do.

Code: [Select]
th 9554096
he 9111069
in 7080765
er 6165354
an 5842280
re 5269816
on 4764032
en 4083652
at 4074150
nd 4047235
ed 3669892
es 3650832
or 3647548
te 3389944
ti 3382711
ar 3283567
to 3231160
is 3184918
it 3183093
ng 3148976
st 3090607
of 2999090
al 2962519
nt 2884056
ou 2870991
ha 2852182
as 2762100
se 2561667
ve 2490815
le 2473957
hi 2284181

2. Lose CS on same finger. That was another annoyance.

3. Get FRM back, which was in the earlier laoyuts at the start of this round, and which I liked.

4. Lose MB on same finger.

5. It does have RNL on same finger (which always triggers NEARLY LEARN in my head) but those combinations are way down on the bigram list.

6. Gain QU bigram.

I've attached KLE version of next board I'm building. I feel a bit like Jesse from KeyboardIO .. go round in circles finding what works on paper but not reality.

So after exploring various designs from maximal to minimal, I'm kinda back where I started .. with the MS Natural.

My hands and head are so used to it, and it's not actually a bad design (unlike all its children.... ).

So I applied my mind to fix the annoyances .. these changes are to suit my usage needs. Starting with trackball on left hand, so Nav cluster and numpad on right are not a problem. And I'm not a gamer.

Tweaks:

1. arrow keys on home row

2. integrated into Home/End/PageUp/PageDown cluster

3. Extra tab key, with convenient Alt and Shift close by.

4. Copy/Cut/Paste/SelectAll/Undo/Redo keys

5. Enhanced numpad with characters often needed when working with numbers: space, comma, parentheses (phone numbers), colon (time), degree and quotes (also for feet/inches), percent.

6. Provision for Dozenal

Basically I am trying to put all needed keys and chars close by for navigation, and working in spreadsheets.

7. Keys are colour-coded:
white: chars
yellow: modifiers
blue: movement
green: functional

8. AltGr renamed to AltSym :-)

9. No Win or Menu keys, but Compose key instead.

Think that's about it ...

@Den: decided to go for cream rather than black ...

Cheers, Ian




moesasji

  • Valued Member
  • ***
  • Posts: 68
    • View Profile
Re: Went back to the drawing board ....
« Reply #1921 on: 2020-Sep-24 17:56 »
I've been using the layout in https://ieants.cc/smf/index.php?topic=89.msg3072#msg3072 for the last few weeks. Still have to look at keys to type, else muscle memory kicks in and I type QWERTY... I did swap C and W to make the CH bigram more comfortable.

Looks good and in many ways familiar to one that I've used for a bit: https://ieants.cc/smf/index.php?topic=89.msg3069#msg3069. The key thing that annoyed me in practice is the placement of the "w"; for me that is too much of a stretch in many common English words, which isn't really reflected in the score even though the problem is very clear when looking at the heat-map for common words.

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: Went back to the drawing board ....
« Reply #1922 on: 2020-Sep-25 06:35 »
Looks good and in many ways familiar to one that I've used for a bit: https://ieants.cc/smf/index.php?topic=89.msg3069#msg3069.

Yes I noticed, was not a case of copying but arriving in same place via different routes.

Sometimes I feel like we are water circling a drain .. getting closer and closer until we reach the goal.

Every time I make a new layout I think it is The Ultimate and can't be improved.

Been consistently wrong about that so far :-)

Cheers, Ian

Den

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1356
  • Selina is my Superstar
    • View Profile
    • Amuseum
Re: Keyboard Geometries
« Reply #1923 on: 2020-Sep-25 07:36 »
VSV possible formatting:

Code: [Select]

[[meta]]
:label:nirvana.en.matrix.test
:keyboardType:matrix
:author:

,fingerStart,25,26,27,28,56,59,31,32,33,34,-1,-1

[[keys]]
-key-0
.finger.1
.base.27

-key-1
.finger.1
.base.52
.shift.91
.altGr.96


VSV has two types of lines: header & data. Use headers to lead into sections. Data lines must be led by delimiter. Any character except space can be delimiter, but must not collide with data values on same line. Trivial to write a function that finds safe delimiters when exporting to VSV.

Den

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1356
  • Selina is my Superstar
    • View Profile
    • Amuseum
Re: [BEAKL] Balanced Effortless Advanced Keyboard Layout
« Reply #1924 on: 2020-Sep-25 07:47 »
After testing several layouts, BEAKL 15 still feels most intuitive. That said, still testing a new vowel district.

Code: [Select]
Vowel district (left hand)

quiox
yhea.
jk",'

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: [BEAKL] Balanced Effortless Advanced Keyboard Layout
« Reply #1925 on: 2020-Sep-25 08:29 »
After testing several layouts, BEAKL 15 still feels most intuitive. That said, still testing a new vowel district.

Code: [Select]
Vowel district (left hand)

quiox
yhea.
jk",'

Mmm.. also been thinking about I on E.

Relevant lines from bigram counts: (first number is rank) (lower case only)
Code: [Select]
113 ie     1110203
188 ei      541476

319 eo      212329
413 oe      106013

116 ai    1094614
146 ia      788938

241 ua      362114
252 au      333545

323 oa      206142
1011 ao      12208

228 ue      396727
558 eu       51430

26i ui      317385
637 iu       37554


Suspect ie is going to annoy you presently ... :-)
Tho suppose it depends on what you type. Wonder why Webster didn't drop the ie for e when he wrote his dictionary ...
« Last Edit: 2020-Sep-25 08:32 by iandoug »

moesasji

  • Valued Member
  • ***
  • Posts: 68
    • View Profile
Re: Went back to the drawing board ....
« Reply #1926 on: 2020-Sep-25 16:39 »
Every time I make a new layout I think it is The Ultimate and can't be improved. Been consistently wrong about that so far :-)

That sounds extremely familiar and the only way to know is by typing until you get fast....currently really starting to doubt my choice of not putting the 'period' and 'comma' on the main layer, mainly as I keep mixing them up.....the one below is probably the next tweak.

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: Went back to the drawing board ....
« Reply #1927 on: 2020-Sep-25 17:41 »
currently really starting to doubt my choice of not putting the 'period' and 'comma' on the main layer

They are used more than some letters ...

Code: [Select]
        count            %
155976752 16.13296
e 92951452 9.61414
t 66746140 6.90367
a 60386686 6.2459
o 56255022 5.81856
i 53359184 5.51904
n 53334218 5.51646
s 47899576 4.95434
r 46904830 4.85145
h 38381172 3.96983
l 30924224 3.19855
d 29058834 3.00561
c 22468134 2.32392
u 20412350 2.11129
m 17658918 1.82649
f 16561554 1.71299
p 14609274 1.51106
g 14400664 1.48949
w 13236000 1.36902
13018308 1.34651
y 12846008 1.32869
b 10596296 1.09599
, 9450322 0.97746
. 8030840 0.83064
v 7655594 0.79183
k 4808796 0.49738
' 3451252 0.35697
T 2882430 0.29813
I 2648456 0.27393
- 2305734 0.23849
A 2228858 0.23053
S 2199910 0.22754
C 1756500 0.18168
" 1521356 0.15736
x 1507316 0.1559
1 1493952 0.15452
M 1461842 0.1512
B 1440628 0.14901
H 1287100 0.13313
E 1209628 0.12511
P 1201828 0.12431
0 1163708 0.12036
R 1061378 0.10978
W 1052984 0.10891
N 970604 0.10039
D 943406 0.09758
L 929858 0.09618
G 872958 0.09029
O 871534 0.09014
F 846344 0.08754
9 807174 0.08349
j 759624 0.07857
q 753342 0.07792
2 728064 0.0753
) 643288 0.06654
( 638128 0.066
z 570002 0.05896
(other stuff follows after)

@Den: how do I edit in fixed pitch font? Trying to line up variable font with misbehaving tabs is frustrating... :-)
« Last Edit: 2020-Sep-25 17:46 by iandoug »

moesasji

  • Valued Member
  • ***
  • Posts: 68
    • View Profile
Re: Went back to the drawing board ....
« Reply #1928 on: 2020-Sep-26 03:01 »
They are used more than some letters ...

Fully aware of that they tend to come ahead of the v,k. The trade-off I was playing with is the benefits of not having to move my fingers at all at the expense of needing AltGr....it might simply that the 'e' is just too frequent to also put the period on (the comma on 'n' works).

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: Went back to the drawing board ....
« Reply #1929 on: 2020-Sep-26 03:48 »
The trade-off I was playing with is the benefits of not having to move my fingers at all at the expense of needing AltGr....it might simply that the 'e' is just too frequent to also put the period on (the comma on 'n' works).

Curious. :-)

Now if I can get a table to work ...

percentage chance that letter will be followed by ...
Letter period comma
e 1.15343 1.41552
n 1.08053 1.42568
a 0.18533 0.27577

But I suppose we need to multiply those by their relative frequency ... so

e. = 1.15343 x 9.61414  = 11.0892375
n, = 1.42568  x 5.51646 = 7.86471

a. = 0.27577 x 6.2459 = 1.722432

Maybe you could test "a." and see how it feels?

Cheers, Ian

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: Went back to the drawing board ....
« Reply #1930 on: 2020-Sep-26 04:24 »
Fully aware of that they tend to come ahead of the v,k.

I was trying to hint at what I've seen on some layouts: they put the minor letters on AltGr. :-)

Which may require some mental rewiring to use.

Also, those "minor" letters are used for hot-keys ... which is annoying for layout purposes.

Was thinking yesterday (after the "IE / EI" discussion) again about a phonetic keyboard (one sound per key, but not that clunky IPL alphabet... need something better.)
Den made an alphabet (Flownetic), as did I (Latian)...

https://www.keyboard-design.com/pangalactic.html

Need more than 33 sounds for English so punctuation would need to be on AltGr unless we add more keys, or switch back to UniCase ...

I did some keyboard layouts for some West African languages, was quite messy because they rely on "tone" marks, which are more frequent than most of their letters ...




moesasji

  • Valued Member
  • ***
  • Posts: 68
    • View Profile
Re: Went back to the drawing board ....
« Reply #1931 on: 2020-Sep-26 05:19 »
But I suppose we need to multiply those by their relative frequency ... so

e. = 1.15343 x 9.61414  = 11.0892375
n, = 1.42568  x 5.51646 = 7.86471

That those are so similar is indeed very curious.

Logic would indeed dictate that putting the 'period' on 'a' would be a good solution, but that messes with my placement of the doublequote that comes either at the end of a word or after an opening bracket. Probably the compromise below is the one I need to try next. Weirdly enough swapping the doublequote and period in that layout scores consistently worse....not sure why.

btw) putting non-frequent letters under AltGr is not really an option for me as those, like for example Q, tend to be very frequent in editor-shortcuts or commands. Note that this is also why you see some of the less used symbols appear on prime positions in my layout as 'CTRL  _' is for example undo in Emacs.

Den

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1356
  • Selina is my Superstar
    • View Profile
    • Amuseum
Re: Went back to the drawing board ....
« Reply #1932 on: 2020-Sep-26 06:13 »
@Den: how do I edit in fixed pitch font? Trying to line up variable font with misbehaving tabs is frustrating... :-)

First, jot in text editor, then copy to browser. That's true for any browser editing because they overtake the tab key.

Use "tables" tag, with option to choose among various formats with simpler intuitive syntax than HTML, like VSV, CSV, markdown,  RST, wikitable.
« Last Edit: 2020-Sep-26 06:21 by Den »

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: Went back to the drawing board ....
« Reply #1933 on: 2020-Sep-26 07:43 »
Logic would indeed dictate that putting the 'period' on 'a' would be a good solution, but that messes with my placement of the doublequote that comes either at the end of a word or after an opening bracket. Probably the compromise below is the one I need to try next. Weirdly enough swapping the doublequote and period in that layout scores consistently worse....not sure why.

Mmm. Now I understand the difference between the two tables. (attached). My whole "corpus" exercise was to get versions of these for all chars, for English and code. The site they were on did mouseovers to show actual values. Site is broken now.

I've made the first one (spreadsheet) for English, must do the other three.







iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: Went back to the drawing board ....
« Reply #1934 on: 2020-Sep-26 08:21 »
Logic would indeed dictate that putting the 'period' on 'a' would be a good solution, but that messes with my placement of the doublequote that comes either at the end of a word or after an opening bracket. Probably the compromise below is the one I need to try next. Weirdly enough swapping the doublequote and period in that layout scores consistently worse....not sure why.

Suggestions which may or may not work for your hands :-)

moesasji

  • Valued Member
  • ***
  • Posts: 68
    • View Profile
Re: Went back to the drawing board ....
« Reply #1935 on: 2020-Sep-26 08:46 »
Suggestions which may or may not work for your hands :-)

Thanks for that as I thought I had tried that swap of the double-quote with the comma, but I clearly didn't as that indeed looks better.

btw) the placement of the quote I have might look strange, but that is just a reflection of having to type '( a lot in emacs lisp and it makes little difference in the score.

moesasji

  • Valued Member
  • ***
  • Posts: 68
    • View Profile
Re: Went back to the drawing board ....
« Reply #1936 on: Yesterday at 05:39 AM »
Suggestions which may or may not work for your hands :-)

I decided to just try your suggestions as they are, although with backspace on Capslock. This tweak is working extremely well and on my laptop I am now back to reasonable speeds having switched cold turkey to a mirrored layout 4 or 5 weeks ago (see screenshot). During this time I've still been making very big chances to the layout and the speed you see is having swapped the punctuation only yesterday!

With my key problem the pretty high error rate (~10% of key-presses) that still results from the mirroring I did a couple of weeks ago this layout is bound to age very well. :)

btw) the thing that feels a bit uncomfortable is the double-quote followed by a capital as needed when typing quotes....in real typing I think that is pretty rare and this problem is almost unavoidable with brackets on the AltGr layer.


iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: Went back to the drawing board ....
« Reply #1937 on: Yesterday at 06:23 AM »
I decided to just try your suggestions as they are, although with backspace on Capslock. This tweak is working extremely well

Translation: KLAtest is doing a good job at evaluating layouts.

Started playing with https://github.com/Tretygon/keygen last night. (visitor to my site pointed it out to me)
First layout it gave me was not good... So I gave it a better corpus, and better reference layouts than QWERTY and Dvorak, which produced a better result, but not better than things we've come up with here. I don't see how random swaps will work.

Also I suspect the weighting on the various metrics needs tweaking.

Cheers, Ian

moesasji

  • Valued Member
  • ***
  • Posts: 68
    • View Profile
Re: Went back to the drawing board ....
« Reply #1938 on: Yesterday at 06:45 AM »
Translation: KLAtest is doing a good job at evaluating layouts.

Started playing with https://github.com/Tretygon/keygen last night. (visitor to my site pointed it out to me)
First layout it gave me was not good... So I gave it a better corpus, and better reference layouts than QWERTY and Dvorak, which produced a better result, but not better than things we've come up with here. I don't see how random swaps will work.

I remember playing with the upstream optimizer of that one in my quest to find a better layout. My general impression is that you get a decent start-point on the frequent keys that fits with the model the specific optimizer aims for, but that the less frequent keys are way to sensitive to the corpus you feed it. The trick I did with your help is to tweak one of these layouts to reduce the same finger using the tables I found on the ThinQu website: https://microexploitation.com/2018/06/26/the-development-of-the-thinqu-keyboard-layout-factors-that-influence-typing-effort/ with the help of KLA. For that reason I'm really looking forward to see your tables that include the symbols!

btw) the other one of your efforts that would really help is to make it easier to get an overview of how different layouts do in all the corpuses that are on KLA-latest

Den

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1356
  • Selina is my Superstar
    • View Profile
    • Amuseum
Re: Fixed and variable costs
« Reply #1939 on: Yesterday at 07:33 AM »
Personally I think that it should be the above version to properly reflect that each key-press has a cost associated with it; my logic for this is that the idea that two key-presses is the same as three as long as AltGr is under your thumb (or on the home-row) as implied by the first formula can't be right.

Each use of modifiers already incur extra penalty to finger usage scores, and sometimes same finger or same hand.

Also you're implying home keys should have no advantages? The entire concept of home keys is moot?

Why does it matter it takes more fingers, if it's done faster and easier to reach? For that matter, if one thumb can hold down two adjacent modifier keys at once, should be no different than single modifier. (Albeit easier if thumb keys only 1u size.)

The fear or repulsion against layers via modifier key is more mental burden or effort. However not sure that can be quantified.

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: Went back to the drawing board ....
« Reply #1940 on: Yesterday at 08:10 AM »
btw) the other one of your efforts that would really help is to make it easier to get an overview of how different layouts do in all the corpuses that are on KLA-latest

Last such exercise was at end of 2017, though it doesn't feel so long ago.
https://www.keyboard-design.com/best-layouts.html
But that has averages rather than per-test.

I've learned a lot since then. In particular, a lot of the input texts on KLA are not very good. I sourced a lot of them, my thinking at the time was to get "varied" inputs with the assumption that that would sort out letter frequency issues, but it didn't really. People tend to test against only a handful of different inputs.

During the interim, Firefox changed their plugin structure which broke iMacros, that I used to run the tests. Doing all the tests took a lot of time as well.

Hence the rethink, which led to the recent corpus exercise. I'm thinking that, armed with char frequency tables for English and code, plus "letter follows" probability, we can dispense with input texts altogether. If I understand what Den said, then it's similar to how Opt works.

We can even evaluate for both English and code the the same time, with different weightings, eg 80% English, 20% code, or somesuch.

If I write this in a compiled language then it should be much faster than Javascript.

Let me see if I can get the spreadsheets done.

Cheers, Ian

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: Fixed and variable costs
« Reply #1941 on: Yesterday at 08:18 AM »
Each use of modifiers already incur extra penalty to finger usage scores, and sometimes same finger or same hand.

Okay..

Why does it matter it takes more fingers, if it's done faster and easier to reach?

More physical effort, though I was wondering if there is more mental effort as well. On the the other hand, once it becomes hard-wired like ctrl-c or ctrl-t then maybe it's a moot point...

The fear or repulsion against layers via modifier key is more mental burden or effort. However not sure that can be quantified.

Quantifying it is the issue. :-)

Which is why I floated the idea. But if scoring already penalises, then it's okay.

Cheers, Ian

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: Went back to the drawing board ....
« Reply #1942 on: Yesterday at 08:27 AM »
Last such exercise was at end of 2017, though it doesn't feel so long ago.
https://www.keyboard-design.com/best-layouts.html
But that has averages rather than per-test.

Idiot. Forgot about this:

https://www.keyboard-design.com/best-layouts-interactive-explorer.html

moesasji

  • Valued Member
  • ***
  • Posts: 68
    • View Profile
Re: Fixed and variable costs
« Reply #1943 on: Yesterday at 08:34 AM »
Each use of modifiers already incur extra penalty to finger usage scores, and sometimes same finger or same hand.

Also you're implying home keys should have no advantages? The entire concept of home keys is moot?

For clarity I was commenting on the two formulas that Ian was posting. The other one was: (finger penalty for actual char) × (distance) + (finger penalty for shift) × (distance) + (finger penalty for AltGr) × (distance).

For that formula you get zero penalty when your fingers rest on the key even though you need to press two keys instead of one for a single character ... this formula would hence favor having a key on the AltGr layer on the home-row over having that same key on something like the Qwerty E position and in my opinion that can't be right as someone who makes heavy use of the AltGr layer. Applying some penalties for all keys, including the ones on the home-row and modifiers that are under the thumb would fix that and allow to tweak the penalty in such a way that "easy" keys on the main layer are favored.

btw) fully agree that the home-row and homeblock are prime positions to use.


moesasji

  • Valued Member
  • ***
  • Posts: 68
    • View Profile
Re: Went back to the drawing board ....
« Reply #1944 on: Yesterday at 08:42 AM »
Last such exercise was at end of 2017, though it doesn't feel so long ago.
https://www.keyboard-design.com/best-layouts.html
But that has averages rather than per-test.

Personally I think it is best to be able to see the breakdown per type of text to be able to optimize as for example the writing style of academic texts or a piece of code is very different from an email. I don't think you can simultaneously optimize for all use-cases.

edit) this one: https://www.keyboard-design.com/best-layouts-interactive-explorer.html only applies to layouts that have been uploaded; you can't use it to tweak your own.

moesasji

  • Valued Member
  • ***
  • Posts: 68
    • View Profile
Re: Fixed and variable costs
« Reply #1945 on: Yesterday at 09:01 AM »
More physical effort, though I was wondering if there is more mental effort as well. On the the other hand, once it becomes hard-wired like ctrl-c or ctrl-t then maybe it's a moot point...

As someone who uses the AltGr layer and actually tried to learn one of the Seelpy layouts I think the problem comes down to loosing the rolls when having to switch between layers. Easiest way to see that problem is if you need to hit a modifier to access a key for the second key in a trigram. You need to be absolutely sure that you've hit and released the first key before pressing the modifier and the next key or you get garbage...the effect is that the layer switch tends to slow you down (but less than having to use hard to reach keys).

Unfortunately really difficult to capture and quantify this


iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: Went back to the drawing board ....
« Reply #1946 on: Yesterday at 11:52 AM »
Let me see if I can get the spreadsheets done.

Attached.

.tsv == tab separated values, Excel/LibreOffice should handle fine.

The rawfollow files are basically bigrams used to generate the -follow- and -precede- files.

Also the char frequency files included.

At some point when doing this I had issues with the chars I was using for space, enter and tab ... can't remember if it was PHP being silly or MySQL being pedantic. So different chars used depending on file.

§ or ⍽ is space
¶ or ⮠ is enter
¬ or ⭲ is tab

For -follow- and -precede- files, in English check "qu" and "ex" ... that will help you wrap your head around the numbers. Or see the two image grids a few messages above as a partial guide.

Have fun.


moesasji

  • Valued Member
  • ***
  • Posts: 68
    • View Profile
Re: Went back to the drawing board ....
« Reply #1947 on: Yesterday at 02:52 PM »
.tsv == tab separated values, Excel/LibreOffice should handle fine.

LibreOffice does something weird as I don't see a 2D array; probably one of the symbols is messing up the import. I'll just be lazy and wait for the plots. ;)

Den

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1356
  • Selina is my Superstar
    • View Profile
    • Amuseum
Re: [BEAKL] Balanced Effortless Advanced Keyboard Layout
« Reply #1948 on: Yesterday at 03:12 PM »
Layers are somewhat like chording. it's definitely a different paradigm, that could run counter to familiar techniques like rolls. and likely require more practice to perfect.

iandoug

  • Hero Member
  • *****
  • Posts: 1094
    • View Profile
    • Keyboard Design
Re: Went back to the drawing board ....
« Reply #1949 on: Yesterday at 04:07 PM »
LibreOffice does something weird as I don't see a 2D array; probably one of the symbols is messing up the import. I'll just be lazy and wait for the plots. ;)

On the import dialogue, select Tab as separator, and make sure string delimiter is set to nothing.


 

2 Guests, 0 Users