From murdoch.duncan at gmail.com  Thu Feb  9 05:07:11 2012
From: murdoch.duncan at gmail.com (Duncan Murdoch)
Date: Wed, 08 Feb 2012 23:07:11 -0500
Subject: [Rd] scan() doesn't like '1.#IND'
In-Reply-To: <4F33287A.3040008@fhcrc.org>
References: <4F33287A.3040008@fhcrc.org>
Message-ID: <4F33466F.2080501@gmail.com>

On 12-02-08 8:59 PM, Herv? Pag?s wrote:
> Hi,
>
> 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.
> See
>
>
> http://bioconductor.org/checkResults/2.10/bioc-LATEST/BGmix/moscato2-buildsrc.html
>
> 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
> scan().

Is that a bug in the C++ run-time, or is there a legitimate reason to 
produce 1.#IND?

If it's a C++ bug it makes more sense to fix it there than in R.

Duncan Murdoch



[Rd] scan() doesn't like '1.#IND'
Duncan Murdoch