[Rd] scan() doesn't like '1.#IND'
dtenenba at fhcrc.org
Thu Feb 9 05:36:15 CET 2012
2012/2/8 Duncan Murdoch <murdoch.duncan at gmail.com>:
> On 12-02-08 8:59 PM, Hervé Pagès wrote:
>> Since C++ code compiled with g++ 4.6.3 on Windows (the version included
>> in latest Rtools) now can produce things like '1.#IND' when writing
>> doubles to a file (using the<< operator), I wonder whether scan()
>> shouldn't support those things. Right now (with recent R devel and
>> latest Rtools) we get errors like:
>> Error in scan(file, what, nmax, sep, dec, quote, skip, nlines,
>> na.strings, :
>> scan() expected 'a real', got '-1.#IND'
>> that we didn't get with previous versions of R devel and Rtools.
>> for the details. (Note that the file containing the numeric values
>> is generated during the creation of the vignette.)
>> We don't see this error on Linux or Mac because on those platforms
>> the C++ code will produce 'nan' or 'inf', which are supported by
> Is that a bug in the C++ run-time, or is there a legitimate reason to
> produce 1.#IND?
I don't think it's a bug; it's just a different way of saying what
earlier versions of g++ said when they generate "inf", namely that the
number is too large to fit in a double. (The MSVC++ compiler has
always used 1.#IND instead of inf, BTW, and now g++ has decided to do
It does probably represent a floating-point exception in C++ code, but
not a bug in the C++ runtime, so IMO it should be handled by scan() in
the same way as 'inf', since the identical code may produce different
error codes on different platforms.
Note also that there are other variations of the code, such as 11.#INF.
for more information.
> If it's a C++ bug it makes more sense to fix it there than in R.
> Duncan Murdoch
> R-devel at r-project.org mailing list
More information about the R-devel