MTGandP

Can you elaborate on why -O3 often generates slower code? I've never heard that before.

It's nice to see some big names focusing on anti-aging research. It seems obvious that anti-aging research is a good idea, but surprisingly few people are actually pursuing it.

This video (http://www.youtube.com/watch?v=Pm-5s__aZE0) has an interesting debate about whether immortality would be a good thing. I'm still uncertain about this; but I think it's fairly straightforward that our healthspans have not yet reached optimal length. Heck, we currently spend the first 20-30% of our lives just getting the ball rolling.

"The Dennis Ritchie of this generation was just born."

Then I'll make sure my test subjects continue to practice QWERTY.

Thanks, that could be valuable. Is the data separated by keyboard layout?

You can use a new keyboard layout and still remember QWERTY. It's just like learning a second language (only it takes a lot less time).

You can use [my keyboard layout optimizer](https://github.com/MTGandP/Typing) to create your own optimized keyboard. I provide a corpus of programming text you can use, and you can change the weightings to increase the significance of the programming text. (I don't remember if I wrote documentation explaining how to do this; if you want to do this but can't figure out how, remind me and I'll write up some documentation.)

The [Kinesis](http://www.kinesis-ergo.com/) Advantage is a cheaper alternative to Maltron that follows the same design pattern. It's the keyboard I use, and it's definitely more comfortable than a typical staggered keyboard, or even a simpler ergonomic keyboard.

Author of The Keyboard Layout Project here. I'm familiar with Workman; it's a reasonably strong attempt, but I think it has a number of problems and fails to perform as well as Colemak or my own layouts.

If you compare Workman and MTGAP 3.14 (shown [here](http://mathematicalmulticore.wordpress.com/the-keyboard-layo...) using [my keyboard evaluator](https://github.com/MTGandP/Typing), MTGAP 3.14 performs better on every single statistic except finger work. (You can see all of the different statistics explained on [my GitHub page](https://github.com/MTGandP/Typing/blob/master/Fitness). I didn't post them all here because it takes up too much space, but if you want, you can pull the program and to the comparison yourself.)

IIRC, Dvorak has about 500,000 users worldwide.

I'm not trying to design yet another standard. I recommend that people use [Colemak](http://colemak.com/)—even though it's not as popular as Dvorak right now, it's easier to learn, so I think it has a better chance of overtaking QWERTY in the long run.

I design keyboard layouts because it's fun. I want to discover what it means for a layout to be the best. It's more of a scientific curiosity than a desire to make things better—although I do think QWERTY is in need of replacement.

> qwerty might be 1 to 5% less optimal than something else - let's even say 10%.

It's definitely a lot worse than that. If you're just talking about finger travel distance, for example, most modern keyboards (Colemak, [Arensito](http://www.pvv.org/~hakonhal/main.cgi/keyboard), my keyboard) do about three times better.

That's why my keyboard layouts try to optimize for rolls more than any other layout I've seen. The most recent version has a number of very nice rolls, TH, IN, ST, and some other less-frequent digraphs.

Hi, writer of The Keyboard Layout Project here. I'm well aware of the limitations of scoring a layout based on crude heuristics, and I'm trying to collect some good data. Right now I have some data from a few layouts that I've collected using [Amphetype](http://code.google.com/p/amphetype/), which records speed and accuracy for characters, trigraphs, and words. I'm curious, what program did you use to collect typing data?

If you or anyone else has typing data or is willing to collect some, please post a comment on my blog (preferably [here](http://mtgap.wordpress.com/2010/01/16/wanted-typing-data/)) and I will email you.

Ideally, we would have typing data not just from QWERTY and carefully-designed layouts, but randomized layouts. All the layouts people use (except QWERTY) share design patterns—putting the most common keys on the home row, etc. We can get more accurate data if we know how people type on random layouts.

I plan on using a little grant money from my school to pay some people to learn randomized keyboard layouts and then record typing data. If anyone's willing to do this for free, I'd love to have your help; again, you can contact me by leaving a comment on my [blog](https://mathematicalmulticore.wordpress.com/).

Data collection with a web app is also a good idea. I don't plan on writing such a thing any time soon, but if anyone does plan to, I think it would be very useful.

The entire purpose of the modern economy is to pay other people to do things so you don't have to do them yourself. Did you build your house from trees that you chopped down yourself? Do you grow all your own food? Do you cut your own hair?

If you think it's worthwhile to do your own grocery shopping, then you may do so. But there's nothing wrong with paying someone else for a service.

Maybe it's obvious, but I think the observation resembles an NP-complete problem: it's easy to verify that it is true, but finding it is difficult.

You shouldn't even have text at all on the bottom half of the slide. Text on a slideshow presentation should be minimal. The audience should be listening to you, not reading your slides.

A lot of your commit messages don't make any sense. Is there any point at which the program was fully functional but non-obfuscated?

It took me until I read the comments on this thread.

The program outputs your site-specific password to stdout. Is it possible for an attacker to get your stdout history?

> It's my life's dream to do a real-life process vs. algorithm design comparison like this one.

I've done some simple analysis of card sorting. I've timed myself vs. other people sorting cards, where I use bucket sort and they use whatever they want. I usually beat them by about 20%, but that may just be because I've practiced more. I think bucket sort would have a clear advantage over naïve sorting if the deck had about 100 cards or more.

I've also tested bucket sort against merge sort, and they're about the same speed.

For my bucket sort algorithm, I use two iterations. First I sort the cards into three buckets, where the first contains cards 2 thru 5, the second contains 6 thru 10, and the third contains face cards. Then I do insertion sort on the buckets. On mergesort, I switch to insertion sort for sufficiently short lists.

This was a fascinating article. I do have a small correction: bucket sort is more similar to quicksort than merge sort.

merge sort bucket sort

1. divide (in half) 1. divide (in bins)

2. sort halves 2. sort bins

3. merge 3. done!

(Edit: Sorry, the formatting isn't great. I don't know how to do fixed-width text.)

The big difference here is that for merge sort, dividing the lists is trivial because all you have to do is split it into the first have and the second half. But for bucket sort, you have to actually look at each element to decide which bin it should go in. This is more like quicksort's partition step.