Sunday, January 08, 2017
Sunday, November 27, 2016
Tuesday, November 01, 2016
Monday, October 17, 2016
On June 30th, 2016, the National Highway Traffic Safety Administration (NHTSB) opened an investigation on Tesla Motors due to a fatal crash involving a Tesla Model S. The issue is the car's Autopilot software was enabled and driving the car. The autonomous system missed a truck crossing the highway perpendicular to the Tesla's direction of travel. As a result, the Tesla's passed under the truck's trailer. Presumably, the parts of the trailer that went through the Tesla's windshield resulted in the driver's death.
Tesla's blog post on the incident states, in part:
These averages are so broad the comparisons are meaningless.
For example, Tesla quotes (without citation) that among all vehicles in the US, there is a fatality every 94 million miles. The "all vehicles" category presumably includes buses and farm equipment. Does comparing the fatality rates of mopeds and Tesla cars make sense? Furthermore, Tesla's Model S has a suggested retail price of $70,000 USD, which is hardly representative of average vehicles. What is the fatality rate for vehicles comparable to Tesla's Model S? Are the comparable vehicles similar enough to reach meaningful conclusions? What do different vehicle classes look like? How are the associated driver populations for each category best described? Are populations associated with higher fatality rates likely to adopt autonomous driving systems in the first place?
Recall the fatality per mile traveled averages include the effects of negligent drivers. Under this light, Tesla's own numbers are questionable at face value. Specifically, according to the CDC, 31% of the US driving related fatalities involve alcohol impairment. Thus, sober human drivers cause one fatality per 136 million miles traveled, instead of the 94 million miles quoted. The CDC data also indicates a further 16% crashes involve drugs other than alcohol, but the number of resulting fatalities could not be clarified for those collisions with available data.
Tesla's post compares fatality per mile averages. However, Tesla's total of 130 million miles traveled pales in comparison to the number of miles driven to arrive at the CDC averages. It looks like the sample sizes differ by several orders of magnitude. Is Tesla's sample size really enough to reach accurate conclusions? Tesla seems to think so, thus an assessment is fair game. The above numbers show the Autopilot software compares favorably to possibly driving under the influence of intoxicants. Moreover, Autopilot also compares as roughly equivalent to an average driver: likely speeding, perhaps reckless, in some cases impaired by drugs other than alcohol. Altogether, Autopilot is not a good driver.
As a side note, when Tesla invokes fatality per miles traveled averages, the implication is that Tesla's Autopilot is better than average and hence good. But most drivers incorrectly believe themselves better than average. It follows the average driver underestimates what it takes to be a good driver. Tesla's statement could be setting up average readers to deceive themselves by tacitly appealing to their illusory superiority.
But back to the story. What are the self-driving car performance expectations? This June 30th CNN article states, in part:
The year 2020 is basically just around the corner. Today, drivers feel compelled to forcibly take control from autonomous driving systems alarmingly often. This LA Times article from January 2016 states, in part:
Both the information and the questions required for good understanding are missing. Would you be comfortable being driven by someone who misses branches, or just fails to drive at all, as frequently as once a mile? Are the driving conditions for those driven miles reported by Google and others realistic? What proportion were driven in snow, ice, heavy rain, fog, or smoke? Did autonomous driving systems encounter geese, ducks, or deer on the road? How do those systems handle emergency situations?
Suppose you will never let beta software drive you around. What happens when you are affected by someone who does? Back to the CNN article,
Given this expert assessment, what does the lack of Tesla disengagements in California DMV's report mean? That Tesla's software is just better? That the average Tesla driver is less engaged? Does the Tesla crash suggest so-so software is duping drivers into not paying attention?
But even if the timely warning was possible, are driving autopilots a good idea in the first place? In aviation, autopilots do most of the flying and as a result human pilots' ability to fly by hand is compromised. Recovering flight emergency situations often requires manual flying, which is not the time to discover those skills are lacking. Specifically, the professional recommendation is:
In contrast, driving autopilots are promoted for heavy use, and especially for low-workload driving scenarios. The ideal situation often casts the driver as a self-absorbed mass transit passenger:
Note the irony of "progress" illustrated by reading a paper (!) book, comfortably sitting with all driving controls out of reach. And there is more than one irony in play: studying from paper rather than a tablet is associated with better comprehension and retention of the material. Paper also leads to better results than a Kindle. Why does this picture associate technological improvement with paper books?
Of course the flying environment is very different from the driving environment. Kids and pets don't run in front of the plane from behind a row of clouds. Plane collisions are infrequent due to spacious traffic control enforced with multiple radars. And if you listen to plane mishap recordings, you will notice bad situations develop over comparatively long periods of time. Limited flight autopilot failures can be tolerated because the entire flying environment is engineered to catch problems before they become unsurmountable.
In contrast, there is no car equivalent to the cockpit's emergency procedure binder. The driving experience still requires quick judicious action. Experience with flight autopilots show excessive dependency can result in compromised pilot skills. So why should the professional advice for planes, with all the implied liability and gravitas, be any different in nature for cars? And if unattentive drivers do not have the time to recover from an undesired state, why should drivers stop paying attention in the first place? Tesla's own advice agrees: "be prepared to take over at any time".
For clarity's sake, maybe Tesla's "Autopilot" is better described in terms of "Driver Assist".
For time's sake, maybe traffic and community planning is a better way to curb hours wasted while driving. As an example, shutting down container shipping terminals increases truck traffic. Trucks disproportionately wear roads because pavement damage is proportional to the fourth power of weight --- each truck axle carrying 18,000 pounds is equivalent to 10,000 cars. So, more truck traffic means more road work, which in turn causes even more congestion. Self-driving vehicles can be irrelevant to traffic.
For everyone's sake, maybe a characterization of the behaviors correlated with fatalities could lead to keeping drivers exhibiting those behaviors off the road. Ignition interlocks prevent drunk driving 70% of the time according to the CDC, but of course this is invasive for the sober majority. So instead, a reasonable non-invasive Driver Assist feature could detect unfit driving. Critically, this approach does not require developing a fully fledged autonomous driving system to be, in some respects, perhaps just as helpful.
Update: it looks like common sense is finally catching on --- the NTSB says fully autonomous cars probably won't happen, many proponents of the technology are running into trouble and/or scaling back expectations, and Tesla just disabled its Autopilot system.
Posted by Andrés at 11:27
Sunday, October 16, 2016
You can see the statement of an interesting problem I heard recently here. Basically, it has two parts: a simpler stage, and a more complex setup.
The simpler stage is as follows. Players A and B both take a card from a standard 52-card French deck and put it face up on their foreheads. A can only see B's card, and vice versa. Their task is to guess the color of their own card. They cannot communicate with each other, and must write down their guesses at the same time. If at least one of them guesses correctly, they both win. Is there a strategy that always wins?
The more complex setup has four players, and now they must guess the card's suit. If at least one of them guesses correctly, they all win. Is there a strategy that always wins in this case?
So you are still there? Did you really make an honest attempt at the problem?
Ok, so you want to read on. Fine :).
First, the simpler stage. Clearly, treating both players as identical doesn't go anywhere. But if one considers that A's identity is different than B's, one can also assume they behave differently in response to each other's card. That is, the card they see is a selector for some behavior. Moreover, both players may have different responses to the same messages.
This looks a lot like ECC with XOR or parity, and RAID disk arrays. A and B could be stand-ins for error recovery mechanisms that try to reconstruct missing data. If at least one guesses correctly, together they recover the unknown card. This metaphor is not precise enough, but it suggests the following strategy.
For example, let's say A guesses A's card is always the same color as B's card (which A can see). Now if B behaves the same that's not good enough --- so let's have B always guess a color different than that of A's card (which B can see). Let's say color black is 0, and color red is 1. Moreover, let CX stand for player X's card color. With this convention, the approach boils down to:
- A plays 0 xor CB
- B plays CA xor 1
If that's what's going on for two colors and two players, what could be a reasonable guess for 4 suits and 4 players? Well, let the suits be represented by 0, 1, 2 and 3, and further let CX now stand for player X's card suit. Then,
- A plays 0 xor CB xor CC xor CD
- B plays CA xor 1 xor CC xor CD
- C plays CA xor CB xor 2 xor CD
- D plays CA xor CB xor CC xor 3
Posted by Andrés at 17:42
Monday, September 05, 2016
This year, we are extremely happy to announce Ralph Johnson and Gilad Bracha will attend our conference.
1. Registration: Registration is free and now open at
Please make sure to register early to receive the conference's shirt, as well as to help us plan the conference's social events. We are accepting donations from participants to help fund the conference's costs. Please see the Donate section at FAST's website,
Contributions are greatly appreciated, and can be received both in pesos for local attendees, as well as via Paypal for those coming from abroad. Please note that donors, including those that have already sent us their contribution (thank you!), will receive a set of thank you gifts as well as the conference's shirt. For those of you that need a receipt, we can provide those on site.
2. Call for Participation.
Talk proposal submission for the Industry Track is now open at our website:
If you need special arrangements (e.g. because you would like to hold a workshop session), please indicate so in the abstract. The Industry Track's submission deadline is October 20th, 2016.
3. Related events: We will update related event information as we get closer to the conference, so please check for updates.
For any additional questions please write an email to firstname.lastname@example.org
See you in Tucumán!
Posted by Andrés at 00:54
Tuesday, August 09, 2016
Hi! Your Camp Smalltalk crew has been at it for a while, and we are very happy to announce a Camp Smalltalk at Marquette, Michigan, on September 15-18th. We are generously hosted by Northern Michigan University, where John Sarkela teaches Smalltalk courses. Of course, NMU is also home to the Modtalk project. You can help us provide a better experience for everyone by registering here. Don't miss the date!
Posted by Andrés at 13:30
Saturday, July 16, 2016
Sunday, June 26, 2016
Many of today's issues with software ultimately cause unreliable service. Software's popularity does not seem greatly influenced by reliability, so the audience seems to tolerate the situation. However, when unreliability becomes the norm, the resulting ecosystem is one in which nothing works as advertised. You have effectively no recourse other than to roll out your own, become a system administrator, or put up with it.
This kind of environment directly limits what you can accomplish in life. Take for instance email. Although delivery was never guaranteed, at least you had some chance to track down problems and there seemed to be a general willingness to ensure correct transmission. Today, emails simply vanish with no explanation, and you're not supposed to know what has happened. After some debugging, the best working hypothesis for the latest occurrence is as follows:
That aggressive spam filtering is a necessary evil, the usual excuse, doesn't cut it in this case. Someone replies to you, and the text says "at some point, email@example.com wrote:". Or someone comments on a forwarded email of yours that reads "From: firstname.lastname@example.org". These ubiquitous, well established email body patterns are being dropped without notice.
The side effects of unreliable software are allowed to spread unchecked in part because, in an unknowable and incomprehensible software world, naturally there is no responsibility and thus no recourse. Hence, the above diagnosis is merely a best working hypothesis. Occam's razor suggests the email problem is Comcast's fault. But how do you find where the problem actually is without access, much less appropriate support?
I don't think this will get any better as long as software and derived services can be sold without any form of accountability whatsoever. Consequently, until then, protecting yourself from unreliability is up to you. In the case of email, that means implementing and/or managing your own email server. But where does that road end? Email is hardly a top reliability concern. The go-it-alone approach does not scale.
Posted by Andrés at 20:17
Tuesday, October 20, 2015
Smalltalks 2015 is around the corner. We're very pleased with this year's keynote presenters: John Brant, Damien Cassou, and Clément Béra. Such quality speakers are possible thanks to our sponsors, community donors, and collaborators. We really appreciate your support, thank you!
... I can't wait for the conference to start :).
Posted by Andrés at 02:47