<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Long division</title>
	<atom:link href="http://bit-player.org/2009/long-division/feed" rel="self" type="application/rss+xml" />
	<link>http://bit-player.org/2009/long-division</link>
	<description>An amateur's outlook on computation and mathematics.</description>
	<pubDate>Thu, 17 May 2012 09:54:22 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Out of the cesspool and into the sewer: A/B testing trap : Credit Debt Banking News &#124; CDBN</title>
		<link>http://bit-player.org/2009/long-division#comment-2972</link>
		<dc:creator>Out of the cesspool and into the sewer: A/B testing trap : Credit Debt Banking News &#124; CDBN</dc:creator>
		<pubDate>Mon, 21 Jun 2010 20:50:57 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=267#comment-2972</guid>
		<description>[...] as what we only called a &#8220;cesspool&#8221; (and what some-more beautiful writers call a &#8220;watershed.&#8221;) Your exam is a H2O in a backyard &#8212; you&#8217;ve flowed in to a lowest point, though [...]</description>
		<content:encoded><![CDATA[<p>[...] as what we only called a &#8220;cesspool&#8221; (and what some-more beautiful writers call a &#8220;watershed.&#8221;) Your exam is a H2O in a backyard &mdash; you&#8217;ve flowed in to a lowest point, though [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bruce</title>
		<link>http://bit-player.org/2009/long-division#comment-1965</link>
		<dc:creator>Bruce</dc:creator>
		<pubDate>Mon, 23 Feb 2009 21:22:18 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=267#comment-1965</guid>
		<description>As a boater, I found this of interest... I'm not sure why, but :-)

Especially the part about sailing over the continental divide... that just sounds slick.

http://www.craftacraft.com/continental_divide</description>
		<content:encoded><![CDATA[<p>As a boater, I found this of interest&#8230; I&#8217;m not sure why, but :-)</p>
<p>Especially the part about sailing over the continental divide&#8230; that just sounds slick.</p>
<p><a href="http://www.craftacraft.com/continental_divide" rel="nofollow">http://www.craftacraft.com/continental_divide</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andreas Krey</title>
		<link>http://bit-player.org/2009/long-division#comment-1944</link>
		<dc:creator>Andreas Krey</dc:creator>
		<pubDate>Fri, 13 Feb 2009 23:17:13 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=267#comment-1944</guid>
		<description>So far, so bad. My simple algo apparently suffers badly from the noise in the data. I'm using the german area, an my paths seldom reach more than a few pixels before getting stuck somewhere....wait a minute.

Ok, the algorithm at least needs a way to fill plateaus and find an exit from those, just finding a local descent gets stuck in those as well.

Also the raw data (GLOBE) contains some artefacts, in http://ch.iocl.org/g.png (falsecolor to bring out small-elevation features) near the upper left water (pink) there are a few features that are too rectangular to be of natural origin.</description>
		<content:encoded><![CDATA[<p>So far, so bad. My simple algo apparently suffers badly from the noise in the data. I&#8217;m using the german area, an my paths seldom reach more than a few pixels before getting stuck somewhere&#8230;.wait a minute.</p>
<p>Ok, the algorithm at least needs a way to fill plateaus and find an exit from those, just finding a local descent gets stuck in those as well.</p>
<p>Also the raw data (GLOBE) contains some artefacts, in <a href="http://ch.iocl.org/g.png" rel="nofollow">http://ch.iocl.org/g.png</a> (falsecolor to bring out small-elevation features) near the upper left water (pink) there are a few features that are too rectangular to be of natural origin.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andreas Krey</title>
		<link>http://bit-player.org/2009/long-division#comment-1937</link>
		<dc:creator>Andreas Krey</dc:creator>
		<pubDate>Thu, 12 Feb 2009 22:02:55 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=267#comment-1937</guid>
		<description>O(n) with n being the number of pixels in the map, of course. And for each pixel when I build a path to the local minimun or an already-colored pixel, I traverse a path of some number of pixel, but I can color all of them in this iteration. Basically I only need to look at each pixel to or three times -- when I try to start from one that is already colored no work is needed.

Because I can truncate the minimum search when I encounter an already-colored pixel, I will search long paths for some pixels, but I will only try to find the steepest descent from each pixel one time -- when it is not yet colored.</description>
		<content:encoded><![CDATA[<p>O(n) with n being the number of pixels in the map, of course. And for each pixel when I build a path to the local minimun or an already-colored pixel, I traverse a path of some number of pixel, but I can color all of them in this iteration. Basically I only need to look at each pixel to or three times &#8212; when I try to start from one that is already colored no work is needed.</p>
<p>Because I can truncate the minimum search when I encounter an already-colored pixel, I will search long paths for some pixels, but I will only try to find the steepest descent from each pixel one time &#8212; when it is not yet colored.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jess</title>
		<link>http://bit-player.org/2009/long-division#comment-1936</link>
		<dc:creator>Jess</dc:creator>
		<pubDate>Thu, 12 Feb 2009 20:09:46 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=267#comment-1936</guid>
		<description>Andreas, that algorithm makes quite a bit of sense, and solves some of the problems described above, but I don't think it's O(n).  That is definitely a lower bound for any algorithm; you have to go to each pixel to color it.  For your algorithm, for each pixel you color, you have to traverse some sequence of untraversed pixels.  You could probably make an argument that the length of that sequence will decrease at a particular speed, and maybe that would give an O(n log n) or similar complexity.</description>
		<content:encoded><![CDATA[<p>Andreas, that algorithm makes quite a bit of sense, and solves some of the problems described above, but I don&#8217;t think it&#8217;s O(n).  That is definitely a lower bound for any algorithm; you have to go to each pixel to color it.  For your algorithm, for each pixel you color, you have to traverse some sequence of untraversed pixels.  You could probably make an argument that the length of that sequence will decrease at a particular speed, and maybe that would give an O(n log n) or similar complexity.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andreas Krey</title>
		<link>http://bit-player.org/2009/long-division#comment-1930</link>
		<dc:creator>Andreas Krey</dc:creator>
		<pubDate>Thu, 12 Feb 2009 08:08:27 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=267#comment-1930</guid>
		<description>I think there is a very simple O(n) algorithm. Just start from each pixel in the image and find the fastest way downwards. When you end up at a minimum, mark all pixels traversed with the location of the minimum pixel. Likewise if you run into an already-marked pixel, mark back the current path. Choose a color for each minimum found. Of course you need to put artificial rigdes into the ocean when you do the whole of north america.</description>
		<content:encoded><![CDATA[<p>I think there is a very simple O(n) algorithm. Just start from each pixel in the image and find the fastest way downwards. When you end up at a minimum, mark all pixels traversed with the location of the minimum pixel. Likewise if you run into an already-marked pixel, mark back the current path. Choose a color for each minimum found. Of course you need to put artificial rigdes into the ocean when you do the whole of north america.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Tang</title>
		<link>http://bit-player.org/2009/long-division#comment-1928</link>
		<dc:creator>Chris Tang</dc:creator>
		<pubDate>Thu, 12 Feb 2009 06:10:53 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=267#comment-1928</guid>
		<description>Here's an idea:
put the pixels in a priority queue with lowest-height first.  
put each pixel into its own set

for all pixels of the next-lowest height. . .
remove the next pixel and mark it colored.  among all of its adjacent, colored, neighbors, choose that with the greatest height (aka the neighbor with best matching height)
if there is such a neighbor (could be NO neighbors are colored), union the sets of the current pixel and its neighbor
repeat the loop until queue is empty.

Sets now contain the terrain, properly divided up.
Simple, n lg n algorithm due to the priority queue.  Everything else is linear time.</description>
		<content:encoded><![CDATA[<p>Here&#8217;s an idea:<br />
put the pixels in a priority queue with lowest-height first.<br />
put each pixel into its own set</p>
<p>for all pixels of the next-lowest height. . .<br />
remove the next pixel and mark it colored.  among all of its adjacent, colored, neighbors, choose that with the greatest height (aka the neighbor with best matching height)<br />
if there is such a neighbor (could be NO neighbors are colored), union the sets of the current pixel and its neighbor<br />
repeat the loop until queue is empty.</p>
<p>Sets now contain the terrain, properly divided up.<br />
Simple, n lg n algorithm due to the priority queue.  Everything else is linear time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brooks moses</title>
		<link>http://bit-player.org/2009/long-division#comment-1926</link>
		<dc:creator>Brooks moses</dc:creator>
		<pubDate>Wed, 11 Feb 2009 22:25:56 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=267#comment-1926</guid>
		<description>Incidentally, it should be pretty easy to extend the algorithm to find new basins/bubbles, rather than arbitrarily coloring them in with the color of an adjacent basin.

A characteristic of an unseeded basin is that any pixel on its rim drains into an area that has not yet been colored.  Thus, when the coloring algorithm reaches the lowest point on the rim, the pixels inside the basin will have the property that they are (a) uncolored, and (b) lower than the current "water level".

Thus, when you color a pixel, you can add a check to see whether it is in fact in the band of elevations that you are expecting to color.  If it is below that level, it must be inside an unseeded basin.  Thus, you can follow a steepest-descent algorithm to find the spot at the bottom of the basin, place a seed there, and raise the water level on that seed until it reaches the current level.

We know that the steepest-descent algorithm will do the right thing.  It won't run into an existing basin, because that would require there to be an uncolored pixel that is lower than the one we started with, but which is adjacent to an existing basin; this cannot happen because of the order in which basins are colored.  Also, any uncolored pixel that the steepest-descent algorithm lands on will be the bottom of a basin; if steepest-descents from all pixels in an uncolored region do not resolve to a unique answer, that means either that the bottom is flat (so it doesn't matter) or that there are multiple unseeded basins within the region.  The basin-filling algorithm should be recursive; if you find another unseeded basin while doing this, you go and fill it in, and then raise the pair up to the main current level.

A relevant observation is that, since the basin is previously-undiscovered, we know that the filling process will not reach a boundary with the existing basins/oceans until we get up to the current level, and thus the result is not different from having placed seeds in the basins a priori.</description>
		<content:encoded><![CDATA[<p>Incidentally, it should be pretty easy to extend the algorithm to find new basins/bubbles, rather than arbitrarily coloring them in with the color of an adjacent basin.</p>
<p>A characteristic of an unseeded basin is that any pixel on its rim drains into an area that has not yet been colored.  Thus, when the coloring algorithm reaches the lowest point on the rim, the pixels inside the basin will have the property that they are (a) uncolored, and (b) lower than the current &#8220;water level&#8221;.</p>
<p>Thus, when you color a pixel, you can add a check to see whether it is in fact in the band of elevations that you are expecting to color.  If it is below that level, it must be inside an unseeded basin.  Thus, you can follow a steepest-descent algorithm to find the spot at the bottom of the basin, place a seed there, and raise the water level on that seed until it reaches the current level.</p>
<p>We know that the steepest-descent algorithm will do the right thing.  It won&#8217;t run into an existing basin, because that would require there to be an uncolored pixel that is lower than the one we started with, but which is adjacent to an existing basin; this cannot happen because of the order in which basins are colored.  Also, any uncolored pixel that the steepest-descent algorithm lands on will be the bottom of a basin; if steepest-descents from all pixels in an uncolored region do not resolve to a unique answer, that means either that the bottom is flat (so it doesn&#8217;t matter) or that there are multiple unseeded basins within the region.  The basin-filling algorithm should be recursive; if you find another unseeded basin while doing this, you go and fill it in, and then raise the pair up to the main current level.</p>
<p>A relevant observation is that, since the basin is previously-undiscovered, we know that the filling process will not reach a boundary with the existing basins/oceans until we get up to the current level, and thus the result is not different from having placed seeds in the basins a priori.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mccoyn</title>
		<link>http://bit-player.org/2009/long-division#comment-1925</link>
		<dc:creator>mccoyn</dc:creator>
		<pubDate>Wed, 11 Feb 2009 18:47:53 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=267#comment-1925</guid>
		<description>It would be difficult to reverse the algorithm to find basins. To decide which point to remove you would want to remove the highest point under a body of water that includes one of the oceans.  I don't see an easy way to tell the difference between a point under water in a basin and a point under water that is connected to an ocean.

The continuously varied coastline sounds like a fun idea, but I expect the results will be very similar to what would happen if you put a seed point wherever a river meets an ocean.</description>
		<content:encoded><![CDATA[<p>It would be difficult to reverse the algorithm to find basins. To decide which point to remove you would want to remove the highest point under a body of water that includes one of the oceans.  I don&#8217;t see an easy way to tell the difference between a point under water in a basin and a point under water that is connected to an ocean.</p>
<p>The continuously varied coastline sounds like a fun idea, but I expect the results will be very similar to what would happen if you put a seed point wherever a river meets an ocean.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Harald Hanche-Olsen</title>
		<link>http://bit-player.org/2009/long-division#comment-1924</link>
		<dc:creator>Harald Hanche-Olsen</dc:creator>
		<pubDate>Wed, 11 Feb 2009 18:35:30 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=267#comment-1924</guid>
		<description>It would indeed be interesting to have the source code. Here in Norway, we have a lake that actually drains into two rivers, one heading west and one heading east. So anything draining into that lake should have a different colour. I am not sure how that could be achieved, but it should be similar to your bubbles. (Not sure if I can get hold of good enough map data.)</description>
		<content:encoded><![CDATA[<p>It would indeed be interesting to have the source code. Here in Norway, we have a lake that actually drains into two rivers, one heading west and one heading east. So anything draining into that lake should have a different colour. I am not sure how that could be achieved, but it should be similar to your bubbles. (Not sure if I can get hold of good enough map data.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jon Canady</title>
		<link>http://bit-player.org/2009/long-division#comment-1923</link>
		<dc:creator>Jon Canady</dc:creator>
		<pubDate>Wed, 11 Feb 2009 17:21:36 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=267#comment-1923</guid>
		<description>Count this as one vote for "release Lisp source."  Fascinating article, as well!</description>
		<content:encoded><![CDATA[<p>Count this as one vote for &#8220;release Lisp source.&#8221;  Fascinating article, as well!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Harald Hanche-Olsen</title>
		<link>http://bit-player.org/2009/long-division#comment-1922</link>
		<dc:creator>Harald Hanche-Olsen</dc:creator>
		<pubDate>Wed, 11 Feb 2009 16:32:27 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=267#comment-1922</guid>
		<description>If you wish to do all of North America, you get a problem with definitions: The continental US (excluding Alaska) is handy in that the wet portion of its boundary has two components. For North America there is only one. Where do you say the Atlantic coast stops? Or where the Pacific starts? And should you count the Arctic sea as a separate body of water? Ideally, one should be able to color the coastline with a continuously varying color, then color the whole continent according to where a falling raindrop drains into the sea. But your approach does not seem amenable to dealing with this much harder problem.</description>
		<content:encoded><![CDATA[<p>If you wish to do all of North America, you get a problem with definitions: The continental US (excluding Alaska) is handy in that the wet portion of its boundary has two components. For North America there is only one. Where do you say the Atlantic coast stops? Or where the Pacific starts? And should you count the Arctic sea as a separate body of water? Ideally, one should be able to color the coastline with a continuously varying color, then color the whole continent according to where a falling raindrop drains into the sea. But your approach does not seem amenable to dealing with this much harder problem.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin</title>
		<link>http://bit-player.org/2009/long-division#comment-1921</link>
		<dc:creator>Kevin</dc:creator>
		<pubDate>Wed, 11 Feb 2009 16:18:43 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=267#comment-1921</guid>
		<description>Very interesting read. I thoroughly enjoyed it and loved the images. Thanks.</description>
		<content:encoded><![CDATA[<p>Very interesting read. I thoroughly enjoyed it and loved the images. Thanks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian</title>
		<link>http://bit-player.org/2009/long-division#comment-1920</link>
		<dc:creator>Brian</dc:creator>
		<pubDate>Wed, 11 Feb 2009 16:03:29 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=267#comment-1920</guid>
		<description>What if you did the reverse process: flood everything, and slowly drain away, checking for the moment when the fluids part? Seems that this would generate the basin boundaries.</description>
		<content:encoded><![CDATA[<p>What if you did the reverse process: flood everything, and slowly drain away, checking for the moment when the fluids part? Seems that this would generate the basin boundaries.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mikola</title>
		<link>http://bit-player.org/2009/long-division#comment-1919</link>
		<dc:creator>Mikola</dc:creator>
		<pubDate>Wed, 11 Feb 2009 15:22:33 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=267#comment-1919</guid>
		<description>Have you thought about using graph cuts to solve this segmentation problem?  I think that if you tried setting the weight for each edge according to (MAX_HEIGHT - difference) then you ought to be able to get similar results.   

Here is a tutorial:  http://www.cis.upenn.edu/~jshi/GraphTutorial/

For the multicolor case, an optimal segmentation can be approximated to within a constant factor of optimality using Boykov &#38; Kolmogorov's method.</description>
		<content:encoded><![CDATA[<p>Have you thought about using graph cuts to solve this segmentation problem?  I think that if you tried setting the weight for each edge according to (MAX_HEIGHT - difference) then you ought to be able to get similar results.   </p>
<p>Here is a tutorial:  <a href="http://www.cis.upenn.edu/~jshi/GraphTutorial/" rel="nofollow">http://www.cis.upenn.edu/~jshi/GraphTutorial/</a></p>
<p>For the multicolor case, an optimal segmentation can be approximated to within a constant factor of optimality using Boykov &amp; Kolmogorov&#8217;s method.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

