Re: Map-Reduce

En fait, il y a deux choses à distinguer

1. Le fait de construire une structure intermédiaire (qui serait sinon implicite dans le code)
2. Le fait de construire/détruire cette structure « à la même vitesse » (ce qui n'est possible que dans certains cas) et qui permet de ne jamais à avoir l’intégralité de la structure en mémoire

Ce qui est illustré avec cat est le deuxième point (selon moi).

Le map va charger en mémoire tes données puis les rendre accessible à la réduction

C'est bien la différence : ce qui est illustré est le fait de construire une donnée qui n'était pas explicitement construite avant. Dans les premiers exemples du journal, cela consiste simplement à construire l'arbre d'appel réellement, puis de le parcourir, le dernier consiste à construire l'arbre de décisions que l'algorithme allait parcourir de manière physique, plutôt que de continuer à raisonner sur des décisions locales.

De plus, dans ta définition, le map est « inutile » : on peut quasi-systématiquement écrire map en fonction de reduce

map (f,coll) = reduce (lambda x,y: insertColl(x,f(y)), emptyColl, coll)

Mieux encore, en utilisant quelques équations algébriques sur les compositions de reduce, le map-reduce peut se ré-écrire sans map :

reduce (action, init, map (fonction, collection)) = reduce (lambda x,y: action (x, fonction(y)), init, collection)

à une chose sur la quelle on peut itérer

C'est déjà assez puissant : une grande partie des données sont définies de manière inductive dans les langages fonctionnels, et donc un reduce vient automatiquement. Par exemple, il existe une manière de représenter les graphes de manière inductive (ce qui vient avec un certain cout toutefois).