<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://ideas.4brad.com" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>Brad Ideas - Solving Selfish Merge, again - Comments</title>
 <link>http://ideas.4brad.com/solving-selfish-merge-again</link>
 <description>Comments for &quot;Solving Selfish Merge, again&quot;</description>
 <language>en</language>
<item>
 <title>Bad pastage. That last</title>
 <link>http://ideas.4brad.com/solving-selfish-merge-again#comment-6194</link>
 <description>&lt;p&gt;Bad pastage. That last paragraph should read:&lt;/p&gt;
&lt;p&gt;Again, I&#039;m well aware that cars are not trains, let alone computer-controlled train simulations (which are perfect at following the rules). But, this might help a robocar with merges :)&lt;/p&gt;
</description>
 <pubDate>Fri, 24 Oct 2008 13:03:55 -0700</pubDate>
 <dc:creator>Satya</dc:creator>
 <guid isPermaLink="false">comment 6194 at http://ideas.4brad.com</guid>
</item>
<item>
 <title>3-into-2 merge</title>
 <link>http://ideas.4brad.com/solving-selfish-merge-again#comment-6193</link>
 <description>&lt;p&gt;An interesting thing you might want to look at is the multi-player train games over at openttdcoop.org (Yes, I know you&#039;re talking about cars in a special situation here, but bear with me).&lt;/p&gt;
&lt;p&gt;Those guys usually build a loop of 2-or-more train tracks (lanes), with interchanges. That&#039;s the mainline, corresponding to a freeway. The &quot;on-ramps&quot; are quite elaborate. One method is what they call a shift main line (SML), where cars... er, trains... in lane 2 are moved into lane 3 (if it&#039;s empty enough), and cars in lane 1 are then (closer to the merge point) moved into lane 2. The on-ramp can then merge into lane 1.&lt;/p&gt;
&lt;p&gt;Here, this explains it better, with pictures: &lt;a href=&quot;http://www.openttdcoop.org/blog/2008/03/23/main-line-mergers/&quot; title=&quot;http://www.openttdcoop.org/blog/2008/03/23/main-line-mergers/&quot;&gt;http://www.openttdcoop.org/blog/2008/03/23/main-line-mergers/&lt;/a&gt; (number 3 is the SML). That example is complicated by the &quot;priority tracks&quot; (which are sensors for the signals) and the doubled bridges. Moreover, that example has the B line merging into the A line. Both lines are double-tracked.&lt;/p&gt;
&lt;p&gt;Here&#039;s a simpler example: &lt;a href=&quot;http://www.openttdcoop.org/wiki/Unbalancers&quot; title=&quot;http://www.openttdcoop.org/wiki/Unbalancers&quot;&gt;http://www.openttdcoop.org/wiki/Unbalancers&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Again, I&#039;m well aware that cars are not trains, let alone comphttp://www.openttdcoop.org/wiki/Unbalancersuter-controlled train simulations (which are perfect at following the rules). But, this might help a robocar with merges :)&lt;/p&gt;
</description>
 <pubDate>Fri, 24 Oct 2008 12:38:55 -0700</pubDate>
 <dc:creator>Satya</dc:creator>
 <guid isPermaLink="false">comment 6193 at http://ideas.4brad.com</guid>
</item>
<item>
 <title>Alas it may not</title>
 <link>http://ideas.4brad.com/solving-selfish-merge-again#comment-6160</link>
 <description>&lt;p&gt;My supposition, which needs more research, is that it doesn&amp;#8217;t validate anybody&amp;#8217;s driving style.   Right now using that empty lane is selfish and does make the situation worse, because of the poor behaviour it triggers at the merge point &amp;#8212; some people stopping to let you in, some refusing to let you in, some people trying to force their way in, making others stop, some people playing chicken, some people straddling lanes to stop you from cutting ahead of everybody &amp;#8212; and I suspect this poor behaviour causes the bottleneck which blocks everybody, and also slows down the &amp;#8220;uncollapse&amp;#8221; of the road back to flowing traffic.&lt;/p&gt;

&lt;p&gt;So nobody&amp;#8217;s behaviour is vindicated &amp;#8212; not the early mergers, not the selfish mergers.   The behaviour that is vindicated is two full lanes and a fair and even take-turns merge at the end, and nobody does that.&lt;/p&gt;
</description>
 <pubDate>Thu, 16 Oct 2008 18:18:57 -0700</pubDate>
 <dc:creator>brad</dc:creator>
 <guid isPermaLink="false">comment 6160 at http://ideas.4brad.com</guid>
</item>
<item>
 <title>I love how this essentially validates my driving style ;)</title>
 <link>http://ideas.4brad.com/solving-selfish-merge-again#comment-6159</link>
 <description>&lt;p&gt;I enjoyed this post - the thought of Anon@01:05 seems like a defensive-reflex reaction in anticipation of people taking out anger on h/er with regards to the so-called &quot;selfish&quot; merge.&lt;/p&gt;
&lt;p&gt;I like to think of this as an economics problem and solution - since it essentially is: you take the profit-maximizing outcome.&lt;/p&gt;
&lt;p&gt;People who claim what you&#039;re doing is unfair (i.e., the people Anon@01:05 addresses) are simply bad at economics, rather than driving (or, to belabour the idea even further - you need to be a good economist to be a good driver). ;)&lt;/p&gt;
</description>
 <pubDate>Thu, 16 Oct 2008 17:46:43 -0700</pubDate>
 <dc:creator>Krupo</dc:creator>
 <guid isPermaLink="false">comment 6159 at http://ideas.4brad.com</guid>
</item>
<item>
 <title>I think you have misread what I wrote</title>
 <link>http://ideas.4brad.com/solving-selfish-merge-again#comment-6157</link>
 <description>&lt;p&gt;Because I&amp;#8217;m saying approximately the same thing you&amp;#8217;re saying.  To reiterate:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;When traffic is not stop and go, the cooperative zipper over a long distance is best by a long shot&lt;/li&gt;
&lt;li&gt;When traffic is stop and go, using both lanes fully (ie. both are stop and go) and merging in turns at the merge point is best&lt;/li&gt;
&lt;li&gt;What is not best is having one lane be stop and go, and one lane be mosty empty, with people zooming up to the merge point in the mostly empty lane, and then having road rage battles at the merge point.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Unfortunately we mostly get the last choice in collapse conditions, when we want the middle one.  Selfish mergers do nothing, possibly even make it worse, until there are so many of them that they are half the traffic, and it is no longer selfish (ie. confers an advantage to the detriment of the others.)&lt;/p&gt;
</description>
 <pubDate>Thu, 16 Oct 2008 12:20:48 -0700</pubDate>
 <dc:creator>brad</dc:creator>
 <guid isPermaLink="false">comment 6157 at http://ideas.4brad.com</guid>
</item>
<item>
 <title>oh boy...</title>
 <link>http://ideas.4brad.com/solving-selfish-merge-again#comment-6155</link>
 <description>&lt;p&gt;There you go again.&lt;/p&gt;
&lt;p&gt;The obvious merge point is at the end of the lane (usually&lt;br /&gt;
the right-hand one) that is terminating.  The cues include&lt;br /&gt;
the end of the dotted line separating the two merging lanes,&lt;br /&gt;
the solid outside line curving to become the boundry of the&lt;br /&gt;
remaining lane, and, OH YEAH, THE END OF THE MERGING LANE!&lt;/p&gt;
&lt;p&gt;Sure, if traffic is light and one can safely do so, then&lt;br /&gt;
merge before the merge point.  But if traffic is heavy and&lt;br /&gt;
slow, then a zipper merge at the end of the merging lane&lt;br /&gt;
is the correct response, fully utilizing both lanes.&lt;/p&gt;
&lt;p&gt;The idea that merging early in this situation is somehow&lt;br /&gt;
&quot;good&quot;, that people who wait until the merge point are&lt;br /&gt;
&quot;selfish&quot;, and putting one over on others is bullshit,&lt;br /&gt;
pure and simple.  The people who merge at the merge point&lt;br /&gt;
are driving correctly, and people who merge earlier are&lt;br /&gt;
not more virtuous.&lt;/p&gt;
&lt;p&gt;Your tortured rationalization in an attempt to support your&lt;br /&gt;
misguided behavior is a clear indication that, in this case,&lt;br /&gt;
you are wrong.&lt;/p&gt;
</description>
 <pubDate>Thu, 16 Oct 2008 01:05:34 -0700</pubDate>
 <dc:creator>Anon Y. Mouse</dc:creator>
 <guid isPermaLink="false">comment 6155 at http://ideas.4brad.com</guid>
</item>
<item>
 <title>It&#039;s a different problem to some extent</title>
 <link>http://ideas.4brad.com/solving-selfish-merge-again#comment-6154</link>
 <description>&lt;p&gt;As we&amp;#8217;re usually talking about construction merges here.   Indeed, for permanent merges highways do tend to have collector lanes and express lanes for just that reason.&lt;/p&gt;

&lt;p&gt;Highway design tends to avoid having permanent lane reductions too many places.  A usual way to do this is to have one lane simply become an exit lane.  People seem to know that when a lane is &amp;#8220;must exit&amp;#8221; that they want out of it soon, and there is, rather than a merge point, a split point.  Of course they will still, in some circumstances, go all the way to that split point but to stop and wait there is super-selfish because it blocks exiting traffic and is much more dangerous.  People don&amp;#8217;t have the same instinct to let in (or block out) somebody who does it.&lt;/p&gt;

&lt;p&gt;It seems that it might also make sense for construction crews, when closing right lanes, to find a way to make them forced exit instead.  Except that it would just be cones enforcing that, which people would ignore, at risk to crews.&lt;/p&gt;
</description>
 <pubDate>Wed, 15 Oct 2008 11:26:30 -0700</pubDate>
 <dc:creator>brad</dc:creator>
 <guid isPermaLink="false">comment 6154 at http://ideas.4brad.com</guid>
</item>
<item>
 <title>What to do?</title>
 <link>http://ideas.4brad.com/solving-selfish-merge-again#comment-6153</link>
 <description>&lt;p&gt;No, there is no solution for drivers right now.&lt;/p&gt;

&lt;p&gt;If you use an empty merge lane, you will jump ahead of the queue, create road range and trigger lane straddlers.  You will cause consternation at the merge point as people try to not let you in on one hand, and in the event the continuing lane starts getting back up to speed, you will cause it to collapse again by trying to get in.&lt;/p&gt;

&lt;p&gt;The only answer seems to be educating drivers on the right behaviour, and using modern traffic sensors to tell them which of the two behaviours they should enter, including having metering lights that turn on after collapse to stop-and-go.&lt;/p&gt;
</description>
 <pubDate>Wed, 15 Oct 2008 11:22:12 -0700</pubDate>
 <dc:creator>brad</dc:creator>
 <guid isPermaLink="false">comment 6153 at http://ideas.4brad.com</guid>
</item>
<item>
 <title>Re: Solving Selfish Merge, again</title>
 <link>http://ideas.4brad.com/solving-selfish-merge-again#comment-6151</link>
 <description>&lt;p&gt;So when confronted with an empty merge lane, should *I* be selfish hoping that others will follow to fill the lane thereby increasing the total throughput?&lt;/p&gt;
&lt;p&gt;Or do I have it upside down and backward?&lt;/p&gt;
&lt;p&gt;Always ready to sacrifice,&lt;br /&gt;
Randy.&lt;/p&gt;
</description>
 <pubDate>Wed, 15 Oct 2008 09:40:10 -0700</pubDate>
 <dc:creator>Randy</dc:creator>
 <guid isPermaLink="false">comment 6151 at http://ideas.4brad.com</guid>
</item>
<item>
 <title>Local and Express Lanes</title>
 <link>http://ideas.4brad.com/solving-selfish-merge-again#comment-6149</link>
 <description>&lt;p&gt;Did the book discuss highways that have dedicated local and express lanes?  I have driven on roads where there are one or two lanes on the right dedicated to cars entering or exiting the highway, then four &quot;express&quot; lanes that carry them for the rest of the trip.  This is enforced by a physical barrier between the two roads.  The intent is to keep the stop and go of the merging traffic from affecting the traffic moving at speed in the left lanes.  The merging/local traffic has more of an opportunity to reach full speed before merging with the express traffic.  This could help solve the &quot;3 into 2 or 4 into 3&quot; problem you mentioned above.&lt;/p&gt;
</description>
 <pubDate>Wed, 15 Oct 2008 05:34:29 -0700</pubDate>
 <dc:creator>Anonymous</dc:creator>
 <guid isPermaLink="false">comment 6149 at http://ideas.4brad.com</guid>
</item>
<item>
 <title>Solving Selfish Merge, again</title>
 <link>http://ideas.4brad.com/solving-selfish-merge-again</link>
 <description>&lt;p&gt;I&amp;#8217;ve written a few times about the &amp;#8220;Selfish Merge&amp;#8221; problem.   Recently, reading the new book &lt;a href=&quot;http://www.amazon.com/gp/product/0307264785?ie=UTF8&amp;amp;tag=templetonscom-20&amp;amp;linkCode=as2&amp;amp;camp=1789&amp;amp;creative=9325&amp;amp;creativeASIN=0307264785&quot;&gt;Traffic: Why We Drive the Way We Do&lt;/a&gt;&lt;img src=&quot;http://www.assoc-amazon.com/e/ir?t=templetonscom-20&amp;amp;l=as2&amp;amp;o=1&amp;amp;a=0307264785&quot; width=&quot;1&quot; height=&quot;1&quot; border=&quot;0&quot; alt=&quot;&quot; style=&quot;border:none !important; margin:0px !important;&quot; /&gt; by Tom Vanderbilt, I came upon some new research that has changed and refined my thinking.&lt;/p&gt;

&lt;p&gt;The selfish merge problem occurs when two lanes reduce to one.  Typically, most people try to be &amp;#8220;good&amp;#8221; and merge early, and that leaves the right lane, which is ending, mostly vacant.   So some people zoom ahead of everybody in the right lane, and then merge at the very end.   This is selfish in the sense that butting into any line is selfish.  Even if overall traffic flow is not reduced (and even if it is increased) the person butting in moves everybody back one slot so they can get ahead by many slots.   This angers people and generates more counter-productive behaviour, including road rage, and attempts to straddle the lanes so that the selfish mergers can&amp;#8217;t move up to the merge point.&lt;/p&gt;

&lt;p&gt;In Traffic, Vanderbilt writes of surprising research that changed his mind, which showed that, in simulations, some merging forms provided up to 15% more traffic throughput than proper attempts at a zipper merge.   In particular, a non-selfish merge fully using the vanishing lane worked better than the selfish merge situation.&lt;/p&gt;

&lt;p&gt;In this merge, which I&amp;#8217;ll call the &amp;#8220;slow and fair merge,&amp;#8221; drivers are told to use both lanes up to the merge-point, and then to fairly &amp;#8220;take their turn&amp;#8221; at the merge point entering the continuing lane.   Nobody is selfish here, in that nobody butts ahead of anybody else, but both lanes are fully utilized up to the merge point.&lt;/p&gt;

&lt;p&gt;This problem is complex, I believe, because there is a switch-over point, which I call the &amp;#8220;collapse&amp;#8221; point.  This is the point at which the merge flow becomes high enough that traffic collapses to &amp;#8220;stop and go&amp;#8221; mode, before and at the merge-point.   Before that point, in lighter traffic, there is little doubt (for reasons you will see below) that the &amp;#8220;cooperating fast zipper&amp;#8221; merge results in the best traffic flow.  In particular, there are traffic volumes where you could either have cooperating zipper or &amp;#8220;slow and fair&amp;#8221; but cooperating zipper would do a fair bit better.     There are also traffic volumes where cooperating zipper just isn&amp;#8217;t possible any more, and we will either have &amp;#8220;slow and fair&amp;#8221; (which has the best volume) or &amp;#8220;selfish merge&amp;#8221; which has a worse volume.&lt;/p&gt;

&lt;p&gt;Real world experiments show different results from the theoretical.  In particular, many drivers, used to the anarchic selfish-merge approach, don&amp;#8217;t understand fair and slow, even when signs are explicit about it, and so they resist using both lanes and try to merge early.  They also try to straddle, devolving to selfish merge.  An experiment with digital signs which changed from advising drivers to zipper-merge in light traffic to advising &amp;#8220;use both lanes&amp;#8221; and &amp;#8220;merge here, take your turn&amp;#8221; in heavier traffic was disobeyed in fair and slow mode by too many drivers.  The experiment ended before people could learn the system.&lt;/p&gt;
</description>
 <comments>http://ideas.4brad.com/solving-selfish-merge-again#comments</comments>
 <category domain="http://ideas.4brad.com/archives/cat_transportation.html">Transportation</category>
 <pubDate>Tue, 14 Oct 2008 21:00:52 -0700</pubDate>
 <dc:creator>brad</dc:creator>
 <guid isPermaLink="false">827 at http://ideas.4brad.com</guid>
</item>
</channel>
</rss>
