我怎样才能获得严格的accumArray?

时间:2012-02-28 23:48:23

标签: haskell

我有一个键值对列表,我想计算每个键出现的次数以及它出现的值,但是当我尝试时,我得到一个堆栈溢出。这是我正在运行的代码的简化版本:

import Array
add (n, vals) val = n `seq` vals `seq` (n+1,val:vals)
histo = accumArray add (0,[]) (0,9) [(0, n) | n <- [0..5000000]]
main = print histo

当我用'ghc -O'编译它并运行它时,我得到“堆栈空间溢出:当前大小为8388608字节。”

我想我知道发生了什么:accumArray与foldl具有相同的属性,所以我需要一个严格版本的accumArray。不幸的是,我发现的唯一一个是Data.Array.Unboxed,它不适用于列表数组。

文档说当累积函数是严格的,那么accumArray也应该是,但我不能让它工作,讨论here声称文档是错误的(至少对于GHC而言)

除了Data.Array.Unboxed中的那个之外,是否有严格版本的accumArray?或者有更好的方法来做我想要的事情吗?

1 个答案:

答案 0 :(得分:4)

嗯,严格并不一定意味着没有创建thunk,它只是意味着如果参数是底部,结果也是底部。但是accumArray并不是那么严格,它只是在数组出现时将底部写入数组。它不能真正做任何其他事情,因为它必须允许非严格的函数,可以从中间底部产生定义的值。并且严格性分析器不能重写它,以便在每次写入时对累积函数进行WHNF评估,如果它是严格的,因为这将以相当激烈的方式改变程序的语义(包含一些底部与底部的数组)

尽管如此,我同意在一些领域缺乏严格和急切的职能。

对于你的问题,你可以使用更大的堆栈(这里+RTS -K128M不够,但256M就行了),或者你可以使用

import Data.Array.Base (unsafeRead, unsafeWrite)
import Data.Array.ST
import GHC.Arr

strictAccumArray :: Ix i => (e -> a -> e) -> e -> (i,i) -> [(i,a)] -> Array i e
strictAccumArray fun ini (l,u) ies = case iar of
                                       Array _ _ m barr -> Array l u m barr
  where
    iar = runSTArray $ do
        let n = safeRangeSize (l,u)
            stuff = [(safeIndex (l,u) n i, e) | (i, e) <- ies]
        arr <- newArray (0,n-1) ini
        let go ((i,v):ivs) = do
                old <- unsafeRead arr i
                unsafeWrite arr i $! fun old v
                go ivs
            go [] = return arr
        go stuff

严格写入时,thunk保持较小,因此没有堆栈溢出。但请注意,列表占用了大量空间,因此如果列表太长,可能会导致堆耗尽。

另一种选择是使用Data.Map(或Data.IntMap,如果containers的版本是0.4.1.0或更高版本)而不是数组,因为它附带{{ 1}},强制使用组合函数的结果。例如,代码可以是

insertWith'

使用import qualified Data.Map as M -- or Data.IntMap import Data.List (foldl') histo :: M.Map Int (Int,[Int]) -- M.IntMap (Int,[Int]) histo = foldl' upd M.empty [(0,n) | n <- [0 .. 15000000]] where upd mp (i,n) = M.insertWith' add i (1,[n]) mp add (j,val:_) (k,vals) = k `seq` vals `seq` (k+j,val:vals) add _ pr = pr -- to avoid non-exhaustive pattern warning 的缺点是

  • 组合函数必须具有类型Map,因此在您的情况下需要更复杂。
  • 更新是O(日志大小)而不是O(1),因此对于大型直方图,它会慢得多。
  • a -> a -> a s和Map有一些簿记开销,因此将使用比数组更多的空间。但是,如果更新列表与索引数相比较大,则差异可以忽略不计(在这种情况下,每个键的开销为IntMap个字,与值的大小无关),其中大小为每次更新都会增加值。