Boost C++ Libraries: Ticket #7779: uniform_on_sphere returns nan in certain (rare) cases https://svn.boost.org/trac10/ticket/7779 <p> When simulating random vectors using the boost::uniform_on_sphere distribution with single-precision floating-point numbers, certain realizations are a vector of -nan. For the seed used in the included program, this happens at realization 3802480. The realizations before and after the wrong one are correct (i.e. lie on the unit circle). </p> <p> I have only found this to happen in two dimensions, although it happens for many different seed values. I have not encountered the problem when using doubles. </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/7779 Trac 1.4.3 Robert Gantner <rngantner@…> Mon, 10 Dec 2012 08:15:31 GMT attachment set https://svn.boost.org/trac10/ticket/7779 https://svn.boost.org/trac10/ticket/7779 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">bug_uniform_on_sphere.cpp</span> </li> </ul> <p> Program recreating uniform_on_sphere bug. </p> Ticket Robert Gantner <rngantner@…> Mon, 10 Dec 2012 14:16:48 GMT <link>https://svn.boost.org/trac10/ticket/7779#comment:1 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7779#comment:1</guid> <description> <p> When using double precision, the same program leads to a realization composed of NaN's after 1573458057 realizations. </p> <p> Btw, there's an error in the program: it uses the default seed of 5489u since the generator is copied (forgot an &amp; after <code>GeneratorType</code> on line 13). </p> </description> <category>Ticket</category> </item> <item> <author>Robert Gantner <rngantner@…></author> <pubDate>Mon, 10 Dec 2012 16:00:08 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/7779#comment:2 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7779#comment:2</guid> <description> <p> The bug seems to be at line 70 of <code>uniform_on_sphere.hpp</code>. The function <code>std::divides</code> attempts to divide by zero if <code>sqsum</code> is zero (or close to it). This results in <code>0/0=NaN</code> for each component, since <code>sqsum</code> is only zero if all components are zero. </p> <p> In the case mentioned above for <code>float</code>s, <code>sqsum</code> is zero to 20 decimal places at the 3802480th realization. In higher dimensions the probability of obtaining such a case of course decreases, but that does not solve the problem. A simple solution would be to test if <code>sqsum</code> is too small, but this would be an unnecessary overhead. </p> <p> A better solution may be to implement the suggestion in ticket <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/1059" title="#1059: Feature Requests: random_on_sphere can be made 10 times faster! (closed: fixed)">1059</a>, which would allow different algorithms to be used in lower-dimensional cases (where the probability of sampling all zeros is higher) and still retain the current, general implementation in higher dimensions where the probability of this error happening might be negligibly small. </p> </description> <category>Ticket</category> </item> <item> <author>Robert Gantner <rngantner@…></author> <pubDate>Wed, 12 Dec 2012 13:36:45 GMT</pubDate> <title>version, summary changed; keywords set https://svn.boost.org/trac10/ticket/7779#comment:3 https://svn.boost.org/trac10/ticket/7779#comment:3 <ul> <li><strong>keywords</strong> uniform_on_sphere random added </li> <li><strong>version</strong> <span class="trac-field-old">Boost 1.51.0</span> → <span class="trac-field-new">Boost 1.46.1</span> </li> <li><strong>summary</strong> <span class="trac-field-old">uniform_on_sphere returns -nan after many correct realizations when using single-precision floats</span> → <span class="trac-field-new">uniform_on_sphere returns nan in certain (rare) cases</span> </li> </ul> Ticket Steven Watanabe Thu, 14 Feb 2013 22:37:32 GMT <link>https://svn.boost.org/trac10/ticket/7779#comment:4 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7779#comment:4</guid> <description> <p> Actually it doesn't matter if sqsum is close to zero. As long as it isn't zero, there is no problem. (I suppose if sqsum were denormalized, it could be a problem, but normal_distribution doesn't produce denormalized numbers. I'm just going to add a test for zero. This shouldn't affect the performance in any noticeable way, since generating normal variates and dividing is much more expensive than a branch that is almost never taken. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Steven Watanabe</dc:creator> <pubDate>Sat, 16 Feb 2013 20:30:53 GMT</pubDate> <title>status changed; resolution set https://svn.boost.org/trac10/ticket/7779#comment:5 https://svn.boost.org/trac10/ticket/7779#comment:5 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> </ul> <p> (In <a class="changeset" href="https://svn.boost.org/trac10/changeset/82936" title="Avoid generating NaNs. Fixes #7779.">[82936]</a>) Avoid generating <a class="missing wiki">NaNs</a>. Fixes <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/7779" title="#7779: Bugs: uniform_on_sphere returns nan in certain (rare) cases (closed: fixed)">#7779</a>. </p> Ticket