FAQ
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

Search Discussions

  • Duncan Murdoch at Feb 9, 2012 at 4:07 am

    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
  • Dan Tenenbaum at Feb 9, 2012 at 4:36 am

    2012/2/8 Duncan Murdoch <murdoch.duncan@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?
    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
    the same).

    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.
    See
    http://stackoverflow.com/questions/347920/what-do-1-inf00-1-ind00-and-1-ind-mean
    and
    http://www.johndcook.com/IEEE_exceptions_in_cpp.html
    for more information.

    Thanks,
    Dan

    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
    https://stat.ethz.ch/mailman/listinfo/r-devel

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupr-devel @
categoriesr
postedFeb 9, '12 at 1:59a
activeFeb 9, '12 at 4:36a
posts3
users3
websiter-project.org
irc#r

People

Translate

site design / logo © 2022 Grokbase