[Tcl-bugs] [ tktoolkit-Bugs-223739 ] tkTextDisp.c performs floating point comparisons (if ==)

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

Bugs item #223739, was updated on 2000-11-28 12:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=112997&aid=223739&group_id=12997

Category: [text]
Group: 8.0.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: tkTextDisp.c performs floating point comparisons (if ==)

Initial Comment:
I first ran into this in 8.0.5, but the 8.2.3 code has the same problem
and I suspect even the newest version has it.

tkTextDisp.c performs direct equivalence comparisons between floating
point values within if statments. Everybody should know this isn't valid
programming. Floating point comparisons need to be (|a-b|>delta).

Specifically, I have a case where GetYView() is failing on the following
statement on Linux when built with optimization.

if ((first == dInfoPtr->yScrollFirst) && (last == dInfoPtr->yScrollLast)) {

The failure causes Tk to go into on infinite loop.

While the same test case works on unix (hpux, solaris, etc), Linux is
running on intel hardware. And intel chips perform 80-bit floating point
arithemetic even when doubles are stored as 64-bit values. So there
is more precission in the registers and the optimized code uses more
registers.

I've found the following 3 workarounds.
1. Compile tkTextDisp.c non-optimized (works by accident).
2. Write a compare function and pass the values of this specific
    if statement to it. The compare function uses the if ==, but
    this causes the register values to go through storage. Hence,
    causing the precission to be set back to 64-bit values.
3. Force 53-bit arithmetic by with the following code in main().
    (or tk_Main, or ...). This mimics other unix vendor hardware.
    Note the variable 'i' MUST be used.
   #include <fpu_control.h>
   int i = 0x127f;
   _FPU_SETCW(i);

These are all bandaids and can still fail. The real fix is to fix the
actual problem. ie Code proper arithmetic tests within Tcl/Tk.


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

>Comment By: Donal K. Fellows (dkf)
Date: 2001-05-04 03:54

Message:
Logged In: YES 
user_id=79902

It depends how long a thing is being scrolled, doesn't it?
If you've got a piece of text 3000 lines long (or better
yet, a pair of texts that long, such as you might have in
tkdiff of some of the Tcl/Tk sources) a 0.1% difference
could well be noticable.

The correct answer is that the epsilon depends on what the
range is; multiply by dInfoPtr->maxX (or maxY for vertical
scrolling) and check to see if it is less than half maybe?

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

Comment By: Jeffrey Hobbs (hobbs)
Date: 2001-05-03 14:51

Message:
Logged In: YES 
user_id=72656

I think the best is just a simple function for comparing 
double equality to a delta, like so:

/*
 * A comparison function for double values
 */
#define MIN_DBL_VAL		1E-4
#define DOUBLES_EQ(d1, d2)	(fabs((d1) - (d2)) < 
MIN_DBL_VAL)

MIN_DBL_VAL needn't be so small for this case.

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

Comment By: Donal K. Fellows (dkf)
Date: 2000-12-01 06:26

Message:
Well, since the purpose of the comparisons is merely to prevent extraneous calls to the scrollbar code, it should be possible to replace the comparisons with a comparison of the string that would otherwise be handed off to the scrollbar (i.e. to do the sprintf and compare the buffer.)  I'm a little surprised that the effect is as bad as described though, and none of these fixes fills me with glee.

The problem is that the scale of the differences we should ignore is not constant, depending instead upon the number of visual lines in the text widget.  The values being compared can also vary a lot over the range [0,1] with the epsilon value constant during that time (i.e. when you're scrolling the widget up and down) and this means that it is not safe to use tricks like dividing by the sum of the values.  Instead, epsilon needs to depend on the number of visual lines, which is apparently an expensive value to compute.  Urgle!

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=112997&aid=223739&group_id=12997