Tcl 8.5 and special numbers
Arjen Markus
with version 8.5 Tcl supports the special IEEE numbers: Not-a-number,
+ and - Infinity,
(perhaps + and - 0?). Fine so far, but I see in a library I use and
help maintain
(PLplot - http://plplot.sourceforge.net) that certain special numbers
(I think NaNs) are
formatted as "-1.#IND".
The problem is a bit convoluted as up to now the Tcl interface to
PLplot is based on the
string-interface (I intend to change that soon ;)): The special
numbers get printed on the C side
as "-1.#IND" (using printf()) and are passed on as such a string. I
see the same string via Tcl's
puts, but that is probably because they were not interpreted as
numbers inbetween.
I would like to know if Tcl 8.5 regards the underlying bit pattern as
NaN or as something
else entirely. Is this one of the nasty platform-dependencies that we
need to watch out
for? I am used to such representations of NaNs as "1.#QNAN" and
various others ...
(My platform: Windows XP, MSVC/C++ 6.0)
Regards,
Arjen
David Gravereaux
> (I think NaNs) are
> formatted as "-1.#IND".
Off hand, I think that one means 'indeterminate form' as in not initialized.
Arjen Markus
Hm, that is a plausible explanation: the numbers come from
an interpolation algorithm that produces gaps when it decides
there are not enough data points close by. I assumed it would
produce NaNs, but an indeterminate number would work as well
(or better).
According to one reference the hexadecimal representation is
FFC00000. Now I should try to reproduce that within Tcl.
Regards,
Arjen
Kevin Kenny
-1.#IND is a Microsoft-Visual-C++-ism. It's one particular bit
pattern of quiet NaN .
Tcl doesn't know how to interpret the strings,
-1.#NAN, -1.#SNAN, -1.#QNAN, -1.#IND or -1.#INF
as numbers. But it'll happily deal with the underlying
bit patterns as NaNs or infinities as appropriate.
It'll also format gradual underflows correctly, unlike
the MS libraries.
So you've nothing to worry about unless you use sprintf to
format the number and then try to use that string in Tcl.
Alas, it sounds as if that's exactly what you're doing.
In that case, the only one that should really cause trouble
is INF, since the NaNs all error out early in most cases.
I suppose that, if there is enough demand, we could add
this Microsoft-ism to TclParseNumber, but I'm really reluctant
to do so. As far as I know, you're the first to ask.
--
73 de ke9tv/2, Kevin
Kevin Kenny
> Hm, that is a plausible explanation: the numbers come from
> an interpolation algorithm that produces gaps when it decides
> there are not enough data points close by. I assumed it would
> produce NaNs, but an indeterminate number would work as well
> (or better).
>
> According to one reference the hexadecimal representation is
> FFC00000. Now I should try to reproduce that within Tcl.
FFC00000 is a NaN with the sign bit on:
% binary scan \x00\x00\xC0\xFF r x
1
% set x
-NaN
Arjen Markus
>
> Tcl doesn't know how to interpret the strings,
> -1.#NAN, -1.#SNAN, -1.#QNAN, -1.#IND or -1.#INF
> as numbers. But it'll happily deal with the underlying
> bit patterns as NaNs or infinities as appropriate.
> It'll also format gradual underflows correctly, unlike
> the MS libraries.
>
> So you've nothing to worry about unless you use sprintf to
> format the number and then try to use that string in Tcl.
> Alas, it sounds as if that's exactly what you're doing.
>
Yes, right now the Tcl interface to PLplot is based on the
old string-passing method. It is okay for some tasks, but it
turns out to be slow when dealing with large amounts of
numbers (setting up a matrix of data for contour plots
for instance). And it is definitely not okay for this type
of things.
Like I said, I want to change that to the Tcl_Obj method.
> In that case, the only one that should really cause trouble
> is INF, since the NaNs all error out early in most cases.
> I suppose that, if there is enough demand, we could add
> this Microsoft-ism to TclParseNumber, but I'm really reluctant
> to do so. As far as I know, you're the first to ask.
>
I am not asking for that: the MicroSoft compilers do it one way
and another vendor will have a slightly different format. There
will almost be no end to thee variation!
Dealing with these special numbers in this type of information
exchange is something I still need to learn.
Regards,
Arjen