[kepler-dev] Fwd: [Kepler - Bug #6439] (New) Double rounding fails in some cases while evaluating Expressions

[Christopher Brooks]

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: <noreply at nceas.ucsb.edu <mailto:noreply at nceas.ucsb.edu>>
>> 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
>> Kepler-dev at kepler-project.org
>> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>
>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> 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
cxh at eecs.berkeley.edu, 707.332.0670           (Office: 545Q Cory)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20140305/32cb6907/attachment.html>