<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">This is a known issue with doubles, I
      suggested some fixes and closed the bug report.<br>
      <br>
      <a class="moz-txt-link-freetext" href="https://projects.ecoinformatics.org/ecoinfo/issues/6439">https://projects.ecoinformatics.org/ecoinfo/issues/6439</a><br>
      <br>
      <blockquote type="cite">
        <meta http-equiv="content-type" content="text/html;
          charset=ISO-8859-1">
        <div class="wiki" id="journal-21517-notes">
          <p>It is almost never a good idea to compare doubles without
            using an epsilon factor. Because of rounding, doubles are
            unlikely to precisely represent a value.</p>
          <p>One workaround in the expression language is to use</p>
          <p>close(value1, value2)</p>
          <p>which is defined as:</p>
          <p>Return true if the first argument<br>
            is close to the second (within<br>
            EPSILON, where EPSILON is<br>
            a static public variable of this<br>
            class)</p>
          <p>Tokens also have an isCloseTo() method:</p>
          <p>/** Test whether the value of this Token is close to the
            argument * Token. The argument and this token are converted
            to * equivalent types, and then compared. Generally, this is
            the * higher of the type of this token and the argument
            type. * Subclasses should implement the protected
            _isCloseTo() method * to perform the correct type-specific
            operation. * @see #isEqualTo * @param rightArgument The
            token to test closeness of this token with. * @param epsilon
            The value that we use to determine whether two * tokens are
            close. * @return A boolean token that contains the value
            true if the * units of this token and the argument token are
            the same, and their * values are close. * @exception
            IllegalActionException If the argument token is not * of a
            type that can be compared with this token, or the units *
            are not the same. <br>
            */<br>
            public final BooleanToken isCloseTo(Token rightArgument,
            double epsilon)</p>
          <p>See 13.4.1 Invoking Methods in <a class="external"
href="http://ptolemy.eecs.berkeley.edu/books/Systems/chapters/Expressions.pdf">http://ptolemy.eecs.berkeley.edu/books/Systems/chapters/Expressions.pdf</a></p>
        </div>
      </blockquote>
      <br>
      On 3/5/14 10:24 AM, Edward Lee wrote:<br>
    </div>
    <blockquote cite="mid:53176BEA.9000908@eecs.berkeley.edu"
      type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <br>
      I doubt this is a new issue. The underlying arithmetic is IEEE
      754.<br>
      Floating point numbers have the following problems (at least):<br>
      <br>
      - addition is not associative<br>
      - not all decimal numbers within the range of representable
      numbers are representable exactly<br>
      <br>
      Basically, it is rarely justifiable to test for equality of
      doubles.<br>
      <br>
      Edward<br>
      <br>
      <br>
      <div class="moz-cite-prefix">On 3/4/14 11:21 AM, Matt Jones wrote:<br>
      </div>
      <blockquote
cite="mid:CAFSW8x=nNPjuXsftGO9BDUWcWpCwCm0fzxhJjpW9Uf2r_YGX1Q@mail.gmail.com"
        type="cite">
        <div dir="ltr">Daniel and Christopher --
          <div><br>
          </div>
          <div>Do either of you have any insight into this new rounding
            issue?  Can you confirm whether or not this is new behavior?</div>
          <div><br>
          </div>
          <div>Matt<br>
            <br>
            <div class="gmail_quote"> ---------- Forwarded message
              ----------<br>
              From: <span dir="ltr"><<a moz-do-not-send="true"
                  href="mailto:noreply@nceas.ucsb.edu">noreply@nceas.ucsb.edu</a>></span><br>
              Date: Tue, Mar 4, 2014 at 3:24 AM<br>
              Subject: [Kepler - Bug #6439] (New) Double rounding fails
              in some cases while evaluating Expressions<br>
              To: <br>
              <br>
              <br>
              <div> <span></span> Issue #6439 has been reported by
                Owsiak Michal.
                <hr>
                <h1><a moz-do-not-send="true"
                    href="https://projects.ecoinformatics.org/ecoinfo/issues/6439"
                    target="_blank">Bug #6439: Double rounding fails in
                    some cases while evaluating Expressions</a></h1>
                <ul>
                  <li>Author: Owsiak Michal</li>
                  <li>Status: New</li>
                  <li>Priority: Urgent</li>
                  <li>Assignee: Derik Barseghian</li>
                  <li>Category: actors</li>
                  <li>Target version: 2.3.0</li>
                  <li>Bugzilla-Id: </li>
                </ul>
                <p>It seems that addition of doubles can produce values
                  slightly different than they should to be.</p>
                <p>Please take a look at attached workflow
                  (simple_error.xml).</p>
                <p>Condition that should be satisfied to escape the loop
                  is: 1.7 > 1.5 + 0.1</p>
                <p>However, loop is interrupted sooner, because of
                  incorrect calculation of doubles. Value of "p" is set
                  to: 1.6000000000000003</p>
                <p>This, of course, makes it impossible to use doubles
                  as check points for the loops.</p>
                <p>However, it seems that casting to string and back
                  works fine (take a look at second workflow -
                  simple.xml)</p>
                <p>Cheers</p>
                <p>Michal</p>
                <hr> <span>
                  <p>You have received this notification because you
                    have either subscribed to it, or are involved in it.<br>
                    To change your notification preferences, please
                    click here: <a moz-do-not-send="true"
                      href="https://projects.ecoinformatics.org/ecoinfo/my/account"
                      target="_blank">https://projects.ecoinformatics.org/ecoinfo/my/account</a></p>
                </span> </div>
            </div>
            <br>
          </div>
        </div>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
Kepler-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Kepler-dev@kepler-project.org">Kepler-dev@kepler-project.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev">http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Kepler-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kepler-dev@kepler-project.org">Kepler-dev@kepler-project.org</a>
<a class="moz-txt-link-freetext" href="http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev">http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Christopher Brooks, PMP                       University of California
Academic Program Manager & Software Engineer  US Mail: 337 Cory Hall
CHESS/iCyPhy/Ptolemy/TerraSwarm               Berkeley, CA 94720-1774
<a class="moz-txt-link-abbreviated" href="mailto:cxh@eecs.berkeley.edu">cxh@eecs.berkeley.edu</a>, 707.332.0670           (Office: 545Q Cory)
</pre>
  </body>
</html>