[Tcl-bugs] [ tcl-Patches-1340260 ] Simplify round() implementation in expr cmd

[SourceForge.net <no...@so...>]

Patches item #1340260, was opened at 2005-10-28 00:22
Message generated for change (Settings changed) made by dgp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310894&aid=1340260&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 44. Parsing and Eval
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Mo DeJong (mdejong)
Assigned to: Don Porter (dgp)
Summary: Simplify round() implementation in expr cmd

Initial Comment:
I was just reviewing the round() implementation in Tcl 8.4
vs Tcl 8.5. The round() implementation seems to be
more complex than it needs to be. The attached patch
simplifies the function so that it works more like the
8.4 version. I also added tests cases around the min int
and max int cases. As far and I can tell, the results of
no tests are changed by this patch. Kevin, could you
review this patch before I apply it?

----------------------------------------------------------------------

>Comment By: Don Porter (dgp)
Date: 2005-11-01 10:18

Message:
Logged In: YES 
user_id=80530


Here's a test case:

test expr-46.13 {round() handling of long/bignum boundary} {
    expr {round(double(0x7fffffffffffffff))}
} 9223372036854775808

With the contributed patch, on L64 systems:

==== expr-46.13 round() handling of long/bignum boundary FAILED
==== Contents of test case:

    expr {round(double(0x7fffffffffffffff))}

---- Result was:
-9223372036854775808
---- Result should have been (exact matching):
9223372036854775808
==== expr-46.13 FAILED

On the HEAD, the test passes.

Committing that to the test suite...

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2005-11-01 09:55

Message:
Logged In: YES 
user_id=80530


The problem is with systems with
64-bit longs.  Since IEEE doubles
have only 53 bits of precision, the
calculation

    (double) LONG_MAX - 1.0

for example, can't be performed.
That is, the subtraction is lost
below the precision threshold.

Doing the operations as longs
doesn't suffer this problem.

----------------------------------------------------------------------

Comment By: Kevin B KENNY (kennykb)
Date: 2005-10-31 10:28

Message:
Logged In: YES 
user_id=99768

Don, I don't see anything obvious wrong with Mo's approach,
but I haven't had time to really go over things with a
fine-toothed
comb.  It looks as if he has the corner cases accounted for.
Could you give it a second look?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310894&aid=1340260&group_id=10894