This is a known issue with doubles, I suggested some fixes and closed
the bug report.
https://projects.ecoinformatics.org/ecoinfo/issues/6439
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.
One workaround in the expression language is to use
close(value1, value2)
which is defined as:
Return true if the first argument
is close to the second (within
EPSILON, where EPSILON is
a static public variable of this
class)
Tokens also have an isCloseTo() method:
/** 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.
*/
public final BooleanToken isCloseTo(Token rightArgument, double epsilon)
See 13.4.1 Invoking Methods in
http://ptolemy.eecs.berkeley.edu/books/Systems/chapters/Expressions.pdf
On 3/5/14 10:24 AM, Edward Lee wrote:
I doubt this is a new issue. The underlying arithmetic is IEEE 754.
Floating point numbers have the following problems (at least):
- addition is not associative
- not all decimal numbers within the range of representable numbers
are representable exactly
Basically, it is rarely justifiable to test for equality of doubles.
Edward
On 3/4/14 11:21 AM, Matt Jones wrote:
Daniel and Christopher --
Do either of you have any insight into this new rounding issue? Can
you confirm whether or not this is new behavior?
Matt
---------- Forwarded message ----------
From: <[email protected] <mailto:[email protected]>>
Date: Tue, Mar 4, 2014 at 3:24 AM
Subject: [Kepler - Bug #6439] (New) Double rounding fails in some
cases while evaluating Expressions
To:
Issue #6439 has been reported by Owsiak Michal.
------------------------------------------------------------------------
Bug #6439: Double rounding fails in some cases while evaluating
Expressions <https://projects.ecoinformatics.org/ecoinfo/issues/6439>
* Author: Owsiak Michal
* Status: New
* Priority: Urgent
* Assignee: Derik Barseghian
* Category: actors
* Target version: 2.3.0
* Bugzilla-Id:
It seems that addition of doubles can produce values slightly
different than they should to be.
Please take a look at attached workflow (simple_error.xml).
Condition that should be satisfied to escape the loop is: 1.7 > 1.5 + 0.1
However, loop is interrupted sooner, because of incorrect calculation
of doubles. Value of "p" is set to: 1.6000000000000003
This, of course, makes it impossible to use doubles as check points
for the loops.
However, it seems that casting to string and back works fine (take a
look at second workflow - simple.xml)
Cheers
Michal
------------------------------------------------------------------------
You have received this notification because you have either
subscribed to it, or are involved in it.
To change your notification preferences, please click here:
https://projects.ecoinformatics.org/ecoinfo/my/account
_______________________________________________
Kepler-dev mailing list
[email protected]
http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
_______________________________________________
Kepler-dev mailing list
[email protected]
http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
--
Christopher Brooks, PMP University of California
Academic Program Manager & Software Engineer US Mail: 337 Cory Hall
CHESS/iCyPhy/Ptolemy/TerraSwarm Berkeley, CA 94720-1774
[email protected], 707.332.0670 (Office: 545Q Cory)
_______________________________________________
Kepler-dev mailing list
[email protected]
http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
