Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-761471 ] INST_EQ issues with NaN
|
From: SourceForge.net <no...@so...> - 2004-11-05 16:39:03
|
Bugs item #761471, was opened at 2003-06-26 18:45 Message generated for change (Comment added) made by msofer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=761471&group_id=10894 Category: 46. Bytecode Compiler Group: obsolete: 8.4.3 Status: Open Resolution: None Priority: 5 Submitted By: Don Porter (dgp) Assigned to: miguel sofer (msofer) Summary: INST_EQ issues with NaN Initial Comment: This is inconsistent: % set x NaN; expr {$x == NaN} 1 % expr {$x == NaN} 0 They are different because the first case follows an optimization in INST_EQ that a Tcl_Obj will be == to itself. The second case actually flows through to a C-level comparison of two NaN doubles, and at least on this platform, the result is false. ---------------------------------------------------------------------- >Comment By: miguel sofer (msofer) Date: 2004-11-05 13:39 Message: Logged In: YES user_id=148712 Can we then, for VC only, #define IS_NAN(x) _isnan(x) in tclExecute.c and have this stuff fixed? ---------------------------------------------------------------------- Comment By: Kevin B KENNY (kennykb) Date: 2004-11-05 13:34 Message: Logged In: YES user_id=99768 Ugh. I just looked this one up. VC++6 is not IEEE-754 compliant with respect to NaN comparisons. (I disassembled the object code - and verified this. It simply doesn't check for "unordered" in the result word. VC.NET allegedly fixes this - see for example http://msdn.microsoft.com/library/en-us/dndeepc/html/deep05282002.asp Where does that leave us? We probably need to do explicit tests for the "special values" when compiling on VC++6. There are tests available in <float.h>: _finite(x) - Returns TRUE for ordinary and subnormal values, FALSE for Inf and NaN _isnan(x) - Returns TRUE for NaN, FALSE for everything else. _fpclass(x) - Returns a value that classifies a given FP number. See http://msdn.microsoft.com/library/en-us/vccore98/HTML/_crt__fpclass.asp for the constants. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2004-11-05 06:32 Message: Logged In: YES user_id=148712 Note that thismeans that NaN handling in Tcl/VC has been broken for a while - our detection is done by the IS_NAN macro in tclExecute.c, which tests for exactly this. Just wild guessing here - maybe there is some compilation flag required to get proper IEEE handling, disabled by default 'cause it gets slower? One possible solution would be to #define IS_NAN conditionally on the compiler being used. Maybe there is an equivalent function in VC that could be called? Worst case - if the VC bug is unfixable, we should either disable the test on that platform, or maybe pay a heavy cost in double handling and try detecting NaN on the double's string rep? Assigning to Kevin as our resident VC guru ... ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2004-11-05 06:10 Message: Logged In: YES user_id=79902 This is a bug in VC's floating-point number handling. ---------------------------------------------------------------------- Comment By: Daniel South (wildcard_25) Date: 2004-11-04 23:07 Message: Logged In: YES user_id=596509 Tk: v8.5a2 OS: WinXPsp2 Head: 04-11-04 Built with makefile.vc using VC7.1 ==== expr-22.9 non-numeric floats: shared object equality and NaN FAILED ==== Contents of test case: set x NaN expr {$x == $x} ---- Result was: 1 ---- Result should have been (exact matching): 0 ==== expr-22.9 FAILED ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2004-11-02 12:47 Message: Logged In: YES user_id=79902 Great. That gives virtually the original functionality and yet gets the NaN nasty right. :^) Fixed in HEAD and 8.4 branch. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2004-11-01 16:34 Message: Logged In: YES user_id=148712 Patch replaced with a better one. NaN stuff is OK (shortcut gives the same as glibc, howzzat for a criterion?). Don't know about other "funny" values like Inf, -0, ... ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2004-11-01 13:38 Message: Logged In: YES user_id=148712 Attaching a patch with my optimisation: it does seem to work. At least % set x NaN; expr {$x == NaN} 0 ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2004-11-01 11:42 Message: Logged In: YES user_id=79902 Your optimization won't work. You simply can't rely on NaN being of tclDoubleType and the cost of determining the cases where the comparison is actually safe is rather too high. :^( At least in the equal object case, any through-string conversions will be mostly cached... :^/ Fixed in HEAD; backport candidate or shall we not bother given how few people noticed this was broken for so many years? ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2004-11-01 09:28 Message: Logged In: YES user_id=148712 Suggestion for change at INST_EQ and family: * Try first the conversion of valuePtr to numeric type (DEOPT) * Shortcut: if ((valuePtr == value2Ptr) && (t1Ptr != &tclDoubleType)) { ... shortcut; jump to end } else if (valuePtr != value2Ptr) { ... convert value2Ptr } ... This retains the shortcut for non-doubles, and forces doubles to go through the C library. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2004-11-01 08:21 Message: Logged In: YES user_id=79902 NaN is the only value that is not equal to itself, but it's non-trivial to write a special test for it. I believe we just have to deoptimize INST_EQ (though this will marginally shorten TEBC of course.) ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2004-10-30 16:47 Message: Logged In: YES user_id=148712 I did not get it, did I? Sorry ... ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2004-10-30 16:44 Message: Logged In: YES user_id=148712 uhh - no, it can't be list type - it will have been converted to a double, as == attempts numeric conversion first. So the problem may well be that Tcl_GetDoubleFromObj is not handling NaN correctly? Is the following correct % expr double(NaN) domain error: argument not in valid range or should the return value be NaN? ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2004-10-21 20:21 Message: Logged In: YES user_id=79902 NaN is tclDoubleType (or non-numeric; could be a list just fine!) AFAICT, the only way to avoid the problem is to remove the equal-object check from the top of the INST_EQ implementation. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2004-03-29 18:39 Message: Logged In: YES user_id=148712 Is there any other exception to this? Ie, other possibility of a Tcl_Obj not being == to itself? If not, it coud be handled as a special case. What objtype is NaN? ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2004-03-29 18:06 Message: Logged In: YES user_id=79902 Arguably, the solution is to only do the object comparison when not doing numeric comparison. But figuring out which kind of comparison to do could be expensive. Ick. Looks like we'll need to deoptimise... :-( ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2003-06-27 05:38 Message: Logged In: YES user_id=79902 Another case: % set x NaN; expr {$x == $x} 1 This case is *definitely* the INST_EQ opt. The other case in the bug report mixes it up with aggressive literal sharing. (Just a note that the C-level comparison result is correct; we don't want to put in special code to make NaN equal to itself!) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=761471&group_id=10894 |