Probably the biggest thing you've missed are some of the existing projects, specifically
carpalx, Capewell's Keyboard Evolve, and Klauser's evolved layout.

Moreover, Ruby is a really bad choice for a language for such project because it's one of the slowest languages and a keyboard layout genetic algorithm needs to iterate through an astronomic amount of possible keyboard layouts for best results. Such a project should be written with a faster such language, such as C, C++, Java or D.

I don't see why you penalize same-finger typing so hard. Some cases would warrant it, others not I think. For instance, the index fingers will easily type for instance "ln" in my experience. Try typing kiln kiln kiln kiln kiln with Colemak (or think up another similar case in dvorak if that's your poison) - it isn't so bad as you seem to imply. "Illness" of course, is awful.  :)

I can't say for sure, but all the aforementioned attempts at optimization algorithms (including yours) strike me as subject to somewhat arbitrary (or at the very least, highly subjective) rule sets, and the result is probably quite dependent on those. Your evolved layout can only be as good as the correlation between your axioms and actual typing efficiency. It will be a fun and interesting exercise for sure, but will it actually reflect layout quality for most users - or even for yourself?

You're already making assumptions, so why not make a few more while you're at it, and help your poor Ruby cope a little better in the process?

If for instance you force the 6-8 (or maybe 10?) most common keys to the home row your algorithm will have a much easier time of it already. Furthermore, if you force the 10 or so least common characters that are already in hard-to-reach QWERTY positions to stay put you'll gain some of the advantages of Colemak and likely not sacrifice anything noticeable (I'd let QWZXC,.'- stay in place, and probably M as well). If you don't give a rat's ass about QWERTY since you're Dvorak trained and don't need to use QWERTY at all, then by all means do the same thing with rare keys in awkward Dvorak places - after all, you're doing this only for yourself and not for the public.

By the way, I think your same-hand penalty looks elegant. Subjective of course, but interesting. Your top/bottom penalty also seems like a good idea to me.

I have not tested QWERTY, and don't plan to, because I already know it sucks. Since scoring Dvorak, I have changed the scoring methods by increasing all the numbers by a lot so as to make the scoring more accurate. Colemak scores 6.548, and Dvorak with U and I switched scores 6.607. Also Capewell layout scores 7.054 and Arensito scores 7.421. But I believe my scoring system must be skewed, because my algorithm is coming up with layouts that score under 6, and they are clearly not that much better (if better at all, which is unlikely) than Dvorak or Colemak. Also I find it a bit surprising that Arensito and Capewell do worse than Dvorak.

One interesting thing I noticed is that almost every layout it generates has 3 or 4 of the vowels on one side of the home row.

Best layout so far, scoring 5.79 (not necessarily the best, but lowest score)

v l d b j z  f o m u
r h s n c y a e t i
q k x p ' g . ; w ,

The algorithm has a tendency to knock O off the home row.

(By the way, I took DreymaR's advice into account and lowered penalty for same finger to 30.)

And about restricting common keys to the home row, I am working on that. Which means I will probably start working on it within the next month or so.

I will probably at some point post my programs on my blog, which is at mtgap.bilfo.com/blog

What is your layout? EDIT: never mind, I found it here: http://www.sagez.net/amuseum/layout.php
P.S. I love your BFUCK layout, that's exactly what I was thinking when I saw Arensito!

I have made some changes to my scoring program, and due to these changes, I will be tweaking the program for a while. On Capewell's genetic algorithm, he had a penalty for skipping over the home row, but the penalty was reduced if certain combinations were used, because they were easier to type. I didn't want to do anything like that because it would require something like this:

if skips over home row:
  add 30 to score
  if 1st location = w and 2nd location = v OR 1st location = o and 2nd location = n OR.....

And it does that about 15 times. That takes a lot of code, at least in Ruby. Maybe there is some better way of doing it in C++. Anyway, what I did under the revised program was only have a penalty for certain cases of row skipping.

+ 25 for same finger twice, and + 10 more if skipping a row
+ (5*n) for typing with the same hand for the nth time after the 2nd, except when rolling inward along the same row
(QWERTY positions) moving upward and outward (relative to 1 hand, not the whole keyboard) or downward and inward adds 10, and an additional 10 if it skips over the home row

Finger penalties are still the same.

I haven't run the genetic algorithm yet with this new scoring system. But with the previous scoring system, it would usually turn up a result very similar to Dvorak. Here are some of the better (by the previous scoring system) layouts it's gotten:

b l g d q j p y u c
r m t s h i a o e n
w v f ; z , . k ' x

g , . y x ' n f d u
i o a s v l r t h e
; q k p j c w m b z

w f  l m ; j p y ,  '
r  s n t d h i o a e
z x c g v u b k . q

That second one actually looks usable. But I knew my scoring system was skewed when my genetic algorithm thought that was way better than DDvorak, Arensito, Colemak, and Capewell.

In a way I am basing my scoring system off what results those 4 layouts get. First of all, my program should have to run for a very long time to get anything that beats these. Secondly, Arensito should do the best, just because I like that layout.

For ergonomic boards, I suggest that you adjust the weights for the top and particularly the bottom row to a somewhat better value to reflect the ease of hitting those keys. As a programmer, you might introduce a "board_type" type variable to trigger different weight sets.

For my own part though, I feel that stretching "along the grain" of the row stagger doesn't feel or work any worse than I'd imagine it would on a matrix board. The n-m stretch for instance (or the t-"old-c" which is my t-v stretch) feel as fine as I can imagine they would on such a board since my arms and wrists are aligned perfectly with the stretch. In fact, on a matrix board I'd be worried that the board would force me to use more parallel arms which would be uncomfortable I fear.

Oh: For the love of Eris, don't state empty resolution in your results! If your scores differ in the second decimal then you state them with three decimals (e.g., "score"=>7.219 for colemak)! To be more sophisticated, you could always try assessing the uncertainty in your scores (by running different syllabi, making what you deem minor changes to the weights/scoring and suchlike) - an exercise that could prove useful in other ways too. You're making us empirical scientists cry (well, at least I whimpered somewhat).  ;)

Well I modified some stats and got interesting results.

When I greatly increased the penalty for same finger, I got this:

c g i q a u r w p z
f t . e o , l d s h
y v j ' ; k x m b n

Its finger count is about one third that of Colemak.

When the price of each position is increased, here is the (predictable) result:

b y u . j z d c m f
r i e a h l o t n s
x q , v ; w g p k '

This next one was a bit surprising. When I increased the same hand penalty, here is the result:

x k m ; g h w a s p
d y f . , n t e i u
z v x j ' l r o b c

That doesn't look like it optimize hand alternation, and I don't see how I got that result.

Note how "inky" and "pinky" are okay, but "slinky" isn't quite. Similarly, "alkali" is horrible and "knee" too.

Sliding from one key to its' neighbor on the row below isn't bad; it's a tried and tested QWERTY trick for the ed digraph and seems to work well enough.

Jumping up a row isn't good. Jumping two rows up or down isn't good at all (up feels worst) - in my experience it's also bad even if there's one other keypress in between. Typing "ilk" is bad, but "like" isn't quite good either and "kiln" feels like a mess (worse than the similar "link" I think?); I think your tiredness parameter sets in there though.

Maybe a tired finger that gets pressed should gain more tiredness than a rested one?

I'd think that a tired finger that gets even more strain will cramp up more than a rested finger will. You're not really looking for tiredness, remember, but for speed? So if a tired finger has to do extra work I feel that it will do it extra slowly. But this is only based on my feelings about the thing, and nothing more.

URGENT UPDATE!!!!!! I have fixed a bug that was messing up the same hand count, and it is now easier to use and debug. Here's the new scoring system:

Up and out on 1 hand (QR, SP, EL, I; , XA, CT, ,N, .O and their reverse, Colemak positions): +5 (this goes against the hand's natural curve, making it difficult)

Changing rows on 1 hand: +(number of rows changed)^4. That means moving up or down 1 costs 1, and skipping over the home row costs 16.

Using the same finger twice: +25

Reversing direction on 1 hand: +4x, where x is the number of times in a row it's reversed direction

Assigned cost for each position:

15 11 10 12 20 20 11 10 11 15
3  1   0   0  10 10  0   0  1   3
21 18 17 16 24 16 12 16 16 20

Notice that the left side has slightly higher costs in some places than the right side. This is because of the asymmetry of the keyboard, and would be removed for testing for an ergonomic keyboard.

I got some strange results.

qwerty score: "score"=>13.16, "jumphomecount"=>2972.0, "rowskipcount"=>304, "handcount"=>595, "effort"=>29480, "chars"=>31040, "fingercount"=>1130
capewell score: "score"=>7.54, "jumphomecount"=>479.0625, "rowskipcount"=>1168, "handcount"=>660, "effort"=>15421, "chars"=>30247, "fingercount"=>348
arensito score: "score"=>7.45, "jumphomecount"=>711.0, "rowskipcount"=>727, "handcount"=>444, "effort"=>16059, "chars"=>31040, "fingercount"=>342
colemak score: "score"=>7.08, "jumphomecount"=>513.25, "rowskipcount"=>591, "handcount"=>390, "effort"=>15943, "chars"=>31040, "fingercount"=>305
nisa score: "score"=>7.08894, "jumphomecount"=>592.625, "rowskipcount"=>653, "handcount"=>692, "effort"=>15378, "chars"=>31040, "fingercount"=>219
ddvorak score: "score"=>6.74, "jumphomecount"=>388.25, "rowskipcount"=>322, "handcount"=>34, "effort"=>16036, "chars"=>31040, "fingercount"=>489
klausler score: "score"=>6.62, "jumphomecount"=>406.9375, "rowskipcount"=>601, "handcount"=>101, "effort"=>15993, "chars"=>31040, "fingercount"=>202

Jumphomecount is the number of times it jumps over the home row, where a single row jump counts as 1/16 of a jumphomecount.
Rowskipcount, despite the name, is when it moves up and out along 1 hand.
Handcount and fingercount are obvious.
Effort is the price of each position on the keyboard, divided by 11.3 because 11.3 is the average of all the positions, and I wanted to reduce the number so that it could be compared to the other values. For instance, "jumphomecount" is not the number of points that were added due to jumping home, it was the number of times it happened. I wanted effort to be similar.

Nisa is a layout that I designed this morning (with logic, not my genetic algorithm), and it's loosely based on Colemak. I got a few ideas from Colemak, such as the P G thing.* Its score on http://www.siteuri.ro/dvorak/ is 1.5% worse than Colemak, and using my criteria it is almost exactly tied with Colemak, about 0.01% worse. Here's what it looks like.

Q W U P G B L Y C ,
O R E T D H N I S A
Z X ' V J K M . F ;

It was designed with no restrictions in mind except try to keep shortcuts in place, but that was low priority. I still managed to keep all the shortcuts except C in place. It has very low same finger count, and is the lowest on effort, but pays the price by having too much row jumping and some potentially annoying same hand stuff, such as CASF (case, face, sack).

I was surprised to see that Peter Klausler's layout actually did the best, and DDvorak did second best.  They still did just as well when I cut down on the same hand.

*In a previous thread someone asked why P and G weren't switched even though G was more common. Shai mentioned some stuff like PT/TP is more common than GT/TG (which I found to be true, though neither are very common) and to type P you have to bend your index finger back a little. I was about to disagree when I looked at my statistics and saw that G was only 20% more common than P. That's practically nothing, so I went with P G instead of G P.

Well your fingers don't lie naturally straight. Your two middle fingers are longer. If you let your hands rest normally, your middle and ring fingers would rest on W,F,U, and Y. So typing the digraphs I mentioned above requires moving the index or pinky even farther forward, while the ring and middle fingers are already moved back, so your hands are playing Twister with the keyboard.

The HRNIA layout is born!  ;)

It's fascinating to see those similarities.