Donald G Porter wrote:
>  The trouble I have with that is this code example:
>  
>      objPtr = Tcl_NewDoubleObj(d1);
>      code = Tcl_GetDoubleFromObj(interp, objPtr, &d2);
>      
>  In all Tcl 8 releases up to now, a programmer could rely on code now
>  having the value TCL_OK, and the variable d2 holding a copy of the
>  variable d1.
[... but in 8.5, a NaN will result in TCL_ERROR ...]

OK. Here's what I understand about it.

Certainly a conscious decision was made to allow for "quiet
infinities;" that is, the IEEE-754 values +Inf and -Inf were
to be allowed as if they were ordinary floating point numbers.
In the discussion of the TIP, I posted several typical examples
where infinities were benign - generally because they appeared
in the denominator of some fraction - and demonstrated that
the code to guard against such cases is an atrocious amount
of work, particularly since in the cases that I found interesting,
any IEEE-754 compliant hardware is already doing The Right Thing.

NaN is a thornier issue.  While infinities are often (even
usually) benign, NaN generally indicates something gone seriously
amiss in a calculation.  NaN also propagates; a common result
of an arithmetic problem is that there are NaN's all over the
results.  In order to make numeric catastrophes easier to debug,
we decided to make NaN "fail early," that is, return TCL_ERROR
as soon as practicable.

Tcl_NewDoubleObj, obviously, cannot cause a Tcl error since
it does not have a Tcl interpreter to return it in, so we do
have to deal with Tcl objects containing NaN.  Moreover, since
such objects can arise by [binary scan]ning numbers from an
external medium, it seemed wise at least to allow them to pass
through Tcl unchanged, so [binary format] also allows NaN.
NaN is forbidden as an argument to or result from [expr];
the associated error message is "floating point value is
Not a Number".

During the early discussions of TIP 132, the issue was raised
that checking in [expr] does not suffice, because extensions
(including Tk) could also get unexpected NaN's if somehow
the string "NaN" or one of its variants were to reach
Tcl_GetDoubleFromObj (which prior to 8.5, rejected NaN's
entirely).  For this reason, what we wound up settling on
was:
    - Tcl_GetDoubleFromObj returns TCL_ERROR on NaN.
    - In the specific case of NaN, Tcl_GetDoubleFromObj will
      still convert the number, leaving objPtr-> typePtr
      as &tclDoubleObj and placing the (NaN) value is
      objPtr-> doubleValue

An extension that is prepared to handle NaNs gracefully
can check this case with a few lines of code - the way,
for instance, that the 'FormatNumber' function in tclBinary.c
does.

This was thought to have been the best of both worlds -
not inflicting NaN's (and possible nasal demons) on extensions
that aren't prepared to deal with them, while allowing
extensions that are willing to accept NaNs the ability to
scan them with a simple additional check.

-- 
73 de ke9tv/2, Kevin



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core