<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Marc:<br>
    <br>
    _num.scm has some code to deal with computing the correct inexact
    real for (sqrt x) when x is an exact number and (sqrt x) is not an
    exact number.<br>
    <br>
    The simplest thing to do would be (sqrt (exact->inexact x)), but
    I feared that the double rounding could lead to incorrect (but very
    close) answers.  (There are also issues of unnecessary overflows and
    underflows with that simple expression.)<br>
    <br>
    So I ran some random tests to see (a) whether the Gambit code always
    gave correctly-rounded answers (it did), and (b) how often it
    happened that double rounding caused (sqrt (exact->inexact x)) to
    give incorrect answers.<br>
    <br>
    In just 100 tests of (sqrt x) where x is a rational with numerator
    and denominator between 1 and 100, the tests found the following
    examples where (sqrt (exact->inexact x)) gives incorrect
    answers.  In each row the numbers are: x, (sqrt (exact->inexact
    x)), and correctly-rounded (sqrt x):<br>
    <br>
    <blockquote><tt>(double-rounded-result-wrong 9/70 .35856858280031806
        .3585685828003181)</tt><br>
      <tt>(double-rounded-result-wrong 33/49 .8206518066482897
        .8206518066482898)</tt><br>
      <tt>(double-rounded-result-wrong 87/91 .977775002771065
        .9777750027710649)</tt><br>
      <tt>(double-rounded-result-wrong 100/67 1.2216944435630523
        1.2216944435630521)</tt><br>
      <tt>(double-rounded-result-wrong 77/18 2.068278940998476
        2.0682789409984763)</tt><br>
      <tt>(double-rounded-result-wrong 3/7 .6546536707079771
        .6546536707079772)</tt><br>
      <tt>(double-rounded-result-wrong 48/7 2.6186146828319083
        2.618614682831909)</tt><br>
      <tt>(double-rounded-result-wrong 20/51 .6262242910851494
        .6262242910851495)</tt><br>
      <tt>(double-rounded-result-wrong 25/11 1.5075567228888183
        1.507556722888818)</tt><br>
      <tt>(double-rounded-result-wrong 38/59 .8025383458814721
        .8025383458814722)</tt><br>
      <tt>(double-rounded-result-wrong 3/7 .6546536707079771
        .6546536707079772)</tt><br>
      <tt>(double-rounded-result-wrong 25/11 1.5075567228888183
        1.507556722888818)</tt><br>
    </blockquote>
    <br>
    So even for something as simple as (sqrt 3/7) the formula (sqrt
    (exact->inexact 3/7)) gives an  unnecessarily inaccurate answer.<br>
    <br>
    And for integers we have the example<br>
    <br>
    <blockquote><tt>(double-rounded-result-wrong 5680341405563297078633
        7.536803968237e10 7.536803968236998e10)</tt><br>
    </blockquote>
    <br>
    Pretty cool.  Maybe not so important, but still cool!<br>
    <br>
    Brad<br>
  </body>
</html>