Comment savoir quand utiliser le pli à gauche et quand utiliser le pli à droite?

Je suis conscient que le pli à gauche produit des arbres penchés à gauche et le pli à droite produit des arbres penchés à droite, mais lorsque j'atteins un pli, je me retrouve parfois enlisé dans une pensée qui me donne des maux de tête en essayant de déterminer quel type de pli est approprié. Je finis généralement par dénouer tout le problème et par la mise en œuvre de la fonction de pliage telle qu'elle s'applique à mon problème.

Donc ce que je veux savoir, c'est:

• Quelles sont quelques règles de base pour déterminer s'il faut se plier à gauche ou à droite?
• Comment puis-je rapidement décider quel type de pli utiliser compte tenu du problème auquel je suis confronté?

Il existe un exemple dans Scala par exemple (PDF) d'utilisation d'un repli pour écrire une fonction appelée flatten qui concatène une liste de listes d'éléments en une seule liste. Dans ce cas, un pli droit est le bon choix (étant donné la façon dont les listes sont concaténées), mais j'ai dû y réfléchir un peu pour arriver à cette conclusion.

Étant donné que le pliage est une action si courante dans la programmation (fonctionnelle), j'aimerais pouvoir prendre ce genre de décisions rapidement et en toute confiance. Alors ... des conseils?

Vous pouvez transférer un pli dans une notation d'opérateur infixe (écriture entre les deux):

Cet exemple se plie en utilisant la fonction d'accumulateur x

fold x [A, B, C, D]

donc égale

A x B x C x D

Il ne vous reste plus qu'à raisonner sur l'associativité de votre opérateur (en mettant des parenthèses!).

Si vous avez un opérateur associatif à gauche , vous définissez les parenthèses comme ceci

((A x B) x C) x D

Ici, vous utilisez un pli gauche . Exemple (pseudocode de style haskell)

foldl (-) [1, 2, 3] == (1 - 2) - 3 == 1 - 2 - 3 // - is left-associative

Si votre opérateur est associatif à droite ( pli à droite ), les parenthèses seraient définies comme ceci:

A x (B x (C x D))

Exemple: contre-opérateur

foldr (:) [] [1, 2, 3] == 1 : (2 : (3 : [])) == 1 : 2 : 3 : [] == [1, 2, 3]

En général, les opérateurs arithmétiques (la plupart des opérateurs) sont associatifs à gauche, donc foldlplus répandus. Mais dans les autres cas, la notation infixe + parenthèses est assez utile.

Olin Shivers les a différenciés en disant «foldl est l'itérateur de liste fondamental» et «foldr est l'opérateur de récursivité de liste fondamentale». Si vous regardez le fonctionnement de foldl:

((1 + 2) + 3) + 4

vous pouvez voir l'accumulateur (comme dans une itération récursive de queue) en cours de construction. En revanche, foldr procède:

1 + (2 + (3 + 4))

où vous pouvez voir le parcours vers le cas de base 4 et construire le résultat à partir de là.

Je pose donc une règle empirique: si cela ressemble à une itération de liste, une itération qui serait simple à écrire sous forme récursive de queue, foldl est la voie à suivre.

Mais en réalité, cela sera probablement le plus évident à partir de l'associativité des opérateurs que vous utilisez. S'ils sont associatifs à gauche, utilisez foldl. S'ils sont associatifs à droite, utilisez foldr.

D'autres affiches ont donné de bonnes réponses et je ne répéterai pas ce qu'elles ont déjà dit. Comme vous avez donné un exemple Scala dans votre question, je vais donner un exemple spécifique à Scala. Comme Tricks l'a déjà dit, il foldRightfaut conserver n-1les cadres de pile, où nest la longueur de votre liste et cela peut facilement conduire à un débordement de pile - et même la récursivité de queue ne pourrait pas vous sauver de cela.

A List(1,2,3).foldRight(0)(_ + _)se réduirait à:

1 + List(2,3).foldRight(0)(_ + _)        // first stack frame
    2 + List(3).foldRight(0)(_ + _)      // second stack frame
        3 + 0                            // third stack frame 
// (I don't remember if the JVM allocates space 
// on the stack for the third frame as well)

tandis que List(1,2,3).foldLeft(0)(_ + _)se réduirait à:

(((0 + 1) + 2) + 3)

qui peut être calculé de manière itérative, comme cela a été fait dans la miseList en œuvre de .

Dans un langage strictement évalué comme Scala, a foldRightpeut facilement faire exploser la pile pour de grandes listes, alors que ce foldLeftn'est pas le cas.

Exemple:

scala> List.range(1, 10000).foldLeft(0)(_ + _)
res1: Int = 49995000

scala> List.range(1, 10000).foldRight(0)(_ + _)
java.lang.StackOverflowError
        at scala.List.foldRight(List.scala:1081)
        at scala.List.foldRight(List.scala:1081)
        at scala.List.foldRight(List.scala:1081)
        at scala.List.foldRight(List.scala:1081)
        at scala.List.foldRight(List.scala:1081)
        at scala.List.foldRight(List.scala:1081)
        at scala.List.foldRight(List.scala:1081)
        at scala.List.foldRight(List.scala:1081)
        at scala.List.foldRig...

Ma règle d'or est donc - pour les opérateurs qui n'ont pas d'associativité spécifique, utilisez toujours foldLeft, au moins dans Scala. Sinon, suivez les autres conseils donnés dans les réponses;).

Il convient également de noter (et je me rends compte que c'est un peu évident), dans le cas d'un opérateur commutatif, les deux sont à peu près équivalents. Dans cette situation, un foldl pourrait être le meilleur choix:

foldl: (((1 + 2) + 3) + 4)peut calculer chaque opération et reporter la valeur accumulée vers l'avant

foldr: a (1 + (2 + (3 + 4)))besoin d'un cadre de pile à ouvrir pour 1 + ?et 2 + ?avant le calcul 3 + 4, puis il doit revenir en arrière et faire le calcul pour chacun.

Je ne suis pas assez expert des langages fonctionnels ou des optimisations de compilateurs pour dire si cela fera réellement une différence, mais il semble certainement plus propre d'utiliser un foldl avec des opérateurs commutatifs.