From: SourceForge.net <no...@so...> - 2004-10-21 23:21:40
|
Bugs item #761471, was opened at 2003-06-26 22:45 Message generated for change (Comment added) made by dkf 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: Donal K. Fellows (dkf) 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: Donal K. Fellows (dkf) Date: 2004-10-22 00: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 22: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 22: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 09: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 |