Bonnes pratiques pour l'insertion de code C (sources R) dans un package

Postez ici vos questions, réponses, commentaires ou suggestions - Les sujets seront ultérieurement répartis dans les archives par les modérateurs

Modérateur : Groupe des modérateurs

Geoffroy Berthelot
Messages : 1
Enregistré le : 25 Avr 2024, 12:58

Bonnes pratiques pour l'insertion de code C (sources R) dans un package

Messagepar Geoffroy Berthelot » 02 Mai 2024, 09:35

Bonjour à toutes et à tous,

Je m'excuse pour ce titre à rallonge, mais je n'ai pas trouvé plus synthétique pour décrire notre demande.
Avec un collègue nous réalisons notre premier package R (je précise que je suis moi-même un très grand débutant en R), et nous nous posons des questions sur les bonnes pratiques liées à l'inclusion de code C dans notre package.
Plus précisément, lors de la compilation de notre package, nous avons 2 warnings qui se lèvent:

Code : Tout sélectionner

checking dependencies in R code ... WARNING
  Dépendance d'espace de nom dans le champ Imports non importé depuis : ‘grDevices’
    All declared Imports should be used.
  Objets non exportés importés par appels ':::' :
    ‘stats:::C_Cdqrls’ ‘stats:::C_influence’
    See the note in ?`:::` about the use of this operator.
    Including base/recommended package(s):
    ‘stats’
 
❯ checking foreign function calls ... WARNING
  Foreign function calls to a base package:
    .Call(stats:::C_Cdqrls, ...)
    .Call(stats:::C_influence, ...)
  Packages should not make .C/.Call/.External/.Fortran calls to a base
  package. They are not part of the API, for use only by R itself and
  subject to change without notice.


Et qui sont tout à fait compréhensibles: nous appelons les deux fonctions ‘stats:::C_Cdqrls’ et ‘stats:::C_influence’ pour des raisons de performance (nous effectuons un très grand nombre de régressions, de l'ordre du million ou du milliard) et on peut imaginer que ces fonctions, qui sont toutes deux des fonctions du code source de R, puissent être amenées à changer dans des versions ultérieures. Nous comprenons qu'il faut les inclure dans le package sous un répertoire src/ qui contiendra ces 2 fonctions C avec les fichiers headers (.h) associés. Mais nous ne savons pas jusqu'à quel niveau nous devons inclure les fonctions C dans notre package, car elles font elles-mêmes appel à d'autres types ou fonctions C définies ailleurs.

Nos questions sont les suivantes:
(1) Au delà de ces 2 fonctions 'stats:::C_Cdqrls' (lm.c) 'stats:::C_influence' (influence.c), quelles fonctions doivent être incluses dans notre package dans le répertoire /src ? Par exemple, la fonction 'C_Cdqrls()' appelle les fonctions 'coerceVector()', 'mkNamed()', 'asReal()', etc. Devons-nous également inclure toutes ces fonctions et leur dépendances ? Quelles sont les recommandations ? Une recherche sur le net ne nous a pas permis d'en savoir plus. Existe-t'il un package R qui permettrait d'inclure toutes les dépendances et les fichiers concernés d'un seul coup (j'imagine que ca peut-être source d'erreur de le faire à la main).

(2) Nous pourrons ainsi produire un package au format 'source' contenant les fichiers R d'un coté, et ces fichiers dans notre répertoire /src. Nous voyons également que d'autres binaries sont proposées (Windows, MacOS) dans les packages mis à dispositions sur le CRAN. Devons nous également compiler nos fichiers C et proposer différentes binaries lors du dépôt de notre package? Existe-t'il des packages R qui permettrait de réaliser ceci, comme Rtools() devtools()?

Un grand merci pour les conseils que vous pourrez nous apporter!

Retourner vers « Questions en cours »

Qui est en ligne

Utilisateurs parcourant ce forum : Google [Bot] et 1 invité