Appeler explicitement return dans une fonction ou non

Question

Il y a quelque temps J'ai été réprimandé par Simon Urbanek de l'équipe centrale de R (je crois) pour recommander à un utilisateur d'appeler explicitement return à la fin d'une fonction (son commentaire a toutefois été supprimé) :

foo = function() {
  return(value)
}

Il a plutôt recommandé :

foo = function() {
  value
}

Probablement dans une situation comme celle-ci, c'est nécessaire :

foo = function() {
 if(a) {
   return(a)
 } else {
   return(b)
 }
}

Son commentaire nous éclaire sur les raisons de ne pas appeler return à moins d'être strictement nécessaire est une bonne chose, mais cela a été supprimé.

Ma question est la suivante : pourquoi ne pas appeler return plus rapide ou meilleur, et donc préférable ?

Answer 1

La question était : Pourquoi ne pas appeler (explicitement) le retour est-il plus rapide ou meilleur, et donc préférable ?

Il n'y a pas de déclaration dans la documentation R faisant une telle supposition.
La page principale ? "fonction" dit :

function( arglist ) expr
return(value)

Est-ce plus rapide sans retour d'appel ?

Ambos function() y return() sont des fonctions primitives et les function() renvoie lui-même la dernière valeur évaluée, même sans inclure return() fonction.

Appel à return() comme .Primitive('return') avec cette dernière valeur comme argument fera le même travail mais nécessite un appel de plus. De sorte que cet appel (souvent) inutile .Primitive('return') peut attirer des ressources supplémentaires. Une mesure simple montre cependant que la différence résultante est très faible et ne peut donc pas être la raison de ne pas utiliser le retour explicite. Le graphique suivant est créé à partir de données sélectionnées de cette façon :

bench_nor2 <- function(x,repeats) { system.time(rep(
# without explicit return
(function(x) vector(length=x,mode="numeric"))(x)
,repeats)) }

bench_ret2 <- function(x,repeats) { system.time(rep(
# with explicit return
(function(x) return(vector(length=x,mode="numeric")))(x)
,repeats)) }

maxlen <- 1000
reps <- 10000
along <- seq(from=1,to=maxlen,by=5)
ret <- sapply(along,FUN=bench_ret2,repeats=reps)
nor <- sapply(along,FUN=bench_nor2,repeats=reps)
res <- data.frame(N=along,ELAPSED_RET=ret["elapsed",],ELAPSED_NOR=nor["elapsed",])

# res object is then visualized
# R version 2.15

L'image ci-dessus peut différer légèrement selon votre plateforme. Sur la base des données mesurées, la taille de l'objet retourné ne fait aucune différence, le nombre de répétitions (même si elles sont mises à l'échelle) ne fait qu'une très petite différence, qui, dans la réalité, avec des données réelles et un algorithme réel, ne pourrait pas être comptée ou rendre votre script plus rapide.

Est-ce mieux sans retour d'appel ?

Return est un bon outil pour concevoir clairement des "feuilles" de code où la routine doit se terminer, sortir de la fonction et retourner la valeur.

# here without calling .Primitive('return')
> (function() {10;20;30;40})()
[1] 40
# here with .Primitive('return')
> (function() {10;20;30;40;return(40)})()
[1] 40
# here return terminates flow
> (function() {10;20;return();30;40})()
NULL
> (function() {10;20;return(25);30;40})()
[1] 25
> 

Cela dépend de la stratégie et du style de programmation du programmeur, il peut utiliser la fonction no return() car elle n'est pas nécessaire.

Les programmeurs de base de R utilisent les deux approches, c'est-à-dire avec et sans return() explicite, comme il est possible de le trouver dans les sources des fonctions de base.

Souvent, seule la fonction return() est utilisée (sans argument), renvoyant NULL dans les cas où il faut arrêter la fonction de manière conditionnelle.

Il n'est pas clair s'il est meilleur ou non car l'utilisateur standard ou l'analyste utilisant R ne peut pas voir la vraie différence.

Mon opinion est que la question devrait être : Y a-t-il un danger à utiliser un retour explicite provenant de l'implémentation de R ?

Ou, peut-être mieux, l'utilisateur qui écrit le code de la fonction devrait toujours demander : Quel est l'effet dans no en utilisant un retour explicite (ou en plaçant l'objet à retourner comme dernière feuille de la branche de code) dans le code de la fonction ?

Answer 2

Si tout le monde est d'accord pour dire que

1. return n'est pas nécessaire à la fin du corps d'une fonction
2. ne pas utiliser return est légèrement plus rapide (selon le test d'@Alan, 4,3 microsecondes contre 5,1)

devrions-nous tous arrêter d'utiliser return à la fin d'une fonction ? Je ne le ferai certainement pas, et j'aimerais expliquer pourquoi. J'espère savoir si d'autres personnes partagent mon opinion. Et je m'excuse si ce n'est pas une réponse directe à l'OP, mais plutôt un long commentaire subjectif.

Le principal problème que je rencontre en n'utilisant pas return est que, comme Paul l'a souligné, il y a d'autres endroits dans le corps d'une fonction où vous pouvez en avoir besoin. Et si vous êtes obligé d'utiliser return quelque part au milieu de votre fonction, pourquoi ne pas faire en sorte que tout return déclarations explicites ? Je déteste être incohérent. Je pense aussi que le code se lit mieux ; on peut parcourir la fonction et voir facilement tous les points de sortie et les valeurs.

Paul a utilisé cet exemple :

foo = function() {
 if(a) {
   return(a)
 } else {
   return(b)
 }
}

Malheureusement, on pourrait faire remarquer qu'il peut facilement être réécrit comme :

foo = function() {
 if(a) {
   output <- a
 } else {
   output <- b
 }
output
}

Cette dernière version est même conforme à certaines normes de codage de programmation qui préconisent une déclaration de retour par fonction. Je pense qu'un meilleur exemple aurait pu être :

bar <- function() {
   while (a) {
      do_stuff
      for (b) {
         do_stuff
         if (c) return(1)
         for (d) {
            do_stuff
            if (e) return(2)
         }
      }
   }
   return(3)
}

Cela serait beaucoup plus difficile à réécrire en utilisant une seule déclaration de retour : il faudrait plusieurs déclarations de retour. break et un système complexe de variables booléennes pour les propager. Tout cela pour dire que la règle du retour unique ne fonctionne pas bien avec R. Donc, si vous avez besoin d'utiliser la fonction return à certains endroits du corps de votre fonction, pourquoi ne pas être cohérent et l'utiliser partout ?

Je ne pense pas que l'argument de la vitesse soit valable. Une différence de 0,8 microseconde n'est rien quand on commence à regarder les fonctions qui font vraiment quelque chose. La dernière chose que je vois, c'est qu'il faut moins taper, mais bon, je ne suis pas paresseux.

Answer 3

Il s'agit d'une discussion intéressante. Je pense que l'exemple de @flodel est excellent. Cependant, je pense qu'il illustre mon point de vue (et @koshke le mentionne dans un commentaire) selon lequel return a un sens lorsque vous utilisez un impératif au lieu d'un fonctionnel style de codage .

Je ne veux pas insister sur le point, mais j'aurais réécrit foo comme ça :

foo = function() ifelse(a,a,b)

Un style fonctionnel évite les changements d'état, comme le stockage de la valeur de output . Dans ce style, return n'est pas à sa place ; foo ressemble plus à une fonction mathématique.

Je suis d'accord avec @flodel : l'utilisation d'un système complexe de variables booléennes en bar serait moins claire, et inutile lorsque vous avez return . Ce qui fait bar si favorable à return est qu'il est écrit dans un style impératif. En effet, les variables booléennes représentent les changements d'"état" évités dans un style fonctionnel.

Il est vraiment difficile de réécrire bar en style fonctionnel, parce que c'est juste du pseudocode, mais l'idée est quelque chose comme ça :

e_func <- function() do_stuff
d_func <- function() ifelse(any(sapply(seq(d),e_func)),2,3)
b_func <- function() {
  do_stuff
  ifelse(c,1,sapply(seq(b),d_func))
}

bar <- function () {
   do_stuff
   sapply(seq(a),b_func) # Not exactly correct, but illustrates the idea.
}

El while serait la plus difficile à réécrire, parce qu'elle est contrôlée par les changements d'état de la boucle a .

La perte de vitesse causée par un appel à return est négligeable, mais l'efficacité gagnée en évitant return et la réécriture dans un style fonctionnel est souvent énorme. Dire aux nouveaux utilisateurs d'arrêter d'utiliser return ne sera probablement pas utile, mais les guider vers un style fonctionnel sera payant.

---

@Paul return est nécessaire dans le style impératif parce que vous voulez souvent quitter la fonction à différents points d'une boucle. Un style fonctionnel n'utilise pas de boucles, et n'a donc pas besoin de return . Dans un style purement fonctionnel, l'appel final est presque toujours la valeur de retour souhaitée.

En Python, les fonctions nécessitent un return déclaration. Toutefois, si vous avez programmé votre fonction dans un style fonctionnel, vous n'aurez probablement qu'une seule instruction return déclaration : à la fin de votre fonction.

En utilisant un exemple tiré d'un autre billet de StackOverflow, disons que nous voulons une fonction qui renvoie TRUE si toutes les valeurs d'un x avait une longueur étrange. On pourrait utiliser deux styles :

# Procedural / Imperative
allOdd = function(x) {
  for (i in x) if (length(i) %% 2 == 0) return (FALSE)
  return (TRUE)
}

# Functional
allOdd = function(x) 
  all(length(x) %% 2 == 1)

Dans un style fonctionnel, la valeur à retourner tombe naturellement aux extrémités de la fonction. Là encore, cela ressemble davantage à une fonction mathématique.

@GSee Les avertissements soulignés dans ?ifelse sont certainement intéressants, mais je ne pense pas qu'ils essaient de dissuader l'utilisation de la fonction. En fait, ifelse a l'avantage de vectoriser automatiquement les fonctions. Par exemple, considérons une version légèrement modifiée de foo :

foo = function(a) { # Note that it now has an argument
 if(a) {
   return(a)
 } else {
   return(b)
 }
}

Cette fonction fonctionne bien lorsque length(a) est 1. Mais si vous réécrivez foo avec un ifelse

foo = function (a) ifelse(a,a,b)

Maintenant foo fonctionne sur toute longueur de a . En fait, ça marcherait même quand a est une matrice. En retournant une valeur de la même forme que test est une fonctionnalité qui aide à la vectorisation, pas un problème.

Answer 4

Il semble que sans return() c'est plus rapide...

library(rbenchmark)
x <- 1
foo <- function(value) {
  return(value)
}
fuu <- function(value) {
  value
}
benchmark(foo(x),fuu(x),replications=1e7)
    test replications elapsed relative user.self sys.self user.child sys.child
1 foo(x)     10000000   51.36 1.185322     51.11     0.11          0         0
2 fuu(x)     10000000   43.33 1.000000     42.97     0.05          0         0

____ EDIT __ _ __ _ __ _ __ _ __ _ ___

Je procède à d'autres repères ( benchmark(fuu(x),foo(x),replications=1e7) ) et le résultat est inversé... Je vais essayer sur un serveur.

Answer 5

Un problème lié au fait de ne pas mettre explicitement "return" à la fin est que si l'on ajoute des déclarations supplémentaires à la fin de la méthode, la valeur de retour est soudainement fausse :

foo <- function() {
    dosomething()
}

Cela renvoie la valeur de dosomething() .

Maintenant, nous arrivons le lendemain et ajoutons une nouvelle ligne :

foo <- function() {
    dosomething()
    dosomething2()
}

Nous voulions que notre code renvoie la valeur de dosomething() mais ce n'est plus le cas.

Avec un retour explicite, cela devient vraiment évident :

foo <- function() {
    return( dosomething() )
    dosomething2()
}

Nous pouvons voir qu'il y a quelque chose d'étrange dans ce code, et le corriger :

foo <- function() {
    dosomething2()
    return( dosomething() )
}