Boost C++ Libraries: Ticket #569: rational::operator<(rational) fails due to overflow https://svn.boost.org/trac10/ticket/569 <pre class="wiki">Consider boost::rational&lt;long&gt;. Pick two objects of that type at random (that's well defined, since there are only finitely many objects of that type), and pick them to both have the same sign. Call them a and b. Then the expression "a &lt; b" returns the wrong value 50% of the time! The problem is that the calculation in rational.hpp can overflow, and that overflow actually happens most of the time. Here's a patch that implements operator&lt; without overflow. It's somewhat less efficient (I haven't benchmarked it) but it gives the right answer. Possibly the new version of operator&lt; has bugs. I've run a few hundred million random tests, with the right answer every time (I've used bc to check the answers), but there might be a subtle problem. In particular, the new code assumes that integer division always truncates towards 0, even when dividing negative integers. Perhaps that is not true on some obscure platforms/compilers? </pre> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/569 Trac 1.4.3 dbenbenn Tue, 07 Mar 2006 21:08:10 GMT <link>https://svn.boost.org/trac10/ticket/569#comment:1 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/569#comment:1</guid> <description> <pre class="wiki">Logged In: YES user_id=95581 Here's a new patch that uses std::numeric_limits to select the more efficient, direct comparison method for unbounded types, and only uses the overflow-avoiding method for types that can overflow. </pre> </description> <category>Ticket</category> </item> <item> <dc:creator>Daryle Walker</dc:creator> <pubDate>Thu, 02 Nov 2006 16:28:12 GMT</pubDate> <title>status changed https://svn.boost.org/trac10/ticket/569#comment:2 https://svn.boost.org/trac10/ticket/569#comment:2 <ul> <li><strong>status</strong> <span class="trac-field-old">assigned</span> → <span class="trac-field-new">closed</span> </li> </ul> <pre class="wiki">Logged In: YES user_id=551024 The problem was also described as bug #798357. Your issue should be fixed since I've fixed the other bug. I used continued-fraction expansion, with the components found by the Euclidean GCD algorithm and forcibly floor-rounding division &amp; modulus. </pre> Ticket