<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Visualizing Floats</title>
	<atom:link href="http://cowboyprogramming.com/2007/01/05/visualizing-floats/feed/" rel="self" type="application/rss+xml" />
	<link>http://cowboyprogramming.com/2007/01/05/visualizing-floats/</link>
	<description>Game Development and General Hacking by the Old West</description>
	<lastBuildDate>Sat, 21 Jan 2012 10:03:39 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Fyodor</title>
		<link>http://cowboyprogramming.com/2007/01/05/visualizing-floats/comment-page-1/#comment-207225</link>
		<dc:creator>Fyodor</dc:creator>
		<pubDate>Thu, 24 Mar 2011 01:52:06 +0000</pubDate>
		<guid isPermaLink="false">http://cowboyprogramming.com/?p=40#comment-207225</guid>
		<description>Great job, Mick! This article makes people to think about stuff that they use every day but have no idea how it works. 

I would like to add a little note about scaling. In fact using large scaling e.g. nanometers will give you _slightly_ better accuracy than your get using parsecs. But the accuracy ratio of different scalings will newer exceed 2. And there is no matter is it float or double.</description>
		<content:encoded><![CDATA[<p>Great job, Mick! This article makes people to think about stuff that they use every day but have no idea how it works. </p>
<p>I would like to add a little note about scaling. In fact using large scaling e.g. nanometers will give you _slightly_ better accuracy than your get using parsecs. But the accuracy ratio of different scalings will newer exceed 2. And there is no matter is it float or double.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: burning calories</title>
		<link>http://cowboyprogramming.com/2007/01/05/visualizing-floats/comment-page-1/#comment-144111</link>
		<dc:creator>burning calories</dc:creator>
		<pubDate>Wed, 06 Jan 2010 17:38:52 +0000</pubDate>
		<guid isPermaLink="false">http://cowboyprogramming.com/?p=40#comment-144111</guid>
		<description>thanks a lot for the interesting and informative post.</description>
		<content:encoded><![CDATA[<p>thanks a lot for the interesting and informative post.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dog health information</title>
		<link>http://cowboyprogramming.com/2007/01/05/visualizing-floats/comment-page-1/#comment-138304</link>
		<dc:creator>dog health information</dc:creator>
		<pubDate>Sat, 21 Nov 2009 23:27:14 +0000</pubDate>
		<guid isPermaLink="false">http://cowboyprogramming.com/?p=40#comment-138304</guid>
		<description>I think commenter erik lien is right.  Might want to doublecheck that Mike.</description>
		<content:encoded><![CDATA[<p>I think commenter erik lien is right.  Might want to doublecheck that Mike.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Catherine Ellis</title>
		<link>http://cowboyprogramming.com/2007/01/05/visualizing-floats/comment-page-1/#comment-135186</link>
		<dc:creator>Catherine Ellis</dc:creator>
		<pubDate>Mon, 26 Oct 2009 00:54:10 +0000</pubDate>
		<guid isPermaLink="false">http://cowboyprogramming.com/?p=40#comment-135186</guid>
		<description>Enjoyed reading this article, nice one Mick</description>
		<content:encoded><![CDATA[<p>Enjoyed reading this article, nice one Mick</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ð›ÑŽÐ±Ð¸Ñ‚ÐµÐ»ÑŒ Ð¼Ð¸Ð½Ð¸-Ð¸Ð³Ñ€</title>
		<link>http://cowboyprogramming.com/2007/01/05/visualizing-floats/comment-page-1/#comment-95602</link>
		<dc:creator>Ð›ÑŽÐ±Ð¸Ñ‚ÐµÐ»ÑŒ Ð¼Ð¸Ð½Ð¸-Ð¸Ð³Ñ€</dc:creator>
		<pubDate>Thu, 19 Mar 2009 13:42:07 +0000</pubDate>
		<guid isPermaLink="false">http://cowboyprogramming.com/?p=40#comment-95602</guid>
		<description>Great article, Mick!</description>
		<content:encoded><![CDATA[<p>Great article, Mick!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Erik Lien</title>
		<link>http://cowboyprogramming.com/2007/01/05/visualizing-floats/comment-page-1/#comment-92950</link>
		<dc:creator>Erik Lien</dc:creator>
		<pubDate>Tue, 10 Mar 2009 03:07:51 +0000</pubDate>
		<guid isPermaLink="false">http://cowboyprogramming.com/?p=40#comment-92950</guid>
		<description>In your FLOATS vs. INTEGERS part you got the precision wrong. Remember the implicit bit in floating point numbers. 32 bit floats have 24 bits of precision. (If you want to store integers in a float, you can accurately represent all integers from 0 to 16777216. As you said, between any 2 powers of two there are 8388608 possible numbers, so from 8388608 to 16777216 you have all the needed 8388608 integers. From 0 to 8388608 you also have all the integers plus lots of numbers inbetween. From 16777216 to 33554432 you only have the even integers)

So your precision up to 2^32mm becomes 256mm. Using the sign bit (by centering the world, as mentioned), your precision increases to 128mm. Still not great, but much more useful than 512mm. And you could use doubles :)</description>
		<content:encoded><![CDATA[<p>In your FLOATS vs. INTEGERS part you got the precision wrong. Remember the implicit bit in floating point numbers. 32 bit floats have 24 bits of precision. (If you want to store integers in a float, you can accurately represent all integers from 0 to 16777216. As you said, between any 2 powers of two there are 8388608 possible numbers, so from 8388608 to 16777216 you have all the needed 8388608 integers. From 0 to 8388608 you also have all the integers plus lots of numbers inbetween. From 16777216 to 33554432 you only have the even integers)</p>
<p>So your precision up to 2^32mm becomes 256mm. Using the sign bit (by centering the world, as mentioned), your precision increases to 128mm. Still not great, but much more useful than 512mm. And you could use doubles :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: „¥âáª¨¥ ¨£àë</title>
		<link>http://cowboyprogramming.com/2007/01/05/visualizing-floats/comment-page-1/#comment-77026</link>
		<dc:creator>„¥âáª¨¥ ¨£àë</dc:creator>
		<pubDate>Sun, 18 Jan 2009 17:43:10 +0000</pubDate>
		<guid isPermaLink="false">http://cowboyprogramming.com/?p=40#comment-77026</guid>
		<description>Great article! Very nice</description>
		<content:encoded><![CDATA[<p>Great article! Very nice</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sean T. McBeth</title>
		<link>http://cowboyprogramming.com/2007/01/05/visualizing-floats/comment-page-1/#comment-3066</link>
		<dc:creator>Sean T. McBeth</dc:creator>
		<pubDate>Mon, 13 Aug 2007 13:18:31 +0000</pubDate>
		<guid isPermaLink="false">http://cowboyprogramming.com/?p=40#comment-3066</guid>
		<description>I have similar concerns about using floats as color component values in HDRI. Color is equally dependant on the relative value between two &quot;consecutive&quot; colors as it is on the absolute value of that color. If there isn&#039;t enough resolution in our color data, then we end up with nasty gradients.

As you probably already know, HDRI seeks to use values outside of the [0.0 1.0] range in order to represent light saturation. Almost a full 1/8th of all usable 32b floating point values (because of the NaN and inf definition, there are only (2^32 - 2^24) usable values, and only half of them are positive) fall in the [0.0 1.0] range, and as you demonstrated, the values get much worse the further out you get.

It&#039;s unfortunate that the latest graphics hardware is now hardwired to exclusively use floats in shader operations.</description>
		<content:encoded><![CDATA[<p>I have similar concerns about using floats as color component values in HDRI. Color is equally dependant on the relative value between two &#8220;consecutive&#8221; colors as it is on the absolute value of that color. If there isn&#8217;t enough resolution in our color data, then we end up with nasty gradients.</p>
<p>As you probably already know, HDRI seeks to use values outside of the [0.0 1.0] range in order to represent light saturation. Almost a full 1/8th of all usable 32b floating point values (because of the NaN and inf definition, there are only (2^32 &#8211; 2^24) usable values, and only half of them are positive) fall in the [0.0 1.0] range, and as you demonstrated, the values get much worse the further out you get.</p>
<p>It&#8217;s unfortunate that the latest graphics hardware is now hardwired to exclusively use floats in shader operations.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mick West</title>
		<link>http://cowboyprogramming.com/2007/01/05/visualizing-floats/comment-page-1/#comment-591</link>
		<dc:creator>Mick West</dc:creator>
		<pubDate>Tue, 03 Apr 2007 20:59:01 +0000</pubDate>
		<guid isPermaLink="false">http://cowboyprogramming.com/?p=40#comment-591</guid>
		<description>I don&#039;t know what I was thinking.  I must be getting old.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t know what I was thinking.  I must be getting old.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul Robinson</title>
		<link>http://cowboyprogramming.com/2007/01/05/visualizing-floats/comment-page-1/#comment-588</link>
		<dc:creator>Paul Robinson</dc:creator>
		<pubDate>Tue, 03 Apr 2007 18:39:48 +0000</pubDate>
		<guid isPermaLink="false">http://cowboyprogramming.com/?p=40#comment-588</guid>
		<description>That came up at a meeting here as well - adjusting the scale won&#039;t do a thing since all entities are scaled equally, so the accuracy you have will be scaled as well. I guess you could try scaling to a boundary to maximize the accuracy a little - ie. center your world, but make sure the extents are at -1 &amp; 1, say, and not -0.9 &amp; 0.9.</description>
		<content:encoded><![CDATA[<p>That came up at a meeting here as well &#8211; adjusting the scale won&#8217;t do a thing since all entities are scaled equally, so the accuracy you have will be scaled as well. I guess you could try scaling to a boundary to maximize the accuracy a little &#8211; ie. center your world, but make sure the extents are at -1 &amp; 1, say, and not -0.9 &amp; 0.9.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

