CODEWITHSUNDEEP
haskellfunctional-programming
Norrius
Norrius

Reputation: 7920

What is "a Haskell way" to transpose a graph?

Suppose I have a tree represented as a list of parents and I want to reverse the edges, obtaining a list of children for each node. For this tree - https://i.sstatic.net/uapqT.png - transformation would look like:

[0,0,0,1,1,2,5,4,4] -> [[2,1],[4,3],[5],[],[8,7],[6],[],[],[]]

But it's not limited to graph transposing, however. I have a few other problems that I would solve in imperative language in the following way: traverse some source data array and non-sequentially update a resulting array as I get to know something about it.

Essentially, my question is "what is Haskell's idiomatic way to solve things like this?". As I understand, I can do it in imperative way by means of mutable vectors, but isn't there some purely functional method? If not, how would I properly use mutables?

Finally, I need it to work fast, that is O(n) complexity, and non-standard packages are not an option for me.

Upvotes: 0

Views: 520

Answers (2)

András Kovács
András Kovács

Reputation: 30103

It's worth to consider the pure functions in Data.Vector or Data.Array that internally use mutation, in order to be more efficient (the accum-s in both libraries, plus the unfolds and construct-s in vector).

The accum-s are great when we don't care about intermediate states of an array during construction. They're nicely applicable for transposing graphs, although we have to provide a range for the node keys:

{-# LANGUAGE TupleSections #-}

import qualified Data.Array as A

type Graph = [(Int, [Int])]

transpose :: (Int, Int) -> Graph -> Graph
transpose range g =
    A.assocs $ A.accumArray (flip (:)) [] range (do {(i, ns) <- g; map (,i) ns})

Here we first unroll the graph into an adjacency list, but with swapped pairs of indices, and then accumulate them into an array. It's roughly as fast as a standard imperative loop over a mutable array, and it's more convenient than the ST monad.

Alternatively, we can just use IntMap, likely alongside the State monad, and just port our imperative algorithms as they are, and the performance will be satisfactory for most purposes.

Fortunately IntMap provides a lot of higher-order functions, so we're not (always) forced to program in an imperative style with it. There's an analogue for accum, for instance:

import qualified Data.IntMap.Strict as IM

transpose :: Graph -> Graph
transpose g =
  IM.assocs $ IM.fromListWith (++) (do {(i, ns) <- g; (i,[]) : map (,[i]) ns})

Upvotes: 2

Petr
Petr

Reputation: 63359

A purely functional way would be to use a map to store the information, producing O(n log n) algorithm:

import qualified Data.IntMap as IM
import Data.Maybe (fromMaybe)

childrenMap :: [Int] -> IM.IntMap [Int]
childrenMap xs = foldr addChild IM.empty $ zip xs [0..]
  where
    addChild :: (Int, Int) -> IM.IntMap [Int] -> IM.IntMap [Int]
    addChild (parent, child) = IM.alter (Just . (child :) . fromMaybe []) parent

You could also use an imperative solution and keep things pure using the ST monad, which is obviously O(n), but the imperative code somewhat obscures the main idea:

import Control.Monad (forM_)
import Data.Array
import Data.Array.MArray
import Data.Array.ST

childrenST :: [Int] -> [[Int]]
childrenST xs = elems $ runSTArray $ do
    let l = length xs
    arr <- newArray (0, l - 1) []
    let add (parent, child) =
          writeArray arr parent . (child :) =<< readArray arr parent
    forM_ (zip xs [0..]) add
    return arr

One drawback of this approach is that an index is out of bounds, it just fails. Another is that you traverse the list twice. However, if you used arrays instead of lists everywhere, this wouldn't matter.

Upvotes: 1

Related Questions