R devel - Feb 2012 - scan() doesn't like '1.#IND'

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().

Thanks,
H.

-- 
Herv? Pag?s

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319

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