Re: [Boost-bugs] [Boost C++ Libraries] #7779: uniform_on_sphere returns -nan after many correct realizations when using single-precision floats

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #7779: uniform_on_sphere returns -nan after many correct realizations when using single-precision floats
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-12-10 16:00:08


#7779: uniform_on_sphere returns -nan after many correct realizations when using
single-precision floats
---------------------------------------------------+------------------------
  Reporter: Robert Gantner <rngantner@…> | Owner: no-maintainer
      Type: Bugs | Status: new
 Milestone: To Be Determined | Component: random
   Version: Boost 1.51.0 | Severity: Problem
Resolution: | Keywords:
---------------------------------------------------+------------------------

Comment (by Robert Gantner <rngantner@…>):

 The bug seems to be at line 70 of `uniform_on_sphere.hpp`. The function
 `std::divides` attempts to divide by zero if `sqsum` is zero (or close to
 it). This results in `0/0=NaN` for each component, since `sqsum` is only
 zero if all components are zero.

 In the case mentioned above for `float`s, `sqsum` 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 `sqsum` is too small, but
 this would be an unnecessary overhead.

 A better solution may be to implement the suggestion in ticket
 [ticket:1059], 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.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/7779#comment:2>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:11 UTC