[Rd] c++ code on amd64

[Thomas Lumley]

On Sun, 16 Apr 2006, Prof Brian Ripley wrote:

> You mention 'float' repeatedly.  A %f argument in Rprintf (and printf)
> refers to a _double_.  Given how little you have shown us it has to be
> entirely guesswork, but is cel.GetIntensity(1) perhaps a float?  If so
> what happens is I believe undefined and compiler-specific.  (Normally
> headers force conversions, but not for variable-argument-list functions.)

I don't think so.   The N843 draft of the ISO C standard 
(http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n843.htm) says
in 6.5.2.2
        [#7]  If the expression that denotes the called function has |
        a type that does include  a  prototype,  the  arguments  are
        implicitly  converted,  as if by assignment, to the types of
        the  corresponding  parameters,  taking  the  type  of  each
        parameter  to  be  the  unqualified  version of its declared
        type.   The  ellipsis  notation  in  a  function   prototype
        declarator causes argument type conversion to stop after the
        last declared parameter.  The  default  argument  promotions
        are performed on trailing arguments.

The "default argument promotions" include promoting float to double. This 
is also what comp.lang.c FAQ 12.9 says: the answer begins

   "It's true that printf's %f specifier works with both float and double
    arguments.Due to the ``default argument promotions'' (which apply in
    variable-length argument lists such as printf's, whether or
    not prototypes are in scope), values of type float are promoted to
    double, and  printf therefore sees only doubles.

I assume this applies to Rprintf as well

 	-thomas


>
> On Sun, 16 Apr 2006, Kasper Daniel Hansen wrote:
>
>> Hi
>>
>> Brief synopsis:
>>
>> I am having a rather peculiar problem regarding a C++ library. It
>> seems that functions from this library behave differently when
>> compiled using R as opposed to being compiled directly from the
>> command line. The problem is only seen on the amd64 platform (using
>> gcc 4.0.2) and not on either of Solaris (both 32 bit and 64 bit), Mac
>> OS and Windows.
>>
>> A bit more detail:
>>
>> Basically the c++ library contains a class and methods for parsing
>> text files in specific formats. These files contains integers as well
>> floats.
>>
>> If I write a stand-alone c++ program with a line like
>>
>>   ....
>>   cout << "x: " cel.GetIndexToX(1) << " intensity: " <<
>> cel.GetIntensity(1) << endl;
>>   ....
>>
>> (here cel is pointing to a specific file while GetIndexToX returns an
>> integer (in what is essentially the first row), while GetIntensity
>> returns a float), it works fine: the two numbers are printed to stdout.
>>
>> If I instead embed the code inside R like
>>
>> extern "C" {
>>    ....
>>    Rprintf("x: %d intensity: %f", cel.GetIndexToX(1),
>> cel.GetIntensity(1)):
>>   ...
>> }
>>
>> and do a R CMD INSTALL, I am able to read the integer from the file,
>> but not the float. The float always returns 0.00000. This is very
>> strange considering that the code is basically identical in the two
>> cases (except for the extern part and inclusion of the R header
>> files), and that the integer number is being read perfectly!
>>
>> I would say that the fact that the stand-alone program works is
>> indicating that the C++ library actually works. Further indication
>> that this is the case is the fact that our R package works fine on
>> Mac G4, Solaris and Windows.
>>
>> The only real difference I can see is that the amd64 platform is the
>> only little-endian 64-bit platform.
>>
>> My working hypothesis is that the float is being read and then
>> truncated.
>>
>> I am extremely baffled by this. Do anyone have an idea on where I
>> should start looking?
>>
>> System details:
>>
>> uname -a
>> Linux shadowfax.berkeley.edu 2.6.12-1-amd64-k8-smp #1 SMP Wed Sep 28
>> 02:57:49 CEST 2005 x86_64 GNU/Linux
>>
>> gcc --version
>> gcc (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
>>
>> R is version 2.2.1 build using a standard ./configure, make step.
>>
>>
>> /Kasper
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> -- 
> Brian D. Ripley,                  ripley at stats.ox.ac.uk
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford,             Tel:  +44 1865 272861 (self)
> 1 South Parks Road,                     +44 1865 272866 (PA)
> Oxford OX1 3TG, UK                Fax:  +44 1865 272595
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

Thomas Lumley			Assoc. Professor, Biostatistics
tlumley at u.washington.edu	University of Washington, Seattle