Chris X Edwards

Recently I drove to Cleveland to watch my brother compete in the Age Group National Championships.

The temperature on Lake Erie was quite nice, but there was much hot air generated by me, a has-been mediocre triathlete, about how it all should be done. Since this is, strangely, the second time in a week I’ve been reviewing my little opinions about triathlon strategy with someone, I thought I’d go ahead and write too much of it down so that I can try to be useful while minimizing future prattle about my trivial racing career.

My first tip is some perspective. My brother finished roughly in the middle of the pack yesterday for his age group, but that’s not really the way to think about it. If you take all the men in the USA who are older than 29 and younger than 35 and line them up at the starting beach head to foot in order of how good they are at this sport, my brother would still be able to fit in the swim/bike transition lane. This line of guys, however would stretch from Cleveland to Perth, Australia. What’s important here is that even if you come in "last", cliche as it may seem, you are a winner — you deserve that medal they gave you!

With that in mind, if you decide to join the elite humans who even try this crazy stuff at all, here are some of the motes of wisdom I collected during my racing career which can make it go a little smoother.

Let’s go in order and start with the swim.

Swim

Unfortunately, the best way to approach the swim is to start being coached as a child and go to swim meets non-stop as a teenager. If, like me, you failed to do that, you will have an endless parade of very attractive college girls swim over top of your back during the swim. Could be worse. Actually it is worse, but I try to focus on the positive. It’s worse because a triathlon swim is like a hockey fight among water polo players. What can be done?

Transition1

Bike

Triathletes are not supposed to specialize but they do and my specialty is the bike. One of the nice things about triathlon is that it is a perfect venue for people who suck at your specialty to compete with you (you just have to submit to their specialty). I could write several books about cycling (and if you like that kind of thing, I endorse this book). But basically competitive cycling comes down to four components. Let’s look at these in reverse order.

To summarize my triathlon cycling advice.

Transition 2

Run

I’m an ok runner. I was blessed with a good physiological running style which is naturally smooth and fast. Still there are things you can and should do to improve. I put a lot of thought into my stride and kinematics. For example, I may have a naturally good fast style but if the race is a marathon, that may not work in my favor. You must analyze your style for wasted energy and motion. Are you slamming the pavement? Are your shoes wearing in a funny way? Are you waving your arms pointlessly? There are many things that can lead to a wasteful stride. All I can say is that I spent many of the long hours training thinking about the details of my running mechanics. It’s worth doing.

Let’s assume you have given your stride sufficient thought or professional coaching — what else can be done? I’ve got a few other less subtle tips for triathlon running.

I’m sure I have a lot more to say on the topic of triathlons but that’s most of the important stuff. One last piece of advice is the most important of all. Smile. There are a lot of good reasons for this. First of all, if you’re a normal grimacing competitor, that just tightens up muscles that really should be relaxed. But from an attitude management standpoint, by forcing yourself to smile and training enough so that it’s not even that hard to, you’re preparing your mind to be unstressed by how things are going to go. You’ll handle adversity much better. You’ll manage your energy better. You’ll be happier. Smiling helps you to have a good race no matter what happens.

One of my eccentric beliefs is that the state of the art of computing is the state of the art of gaming and not the other way around. My Linux loyalty has greatly limited my gaming agenda but it has given me an interesting perspective. When it comes to serious computing, I can’t help but notice that gamers lead the way. Consequently I like to keep informed about what the major trends are there.

Glance over this search I did for "best cpu motherboard". The word "gaming" in some form appears in 8 of the 10 first hits (it features prominently on the links of the other 2).

Are non-gaming people not interested in the "best cpu motherboard"? I’m going to say that as far as market forces go, no. Your CAD draftsman or molecular modeler or video editor or spreadsheet farmer doesn’t need the "best" today. Anything will do for them. But the gamers are always looking to push the frontiers.

A source of some interesting data is the Steam Hardware Survey. This is where Valve’s venerable gaming platform harvests a lot of data about exactly who is doing what with what.

Of course the most interesting thing about the Steam Hardware Survey to me is not necessarily the hardware. Before looking at that, let’s first look at what platforms the games are supporting these days.

Games appearing in search results constrained by OS.

Obviously these aren’t mutually exclusive. Let’s just say that everything runs on Windows. To be precise, only 23 of 48056 go missing when you limit search to just Windows. Still 24% of games available to Linux is pretty extraordinary given the situation as little as five years ago.

With the knowledge that about a quarter of the games are available to alternative platforms, what does the actual usage look like. We can check with the hardware survey and see who’s running what. Here is a very depressing plot of the OS ecosystem in gaming.

Talk about hanging on by a thread! At least Linux grew .02% since the start of 2017.

This is a bit surprising to me since Linux has enjoyed the aforementioned huge surge of compatible games in recent years. With impressive Wine support a lot of games are running better on Linux than their original target. But still, if you’re simply a path-of-least-resistance player, passing up on a non-negligible number of games you’d like to play may not be realistic. I’m going to take these Linux numbers to represent vive-la-resistance players!

What’s also strange is that with Android, tablets, and cloud office suites, it seems like Windows is teetering on the edge of insignificance. Here’s a good article about how Windows is being internally dismantled at Microsoft. But apparently gamers didn’t get the message. I wouldn’t be shocked to see Office move to an online platform and Windows get branded as a game platform like Xbox. Clearly Valve has their work cut out to fight Microsoft’s monopoly and Linux is a key weapon in that fight. Here’s a recent article on the whole showdown.

I was kind of surprised to learn that 0.22% of Steam users were using 32 bit Windows XP. Ouch. Reminds me of some ancient computers which are forever stuck to some equipment in science labs I know.

Among the 3% of people using Macs for games, it seems like they mostly keep them up to date.

I think I found the language preferences most interesting. English dominates Linux users a bit more than it does in general. Here’s an interesting look at the language settings. When all OS choices are looked at, Chinese is dominant. But when you focus only on Linux users, the trends shift quite a bit to Russians and Europeans.

Note that these don’t add up to 100% because it is missing the majority of people who use English language settings. Note also that a lot of Russians (I can personally assure you) and Chinese and everyone else often use English despite that being a foreign language for them.

That was interesting to me with respect to Linux. But there’s much more of interest to the whole computer using world. Let’s look at the hardware.

Monitors are pretty standardized now. 60.49% have a 1920x1080 monitor. And 34.87% have two such regular monitors for a grand total of 3840x1080. I have two regular monitors set up for serious work for a grand total of 2160x1920 which really bakes Steam’s noodle.

I’m a little shocked that 60.51% have 4 CPUs but in the many years this has been standard only 4.15% have 6 CPUs and only .99% have 8. That leaves 31.40% of people using 2 CPUs like my laptop had in 2006. The conclusion would seem to be that a lack of more processing cores is not generally a serious performance bottleneck in gaming.

RAM seems to not have become much more plentiful either. There are roughly three equal groups: less than 8GB, exactly 8GB, and more than that. At 38.97% the setups with 8GB are most prevalent. But 36.67% have more than 12GB. The survey format doesn’t even explore silly levels of RAM that people like to have for VMs and video editing. But again, I think we must conclude that after 8GB, going crazy on the RAM has diminishing returns on gaming enjoyment.

Graphics cards are a rout — 15 of 16 most popular graphics cards are Nvidia GeForce. Here’s a rough breakdown of popular video cards. Don’t get too upset if I’m a couple percent off — I think the survey was too. The interesting thing to note here is that half of gamers have pretty decent cards. My guess is that the other half are making do with laptops and tablets and such.

Last year I wrote about how prices are stablizing in the computer world. Usually that’s a good thing but since computers have been getting delightfully better and cheaper historically, this feels like the end of the party.

I’m really curious how this will all turn out. Clearly Intel has some serious challenges. Here’s a nice article discussing Intel’s many strategic problems. Clearly they’ve lost to Nvidia on what matters to the serious people, the gamers. And from that gaming enthusiasm came GPUs that are now the default way technical people do advanced technical things. Intel may want to catch up but I’m not sure that will be easy.

The only prediction I will make is that gamers will continue to greatly influence what technology gets seriously developed — more than the other way around.

Homo Deus: A Brief History Of Tomorrow is the follow up book to Yuval Noah Harari’s Sapiens (which I reviewed here). It is hard to know what to say about this book. The first blurb on the back is from the freakishly insightful Daniel Kahneman and it immediately singles out this book’s core value.

Just so you don’t think I’m being lazy here, I had a look at today’s NYT hardcover nonfiction best sellers list and for each of the top 15 books, I calculated the percentage of Amazon reviews that contained the phrase "thought-provoking". Have a look.

Total for NYT NF Top15: 83/6135 = 1.4%

That exercise itself was a bit thought-provoking. Check out how Harari’s book crushes this silly metric.

Homo Deus - Yuval Noah Harari - 128/1146 = 11.2%

Let’s look at a very typical example but one that I took a special interest in. Here he’s vaguely pondering the nature of consciousness (a topic I am especially interested in) without getting too precise about what he means by that word.

The photo on this page (p.115) is of Waymo’s Firefly/Koala (did it even have a proper name?). I’m pretty sure this particular specimen had absolutely no ambitions to talk to other cars. Brad Templeton who advised Waymo for this project has this to say about that issue.

I point that out because this is one of the areas I know pretty well, and it could be that Harari is doing quite a bit of such hand waving.

The first part of the book makes a surprisingly animated attack on the idea of eating meat. I eat very little meat but I also have other topics higher on the list of philosophical issues to worry about. Still, if you’re a vegetarian, you’ll like the first part of the book.

Harari spends a decent amount of time letting you know that your mind is composed of different cognitive actors. Most people who know me have been exposed to that idea before. I do like his clever term "dividual" to describe our collection of cognitive contributors.

He talks here and there about science fiction topics. The title refers to what humans may "evolve" into — what will be beyond us (Homo sapiens) on the evolutionary tree.

But when I read that, I wondered, why so complicated? Some people can already "upgrade" themselves with an ancient medical procedure that will almost always strongly reorient a person’s priorities — castration. But Harari doesn’t talk much about why men aren’t improving their lives with that technology upgrade, so I’m not quite sold on the inevitability of fancier computerized versions.

Don’t get me wrong. I would recommend the book. It is interesting even if slightly questionable here and there. It’s decently well-written and engaging. Whatever flaws this book had, it was definitely a rare champion of "thought-provoking".

A couple of years ago I was visiting my dad and I was introduced to this toaster.

This is a fancy and somewhat expensive toaster. Just look at that fancy digital display! I don’t know about you but for me and many others toast is a breakfast thing. Sometimes I get up and make toast while other people are still sleeping. Imagine my surprise when this toaster announced the readiness of my finished toast with a shriek like a chimpanzee being disolved in acid. It scared the hell out of me! I wondered, what moron designed a breakfast food preparation appliance to literally sound like an imminent train wreck?

This would not do. Annoyingly the toaster was assembled with special security screws. That just made me even more committed. First I had to make a tool to disassemble the thing.

Having accomplished that I was able to open it up.

And here’s the obnoxious source of all the fuss.

This spec sheet shows a very similar 1205 buzzer producing 85dBA. This means that it is similar to a dump truck driving by. I was able to disable the buzzer, reassemble, and finally make toast in blessed silence.

That was a toaster problem.

It was not the toaster problem.

The toaster problem is a shorthand phrase I use when discussing autonomous vehicle technology or any futuristic technology that is heavily dependent on artificial intelligence that hasn’t quite been invented or perfected. The toaster problem is that toasters can not reliably toast a piece of bread. All toasters I know about may be able to be set up to make one piece of toast satisfactorily, but if you scale that to 9 pieces of toast, maybe on a cold morning or a hot day, well, if you want your toast perfect, you, a human, will have to keep an eye on it. No big deal usually, but the important point is this: if we can’t have autonomous toast toasting machines, how the hell are we going to have automatic machines that can perform double lane highway merges?

I focus on toasters because the technology is so banal and stupid. Not only that, but I personally can envision a solution. I believe that I could set up a camera to watch the progress of my bread toasting and with enough iterations, I could train a machine learning algorithm to produce a "toastedness" score which would actually be related to the toast you were wanting regardless of how hot the coils were at the start of the process. I’m a wee bit surprised that KitchenAid doesn’t have such a thing for $1000.

But why is this a useful phrase? It’s important because there are tons of things that are unsolved toaster problems. For example, trains have drivers. I happen to know that some trains do not and this industry is working hard on their toaster problems, but still — if 2d cars are to drive themselves, shouldn’t we be seeing 1d trains do it first?

Another example being worked on are floor cleaning machines that can operate with or without a driver. This is actually the first (2d) autonomous vehicle I ever got to ride.

A couple weeks ago I spent twenty minutes being actively driven around O’Hare airport on the ground in a fancy fleet-managed airplane. I would guess that taxiing in such a controlled environment is a toaster problem even if full gate to gate autonomous flying turns out more complex. Certainly ground support vehicles in tightly controlled airports could be easier than general passenger car transportation. Oxbotica is working on that toaster problem now.

Sometimes it can be tricky to place a technology concept on the toaster spectrum. Is an automated battleship easier than a unoccupied robocar that safely doesn’t kill cyclists? That probably depends on many complicated factors but that idea is currently more than science fiction. How about a car that can race off-road through the Mojave desert? It’s not obvious.

Certainly partial technological progress on the way to fully autonomous passenger cars implies many useful intermediate technologies. Is a car that can park itself essential before a car that can do everything that I can do as a driver? I’d say so. All the modern ADAS features are toaster problems solved.

I think one of the biggest mistakes made by a lot of autonomous car teams is to neglect the toaster problems. For example, Kitty Hawk is aiming for flying autonomous cars. I suppose if you’re ok eating burned toast, you might as well dream big.

UPDATE 2018-07-04

Car alarms. That’s way way lower than toast. And, a very similar stupid problem, the obnoxious klaxons of garbage trucks and backhoes in reverse. There will be no meaningful autonomous cars while these things exist.

UPDATE 2018-07-12

The Economist covers some projects that may literally be working on the toaster problem as part of a grander robotic chef.

Also there can be toaster problems in other areas too. For example, the fact that I can’t live under the surface of the ocean or in central Greenland is a toaster problem for people wanting to colonize Mars.

I have been interested in Probabilistic Robotics by Sebastian Thrun, Wolfram Burgard, and Dieter Fox since I first heard about it while learning about the rocket science of Kalman filters from Professor Thrun himself in last year’s grand educational experience with Udacity (a company started by, yes, Sebastian Thrun). I was finally able to put my employer’s library to use and borrow this massive and expensive book. I found the topic to be interesting and important enough that I wanted the hardcore experience and this is definitely it!

A good summary of the book’s mission is on page 488:

And we learn, not only is it sensors that are not telling the truth—it turns out that actuators don’t actually do exactly what you tell them either. Oh and the maps you have or make are never quite right. These are the problems that this book tries to come to grips with.

Another way to think of it is that the existence of this book explains why a Roomba navigates the way it does (randomly). Or put another way, "stupid" easy navigation may be just as smart as fiendishly difficult hard navigation if you can get away with it. This book is not looking for the easy solution!

A big topic was SLAM which stands for Simultaneous Localization And Mapping (note Professor Thrun’s DARPA Challenge car, Stanley, in the SLAM Wikipedia page). This is where the robot is dropped into a place and has to figure out what’s there and how to reliably not hit it, even when all sensors are a bit wonky. This is fine, but I think there is more to this topic than the book even thought about (despite covering EKF SLAM, GraphSLAM, SEIF SLAM, multi-agent SLAM, etc). SLAM in rooms or controlled indoor environments which the book spent a lot of time on may be necessary for SWAT teams and turning off a serious nuclear reactor malfunction, but for everybody else (and the nuclear plant actually), just mount cameras on the walls! This may not be a terribly hard problem unless you really want it to be! But hey, what do I know?

If I had to provide a one word answer to all of the problems this book worries about, I would say: Bayes. Apparently using Bayes Theorem early and often can really provide a lot of help with these tricky problems. How exactly that is done can be tricky.

Page 233 quotes (Cox 1991) by saying, "Localization has been dubbed the most fundamental problem to providing a mobile robot with autonomous capabilities." It is definitely hard, but if they still believe that after doing some work on the autonomous car problem among idiot human drivers, then I think they need to take another look at things.

Every chapter concluded with (some freakishly microscopic print in) a section called "Bibliographical Remarks". I found this interesting because they did a decent job of summarizing the history of this weird little corner of robotics math nerdery. However, many times the saga would build up until the final word on the topic was Thrun et al. Which is fine but I sometimes wondered if I was reading a Thrun biography. On page 144, we are reminded that, "Entire books have been dedicated to filter design using inertial sensors." So it could be even more painfully specialized I suppose than Sebastian’s greatest hits which are genuinely impressive.

I was quite frustrated to read this on page 329, "Little is currently known about the optimal density of landmarks, and researchers often use intuition when selecting specific landmarks." It goes on to say, "When selecting appropriate landmarks, it is essential to maximize the perceptual distinctiveness of landmarks." I’m a big proponent of making these gruesome algorithmic/computation problems as easy as possible. Yet never is the topic of how to eliminate the uncertainty with environmental augmentation mentioned. It would be like fretting over how hard it was to train people to memorize all street names and features because putting up street and road signs would be expensive. But, hey, my little thoughts on how horrifically hard problems might be simply averted with a dirty trick are probably not appreciated by people whose job it is to solve hard problems.

There were some interesting fun bits of knowledge that I had never heard of. For example, the fact that terramechanics is a thing is interesting to me. And I learned that the Aurora CEO Chris Urmson once worked on an autonomous robot to search for meteors in Antarctica which is very cool (in many ways). That reminds me of my concept for autonomous archaeology robots which also would use a lot of the ideas from this book to make very accurate maps of where items were found.

I don’t think that this book was remarkable for a graduate level textbook, but wow, what a crappy way to teach something! The first thing to complain about is that pseudocode equals pseudoquality. As it says on page 596 "This algorithm leaves a number of important implementation questions open, hence it shall only serve as a schematic illustration." The "algorithms" were to me useless. Implementing them from the opaque pseudocode scribbled with frantic Unicode hand waving seemed no easier than thinking of a decent algorithm myself directly in code. It’s like betting someone that you climbed Mt. Everest but instead of just showing them a picture of you on the summit, you say that they’ll need to climb the mountain too to see if there really is proof of the deed up there. Just write real code! This isn’t probabilistic abstract thinking! Everyone who looks at this book will want this technology on a machine that runs software. Showing some real code could highlight good practices throughout, easily demonstrate algorithm effectiveness, and easily prove they even work at all.

I was really not delighted with the gruesome math and just unnecessarily harsh, but no doubt typical, syntax throughout. It certainly was great practice for slogging through such muck. I definitely feel more prepared to read obfuscatory stuff like this in the future. It was so baroque that it was hard for everyone to keep it straight. In Table 16.3-7, for example, there is Q(u) = 0 but then in the text on the next page it talks about it as "all Q_u's." Yuck. I did not spot a rho, nu, iota, zeta, or upsilon — though I could have overlooked them during my quick census. All other Greek letters made an appearance, at least half in both forms! Did I mention that just writing software, a language that all roboticists must speak, would be much better?

Sometimes even the algorithm outline was not especially encouraging. On page 366, for example, "A good implementation of GraphSLAM will be more refined than our basic implementation discussed here." Gee thanks!

I feel like with the intense level of math, theory, and algorithms that mentioning real world robots at all may be premature. I got the feeling that all of this math would be more intelligently applied to abstract computer models only and talking about real applications just muddles things. I even was reminded of automata curiosities and that is finally explicitly mentioned (referring to Rivest and Schapire 1987a,b) in the final paragraph of the book’s text!

I sure wish I had this book’s TeX source because I would love to search and count the occurrences of these words: "straightforward", "obvious", "of course", "simply", "easily", "clearly", "standard simplification", etc. I would bet $50 that some condescending word like that appears more than 600 times, or on average at least once per page. I’ll leave that as "an exercise for the reader". Ahem. Provide some source code proof that this stuff works and then I’ll start feeling like I’m the dumb one for not having implemented it!

I’ll make a list of errors I found to give you a sense of the production quality in general.

Really, that’s pretty good for such a massive tome (in English by German dudes, also Hut ab).

I’m glad I read this. It was definitely an experience and I feel more like grad students who have been hazed in this way, but if you really want to learn this stuff for practical applications, I’d just pay Sebastian for Term 2 of the Advanced SDCarND program and save yourself a lot of trouble. And get some working code instead of just a mental workout!