Idiomatiques efficace Haskell ajouter?

Liste et les inconvénients de l'opérateur (:) sont très fréquents en Haskell. Le contre est notre ami. Mais parfois, j'ai envie d'ajouter à la fin d'une liste à la place.

xs `append` x = xs ++ [x]

Cela, malheureusement, est pas un moyen efficace de mettre en œuvre.

J'ai écrit jusqu' Le triangle de Pascal en Haskell, mais j'ai dû utiliser la ++ [x] anti-idiome:

ptri = [1] : mkptri ptri
mkptri (row:rows) = newRow : mkptri rows
    where newRow = zipWith (+) row (0:row) ++ [1]

à mon humble avis, c'est une belle lisible le triangle de Pascal et de tous, mais l'anti-idiome ne m'irrite. Quelqu'un peut m'expliquer (et, idéalement, m'indiquer un bon tutoriel) sur ce que l'idiomatiques structure de données est pour les cas où vous voulez ajouter à la fin de manière efficace? J'espère que pour la proximité de la-liste-comme la beauté dans cette structure de données et de ses méthodes. Ou, alternativement, expliquez-moi pourquoi cet anti-idiome est en fait pas si mauvais que ça pour ce cas (si vous croyez que tel est le cas).

[modifier] La réponse que j'aime le plus Data.Sequence, qui n'ont, en effet, "près de de la liste comme la beauté." Pas sûr de savoir comment je me sens sur la rigueur d'exploitation. D'autres suggestions et des idées différentes sont toujours les bienvenus.

import Data.Sequence ((|>), (<|), zipWith, singleton)
import Prelude hiding (zipWith)

ptri = singleton 1 : mkptri ptri

mkptri (seq:seqs) = newRow : mkptri seqs
    where newRow = zipWith (+) seq (0 <| seq) |> 1

Maintenant nous avons juste besoin de la Liste à être une classe, alors que d'autres structures peuvent utiliser ses méthodes comme zipWith sans le cacher de Prélude, ou en le qualifiant. 😛

  • La liste n'est pas une classe, mais ListLike est. Il y a un Données.Séquence instance est disponible aussi. hackage.haskell.org/package/ListLike-3.0.1
  • Aléatoire gêne: j'ai d'abord essayé d'écrire newRow = 1 <| zipWith (+) seq (drop 1 seq) |> 1, qui à mon humble avis est très beau pour exprimer le triangle de Pascal en montrant explicitement les 1 aux deux extrémités de chaque ligne. Malheureusement, j'ai eu cette erreur: cannot mix '<|' [infixr 5] and '|>' [infixl 5] in the same infix expression
  • Cette seconde newRow est très belle. J'ai eu un non-idéalement-succès avec ZipLists (je m'attendais à quelque chose de plus général, mais c'était trop compliqué), hpaste.org/44613/pascals_ziplist. Avec l'idiome crochets de la she préprocesseur, et quelques maison combinators il ressemble à ceci: pascalsNextLine old = 1 <& (| tail' old + init' old |) &> 1 Il serait intéressant de savoir si il ya quelque chose à généraliser cette idée de la vôtre.
  • Il semble que les deux |> et <| ont la même priorité, de sorte qu'ils ne peuvent pas passer à côté de l'autre. Je me demande si il existe un moyen de changer cela, sans se briser d'autres fichiers, sorta sur un fichier par fichier.
  • Je me demandais à propos de cette trop. Une idée que j'avais était d'utiliser un O(1) cons comme un ajout, mais de là à O(n) reverse la liste résultante. Voir aussi: le contraste entre la mise en œuvre de map par rapport à reverse.
InformationsquelleAutor Dan Burton | 2011-03-04
  1. 16

    Standard Sequence a O(1) pour plus de "les deux bouts" et O(log(min(n1,n2))) pour le général de concaténation:

    http://hackage.haskell.org/packages/archive/containers/latest/doc/html/Data-Sequence.html

    La différence à partir de listes, c'est que Sequence est stricte

    • L'une des choses les plus frustrantes pour les nouveaux utilisateurs de Données.La séquence est qu'il n'y a pas beaucoup de fonctions exportées avec elle. Vous avez besoin de faire usage de la Functor, Pliable, Monoïde, et Traversable instances d'accéder à de nombreuses opérations courantes.
    • Oui, mais c'est une vertu dans de nombreuses façons. Une fois que vous savez ces opérations, vous pouvez les utiliser sur presque n'importe quelle structure de données.
    InformationsquelleAutor Ed'ka
  2. 28

    Gardez à l'esprit que ce qui semble pauvres asymptotique pourrait pas être, parce que vous travaillez dans un paresseux de la langue. Dans le cadre strict de la langue, en ajoutant à la fin d'une liste liée dans cette voie serait toujours O(n). Dans un paresseux de la langue, c'est O(n) seulement si vous traverse à la fin de la liste,auquel cas vous auriez dépensé O(n) effort de toute façon. Ainsi, dans de nombreux cas, la paresse vous sauve.

    Ce n'est pas une garantie... par exemple, k ajoute suivie par un parcours va toujours s'exécuter en O(nk), où il pourrait avoir été O(n+k). Mais il n'changer l'image un peu. La réflexion sur la performance de simples opérations en fonction de leur complexité asymptotique lorsque le résultat est immédiatement forcé n'est pas toujours vous donner la bonne réponse à la fin.

    InformationsquelleAutor Chris Smith
  3. 10

    Quelque chose comme cela explicite la récursivité évite de votre append "anti-idiome". Bien que, je ne pense pas que c'est aussi clair que votre exemple.

    ptri = []:mkptri ptri
mkptri (xs:ys) = pZip xs (0:xs) : mkptri ys
    where pZip (x:xs) (y:ys) = x+y : pZip xs ys
          pZip [] _ = [1]
    • +1 réponse Intelligente. Vous avez raison, c'est moins clair, mais il n'exige pas de l'anti-idiome, et c'est à peu près aussi efficace que possible (autant que je sache). Pas le "accepté" réponse, si, parce que j'espérais pour une utilisation générale de la solution. Vous pouvez réellement faire la dernière ligne pZip _ _ = [1]
    InformationsquelleAutor David Powell
  4. 8

    Dans votre code pour le Triangle de Pascal, ++ [x] n'est pas réellement un problème. Depuis que vous avez à produire une nouvelle liste sur le côté gauche de ++ de toute façon, votre algorithme est intrinsèquement quadratique; elle ne peut pas être asymptotiquement plus rapide simplement en évitant ++.

    Aussi, dans ce cas particulier, lors de la compilation -O2, GHC la liste de fusion règles (devrait) éliminer la copie de la liste ++ normalement créer. C'est parce que zipWith est un bon producteur et ++ est un bon consommateur, c'est le premier argument. Vous pouvez lire au sujet de ces optimisations dans GHC Guide de l'Utilisateur.

    • +1 Cool, j'ai imaginé quelque chose comme ceci est peut-être vrai. Grand lien.
    InformationsquelleAutor lpsmith
  5. 5

    Selon votre cas d'utilisation, les ShowS méthode (en ajoutant par composition de fonctions) peut être utile.

    • Compte tenu de l'exacte algorithme en cours d'utilisation, j'utiliserais ShowS approche.. Mais ça va être une constante amélioration du coefficient d', de toute façon. La construction de la ligne en question est déjà en O(n). L'ajout d'un autre O(n) étape ne pas faire trop de mal.
    InformationsquelleAutor geekosaur
  6. 5

    Si vous voulez juste bon marché append (concat) et snoc (contre à droite) un Hughes liste, aussi appelé DList sur Hackage, est la plus simple à mettre en œuvre. Si vous voulez savoir comment ils fonctionnent, regarder Andy Gill et Graham Hutton premier Travailleur Wrapper papier, John Hughes, le papier d'origine ne semble pas être en ligne. Comme d'autres l'ont dit ci-dessus Montre est une Chaîne spécialisée Hughes liste /DList.

    Un JoinList est un peu plus de travail à mettre en œuvre. C'est un arbre binaire, mais avec une liste d'API - concat et snoc sont bon marché et vous pouvez raisonnablement fmap: le DList sur Hackage a un foncteur instance, mais à mon avis il ne devrait pas avoir le foncteur instance a pour metamorph dans et hors d'une liste ordinaire. Si vous voulez un JoinList ensuite, vous aurez besoin de rouler votre propre l'un sur le Hackage est le mien et il n'est pas efficace, ni bien écrit.

    De données.La séquence est efficace contre et snoc, et il est bon pour les autres opérations - prend des gouttes, etc. qu'un JoinList est lent pour. Parce que l'intérieur du doigt de l'arbre de la mise en œuvre de Données.La séquence a pour l'équilibre de l'arbre, append est plus de travail que ses JoinList équivalent. Dans la pratique, car les Données.La séquence est mieux écrit, je m'attends toujours sur-effectue mon JoinList pour l'ajouter.

    InformationsquelleAutor stephen tetley
  7. 4

    d'une autre manière à éviter de concaténation à tous en utilisant simplement infini listes:

    ptri = zipWith take [0,1..] ptri'
  where ptri' = iterate stepRow $ repeat 0
        stepRow row = 1 : zipWith (+) row (tail row)
    • Vous pouvez écrire que: ptri = zipWith take [1..] . iterate ((zipWith (+) <*> tail) . (0:)) $ 1 : repeat 0 (en supposant que vous avez importé Control.Applicative). Une autre façon intéressante de le faire est: ptri = zipWith take [1..] . transpose . zipWith (++) (iterate (0 :) []) . iterate (scanl1 (+)) $ repeat 1
    InformationsquelleAutor rampion
  8. 3

    Je n'aurais pas forcément appeler votre code "anti-idomatic". Souvent, plus claire est mieux, même si cela signifie sacrifier quelques cycles d'horloge.

    Et dans votre cas particulier, l'ajouter à la fin n'a pas vraiment changer le big-O temps de la complexité! L'évaluation de l'expression

    zipWith (+) xs (0:xs) ++ [1]

    prendra du temps proportionnel length xs et pas de fantaisie, la séquence de la structure de données va changer ça. Si quoi que ce soit, seul le facteur constant sera affectée.

    • Très vrai, le travail total de chaque ligne est toujours en O(n) de toute façon. J'ai aimé les Données.Séquence de solution, cependant, car elle a permis à la même clarté (ou, je dirais, un peu plus de clarté), et il permet également de réduire la quantité de O(n) le travail doit être fait par ligne.
    • Yup, je suis d'accord que Data.Sequence est tout aussi clair.
    • Et comme lpsmith souligné ci-dessus, vous n'avez même pas perdre toute cycles d'horloge dans ce cas. GHC est assez intelligent pour optimiser loin.
    InformationsquelleAutor Heinrich Apfelmus
  9. 2

    Chris Okasaki a un design pour une file d'attente qui traite de cette question. Voir la page 15 de sa thèse
    http://www.cs.cmu.edu/~cep/thèses/okasaki.pdf

    Vous faudra peut-être adapter le code légèrement, mais certains l'utilisent de l'inversion et de garder les deux morceaux de la liste vous permet de travailler plus efficacement en moyenne.

    Aussi, quelqu'un a mis en place certains de la liste de code dans la monade lecteur avec l'efficacité des opérations. Je l'avoue, je n'ai pas vraiment le suivre, mais j'ai pensé que je pourrais le comprendre si je me suis concentré. Il s'avère qu'il a été Douglas M. Auclair dans la Monade problème des lecteurs 17
    http://themonadreader.files.wordpress.com/2011/01/issue17.pdf

    J'ai réalisé la réponse ci-dessus ne permet pas de répondre directement à la question. Donc, pour rire, voici mon récursive réponse. Hésitez pas à déchirent -- elle n'est pas jolie.

    import Data.List 

ptri = [1] : mkptri ptri

mkptri :: [[Int]] -> [[Int]]
mkptri (xs:ys) =  mkptri' xs : mkptri ys

mkptri' :: [Int] -> [Int]
mkptri' xs = 1 : mkptri'' xs

mkptri'' :: [Int] -> [Int]
mkptri'' [x]        = [x]
mkptri'' (x:y:rest) = (x + y):mkptri'' (y:rest)
    InformationsquelleAutor Tim Perry
  10. 1

    Si vous êtes à la recherche d'un objectif général de solution, comment à ce sujet:

    mapOnto :: [b] -> (a -> b) -> [a] -> [b]
mapOnto bs f = foldr ((:).f) bs

    Cela donne une simple alternative définition de la carte:

    map = mapOnto []

    Nous pouvons une définition similaire pour d'autres foldr fonctions, comme zipWith:

    zipOntoWith :: [c] -> (a -> b -> c) -> [a] -> [b] -> [c]
zipOntoWith cs f = foldr step (const cs)
  where step x g [] = cs
        step x g (y:ys) = f x y : g ys

    Nouveau dérivant zipWith et zip assez facilement:

    zipWith = zipOntoWith []
zip = zipWith (\a b -> (a,b))

    Maintenant, si nous utilisons ces fonctions, votre mise en œuvre
    devient assez facile:

    ptri :: (Num a) => [[a]]
ptri = [] : map mkptri ptri
  where mkptri xs = zipOntoWith [1] (+) xs (0:xs)
    InformationsquelleAutor rampion
  11. 1

    J'ai écrit un exemple de @geekosaur de ShowS approche. Vous pouvez voir de nombreux exemples de ShowS dans le prélude.

    ptri = []:mkptri ptri
mkptri (xs:ys) = (newRow xs []) : mkptri ys

newRow :: [Int] -> [Int] -> [Int]
newRow xs = listS (zipWith (+) xs (0:xs)) . (1:)

listS :: [a] -> [a] -> [a]
listS [] = id
listS (x:xs) = (x:) . listS xs

    [modifier] Comme @Dan idée, je l'ai réécrit newRow avec zipWithS.

    newRow :: [Int] -> [Int] -> [Int]
newRow xs = zipWithS (+) xs (0:xs) . (1:)

zipWithS :: (a -> b -> c) -> [a] -> [b] -> [c] -> [c]
zipWithS z (a:as) (b:bs) xs =  z a b : zipWithS z as bs xs
zipWithS _ _ _ xs = xs
    • Ok, peut-être que je suis juste stupide, mais je ne vois pas la différence entre listS et ++, compte tenu de la définition de ++ c'est la même chose, juste moins pointfree: (++) :: [a] -> [a] -> [a] (++) [] ys = ys (++) (x:xs) ys = x : xs ++ ys
    • Ou vous pourriez faire zipWithS depuis zipWith doit passer par chaque élément de toute façon.
    • Non, j'ai été stupide. Maintenant, j'ai réalisé que ce sont les mêmes! ainsi que showString = (++) dans prélude. Donc newRow peut être newRow xs = ((zipWith (+) xs (0:xs)) ++). (1:)
    • J'aime l'idée. Le point a (flux de concaténation [a]->[a] au lieu de la liste) est un idiome et je l'ai vu à de nombreux endroits.
    InformationsquelleAutor Takashi Yamamiya
  12. 1

    Vous pouvez représenter une liste en fonction de construire une liste de []

    list1, list2 :: [Integer] -> [Integer]
list1 = \xs -> 1 : 2 : 3 : xs
list2 = \xs -> 4 : 5 : 6 : xs

    Ensuite, vous pouvez ajouter facilement des listes et ajouter à la fin.

    list1 . list2 $ [] -> [1,2,3,4,5,6]
list2 . list1 $ [] -> [4,5,6,1,2,3]
(7:) . list1 . (8:) . list2 $ [9] -> [7,1,2,3,8,4,5,6,9]

    Vous pouvez réécrire zipWith le retour de ces listes partielles:

    zipWith' _ [] _ = id
zipWith' _ _ [] = id
zipWith' f (x:xs) (y:ys) = (f x y :) . zipWith' f xs ys

    Et maintenant, vous pouvez écrire ptri comme:

    ptri = [] : mkptri ptri
mkptri (xs:yss) = newRow : mkptri yss
    where newRow = zipWith' (+) xs (0:xs) [1]

    Aller plus loin, voici un one-liner qui est plus symétrique:

    ptri = ([] : ) . map ($ []) . iterate (\x -> zipWith' (+) (x [0]) (0 : x [])) $ (1:)

    Ou c'est plus simple encore:

    ptri = [] : iterate (\x -> 1 : zipWith' (+) (tail x) x [1]) [1]

    Ou sans zipWith' (mapAccumR est dans les Données.Liste):

    ptri = [] : iterate (uncurry (:) . mapAccumR (\x x' -> (x', x+x')) 0) [1]
    InformationsquelleAutor HackerFoo