Skip to content

[Rcpp-devel] Using complex numbers in a C program called by R

8 messages · Baptiste Auguie, Dirk Eddelbuettel, Pierre Lafaye de Micheaux

Original
Pierre Lafaye de Micheaux
# 
Dear all,

This email comes after a discussion on the R-pkg-devel mailing list:
https://stat.ethz.ch/pipermail/r-package-devel/2016q1/000627.html

My purpose was to be able, in two of my packages, to use complex numbers 
(create some, addition, multiplication, division, modulus, etc)
directly in a C code that is called from R (using the .C interface).
Note that these complex numbers might not come from R but could be 
created and used directly in my C code, that will then output (via 
pointers)
real (I mean double) values back to R (via the .C interface). I could 
also send from R these complex numbers via the .C interface.

A very simple example of such a function called from R via the .C 
interface could be the following:

#include <R.h>
#include "Rmath.h"
extern "C" {
void Cfunc(complex double *var) {
     double _Complex z = 1.0 + 2.0 * _Complex_I;
     var[0] = z + exp(var[0]);
return;
}}

I could call this function from R as follows:
.C(1i)

No problem so far when I use such a function in a package that is 
compiled under Linux. But this will not work under windows (see the 
discussion
on the R-pkg-devel list). So what I did to make everything work under 
Windows also was to include in the src/ directory of my package the 
source files
from the RcppFaddeeva package. Then I would modify the function above as 
follows:

#include <R.h>
#include "Rmath.h"
#include "libraries/callFaddeeva.cpp"
#include "libraries/Faddeeva.cpp"
#include "libraries/RcppExports.cpp"
extern "C" {
void Cfunc(complex double *var) {
     cmplx z = C(1.0, 2.0);
     var[0] = z + cexp(var[0]);
return;
}}

Maybe there is a way not to include all the Faddeeva source files in my 
packages? But I do not know how to do it.

Best regards,

Pierre L.
Baptiste Auguie
# 
Hi,

Just to clarify: did you include files from RcppFaddeeva because you need
some of its functionality (special complex error functions), or was it only
a workaround to get access to complex numbers? In the latter case, I
recommend you try making a minimal Rcpp package to see how easy it is to
interface with C+ functions, and that way you will only have relevant
header files included.

Best,

baptiste



On 4 January 2016 at 09:36, Pierre Lafaye de Micheaux <
lafaye at dms.umontreal.ca> wrote:

            

      
      
      
    

        

      
      
    

        
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20160104/f6e8d0f4/attachment.html>

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 4 January 2016 at 09:50, Baptiste Auguie wrote:

        
| Hi,
| 
| Just to clarify: did you include files from RcppFaddeeva because you need some
| of its functionality (special complex error functions), or was it only a
| workaround to get access to complex numbers? In the latter case, I recommend
| you try making a minimal Rcpp package to see how easy it is to interface with
| C++ functions, and that way you will only have relevant header files included.

+1

I already responded to Pierre's initial emails in November and tried then to
explain to him that that .C() is a _really bad idea at this point in time.

It is two months later and nothing has changed.

So here is a quick illustration of what Baptiste meant. All it takes is

   library(Rcpp)    # no other depends

and then (and I even got this right on first try):

   R> cppFunction("Rcomplex addTwo(Rcomplex x, Rcomplex y) {return x + y; }")
   R> addTwo(2+2i, 3+3i)
   [1] 5+5i
   R> 

With one invocation of cppFunction() I created an ad-hoc compiled function
(technically compiled as C++ but you can call this C as well) which adds two
complex number -- one of Pierre's request as per the email below.  And low
and behold is just does that.

So yes -- maybe time to learn some Rcpp, maybe forget about .C() and simply
get on with this and other other things.

Dirk

| 
| Best,
| 
| baptiste
| 
| 
| 
| On 4 January 2016 at 09:36, Pierre Lafaye de Micheaux <lafaye at dms.umontreal.ca>

        
| wrote:

        
| 
|     Dear all,
| 
|     This email comes after a discussion on the R-pkg-devel mailing list:
|     https://stat.ethz.ch/pipermail/r-package-devel/2016q1/000627.html
| 
|     My purpose was to be able, in two of my packages, to use complex numbers
|     (create some, addition, multiplication, division, modulus, etc)
|     directly in a C code that is called from R (using the .C interface).
|     Note that these complex numbers might not come from R but could be created
|     and used directly in my C code, that will then output (via pointers)
|     real (I mean double) values back to R (via the .C interface). I could also
|     send from R these complex numbers via the .C interface.
| 
|     A very simple example of such a function called from R via the .C interface
|     could be the following:
| 
|     #include <R.h>
|     #include "Rmath.h"
|     extern "C" {
|     void Cfunc(complex double *var) {
|     ? ? double _Complex z = 1.0 + 2.0 * _Complex_I;
|     ? ? var[0] = z + exp(var[0]);
|     return;
|     }}
| 
|     I could call this function from R as follows:
|     .C(1i)
| 
|     No problem so far when I use such a function in a package that is compiled
|     under Linux. But this will not work under windows (see the discussion
|     on the R-pkg-devel list). So what I did to make everything work under
|     Windows also was to include in the src/ directory of my package the source
|     files
|     from the RcppFaddeeva package. Then I would modify the function above as
|     follows:
| 
|     #include <R.h>
|     #include "Rmath.h"
|     #include "libraries/callFaddeeva.cpp"
|     #include "libraries/Faddeeva.cpp"
|     #include "libraries/RcppExports.cpp"
|     extern "C" {
|     void Cfunc(complex double *var) {
|     ? ? cmplx z = C(1.0, 2.0);
|     ? ? var[0] = z + cexp(var[0]);
|     return;
|     }}
| 
|     Maybe there is a way not to include all the Faddeeva source files in my
|     packages? But I do not know how to do it.
| 
|     Best regards,
| 
|     Pierre L.
| 
| 
| 
|     --
|     Pierre Lafaye de Micheaux
| 
|     Adresse courrier:
|     Universit? de Montr?al
|     Pavillon Andr?-Aisenstadt
|     D?partement de Math?matiques et Statistique
|     CP 6128 Succursale Centre-ville
|     Montr?al Qc H3C 3J7
|     CANADA
| 
|     Adresse physique:
|     D?partement de Math?matiques et Statistique
|     Bureau 4249, Pavillon Andr?-Aisenstadt
|     2920, chemin de la Tour
|     Montr?al, Qu?bec H3T 1J4
|     CANADA
| 
|     T?l.: (00-1) 514-343-6607 / Fax: (00-1) 514-343-5700
|     lafaye at dms.umontreal.ca
|     http://www.biostatisticien.eu
| 
|     _______________________________________________
|     Rcpp-devel mailing list
|     Rcpp-devel at lists.r-forge.r-project.org
|     https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
| 
| 
| _______________________________________________
| Rcpp-devel mailing list
| Rcpp-devel at lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Pierre Lafaye de Micheaux
    

    

      
      #
    

  


  

      
Dear all,

Thanks again for your answers.

For one of my project, I indeed need the special complex error 
functions. This is why I used the RcppFaddeeva source files in the first 
time.
This being said, it was ALSO a workaround to get access to complex 
numbers operations (and so that the package compile under Windows
without errors).

I know that using .C() is now discouraged by R core group. This being 
said, I am a bit reluctant, at least for some projects, to use .Call().
I like the idea to be able to use old FORTRAN77 codes and/or C codes 
written by others. Usually, using these codes is quite straightforward
thanks to the .Fortran() interface. As for the C codes, it is only 
necessary to modify the arguments of the C function to make them 
pointers in
order to then call it through the .C() function.

My understanding, but maybe I am not good enough, is that to be able to 
call a C/C++ function using .Call() and/or involving Rcpp needs
a lot more modifications to the original C source file.

I think this is bad for reproducibility. For example, if one would like 
to call this same C code from Matlab and if this C code is full of Rcpp, 
then
I guess there will be some trouble. Am I right?

Note that I "learned" a bit of Rcpp. I am the author and maintainer of 
package PoweR:
https://cran.r-project.org/web/packages/PoweR/index.html
I wrote in this package the file calcpuissRcpp.cpp that contains some 
Rcpp features (maybe you can have a quick look to see my low? level
of knowledge of Rcpp). And I agree that this is cool stuff when you want 
to be able to access high level
R functions from C. But as said above, you loose some reproducibility 
(in the sense explained above) and maybe also some speed (and this is why I
have two "parallel" versions in my PoweR package: calcpuiss.cpp and 
calcpuissRcpp.cpp).

So, with all this in mind, my "request" is still the same. Namely being 
able to manipulate (and create) complex numbers at the (pure) C level in 
an R package so that it could compile properly (without errors) under 
Microsoft Windows. I found this workaround by copying these RcppFaddeeva 
source files
(.cpp and .h files) in the src/ directory of my package(s) but this is 
not really clean. Probably I could try to remove all "unnecessary" stuff 
from these source
files in order to keep only what is really needed to play with complex 
numbers at the (pure) C level, but maybe there would be something more
clever to do? Like adding RcppFaddeeva to the LinkingTo/Depends/Export 
fields? Or creating a very simple package (by removing all special 
complex error
functions from RcppFaddeeva) and call the resulting package EnableC and 
then add this to LinkingTo/Depends/Export fields?

I hope I made myself clear ...

Thank you again for your time.

Best regards,

Pierre L.

Le 03/01/2016 22:14, Dirk Eddelbuettel a ?crit :

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Baptiste Auguie
    

    

      
      #
    

  


  

      
On 4 January 2016 at 21:14, Pierre Lafaye de Micheaux <

        
lafaye at dms.umontreal.ca> wrote:

        

            

      
      
      
    

        
That's useful to know. In that case, I believe something could be done but
I'd need some help from Dirk to make sure the package export the right
things.
https://github.com/baptiste/rcppfaddeeva/pull/2#issuecomment-109682706

            

      
      
      
    

        
This workaround is clearly suboptimal and needs to be sorted first IMHO.
I'm guessing that's a magic side-effect of the Rcpp.h include in one of the
files.

            

      
      
      
    

        
If you look at RcppFaddeeva, you'll find that the original C+ library is
pretty much untouched, and the c++ wrappers are quite minimal. And with
Rcpp attributes, you don't even have to write R wrappers.

I think this is bad for reproducibility. For example, if one would like to

            

      
      
      
    

        
I believe this step (to use some of Faddeeva's functions) needs some work
in RcppFaddeeva, which I'd be happy to discuss with you and hopefully Dirk,
but that's a different issue altogether.

Or creating a very simple package (by removing all special complex error

            

      
      
      
    

        
Sounds like a good idea to me. And if you put it on github, say, people
could look at it if you get stuck. As I remember, Dirk fixed my
RcppFaddeeva package faster than I was committing to it.

HTH,

baptiste

and call the resulting package EnableC and then add this to

            

      
      
      
    

        
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20160104/a6a1056b/attachment.html>

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
Baptiste,

You and I started RcppFaddeeva following this thread of yours on SO
   http://stackoverflow.com/a/30677939/143305
where you had basic troubles creating an R package.  So that got solved, and
RcppFaddeeva is on CRAN etc.

We never set it up to export headers. Doing so is trivial, but that is work
at your end. I can't commit to this now due to other obligations. Minimally
this involves simply creating inst/include/ to contain the headers, and
telling your src/Makevars{,.win} about it via PKG_CXXFLAGS=-I../inst/include

Then other packages can use LnkingTo: to get the headers.  Now, getting C(++)
code that needs linking is another ball game but I also cover that in a few
pairs of packages.  RApiSerialize and RcppRedis is one.

If and when you (or Pierre) identify an actual reproducible bug in Rcpp.h let
me know, and I'll take it on.  Otherwise I stay out of this. From what I can
tell Pierre is simply stuck in ways that are discouraged but insists on them
anyway.  Which is his choice, but it also not something I need to spend my
time helping him on.

Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Pierre Lafaye de Micheaux
    

    

      
      #
    

  


  

      
Dear Dirk,

I understand that you do not want to spend too much time on this.
And I thank you for the time you already spent fr this specific 
question, and also on others in the past.

As far as I am concerned, I was just trying, spending as less time as 
possible, to make two of my packages work (i.e., compile)
for Microsoft Windows (I work under Ubuntu or Debian). I found a (not 
clean) workaround to it using the RcppFaddeeva source files.
When I will have time (and I also have tons of other obligations), I 
will try to simplify my approach. But for now, it is working, so it 
satisfies me.
At this point, my time is better employed in developing the statistical 
tools and theory than on R/C technicalities.

My comment about reproducibility was not to mention a bug in Rcpp, which 
is really a great tool. It was more about the fact that I tried to make 
(parts of) my code as reusable as possible.
And I feel (with what I know about Rcpp now and how it can interact with 
R, or with what I know about .Call()) that this is possible in a simple 
way with .C().

Have a nice day and a happy new year.

Pierre L.

Le 04/01/2016 13:25, Dirk Eddelbuettel a ?crit :

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 4 January 2016 at 14:21, Pierre Lafaye de Micheaux wrote:

        
| R, or with what I know about .Call()) that this is possible in a simple 
| way with .C().

Please stop abusing this Rcpp mailing list a platform for youe .C() gospel.

Every single developer whose opinion I value has come out swinging on this:

      DO NOT USE .C() IN NEW CODE.

So that is the ground rule here.

If you have Rcpp questions, or even something reproducible, we'd be all ears.
For what it is worth there are other packages uses complex data types on all
platforms (yes, including Windows) so I still think your wounds are
self-inflecting by your own choosing.  But we have a big tent approach:
please do feel free to use whatever tools you like.  But please do no waste
our time her with whatever you think you have to say about .C() or other
non-Rcpp topics.  Maybe r-devel, maybe r-package-devel though both will
probably tell you to smarten up.  Maybe time to create your own list.

Sorry to sound harsh but there is only so much time in each day. And a
minuute spent on .C() is a minute wasted.

Cheers, and good luck.

Dirk