cblp on gh-pages
Update 2017-04-06-react-flux-gu… (compare)
cblp on react-flux-talk-timecode-fix
cblp on master
Update 2017-04-06-react-flux-gu… (compare)
astynax on react-flux-talk-timecode-fix
Update 2017-04-06-react-flux-gu… (compare)
cblp on master
Revert @ruhaskell (compare)
cblp on master
Add @ruhaskell (compare)
cblp on gh-pages
Update link (#109) https://has… (compare)
cblp on qnikst-patch-1
cblp on master
Update link (#109) https://has… (compare)
qnikst on qnikst-patch-1
Update link https://haskell-la… (compare)
Сначала я его распарсил в DotGraph a
из http://hackage.haskell.org/package/graphviz-2999.20.0.3/docs/Data-GraphViz-Types-Graph.html
Распарсить таким образом, чтобы в a
был лейбл я не смог, поэтому пришлось написать функцию, которая проходит по всему графу и матчит ноду с нужными атрибутами. У найденной ноды дернул successors
, а это оказались только непосредственные последователи. Т.е. тут тоже чет рекурсивное надо было изобретать, поэтому я забил.
Потом через fgl
пробовал, но там оказалось что при восстановлении назад из fgl
в дот он какую-то информацию теряет. Не помню уже что именно. Я расстроился и пошел пить.
s
только строятся задумки (s + 1), но никогда не вычисляются
g ks (x0,xs,s)
|x0 == x0' = (x0,s)
|True = g ks (x0',x0:take 30 xs,(s+1))
where
x0' = f xs ks /sum ks
f (x:xs) (k:ks') = x*k + f xs ks'
f _ _ = 0
main = g [2,3,9] (1,[],0)
s
sum
тоже линейно память потребляет на некоторых уровнях оптимизации
g ks (x0,xs,s)
|x0 == x0' = (x0,s)
|True = seq s $ g ks (x0',x0:take 30 xs,1)
where
x0' = f xs ks /14
f (x:xs) (k:ks') = x*k + f xs ks'
f _ _ = 0
так тоже течет x0 x0' должны разрешаться до числа для сравнения в моем понимании, если это не так то понятно куда, но они должны вычисляться?
g ks (x0,xs,s)
|x0 == x0' = (x0,s)
|True = g ks (x0',x0:take 2 xs,s)
where
x0' = f xs ks /sum ks
f (x:xs) (k:ks') = x*k + f xs ks'
f _ _ = 0
практический ответ найден, при take 2 ... take 3 ... утечки нет, при take 4 и более начинается стремительная утечка, получается лишний хвост из более чем 1 элемента влечет утечку (видимо мусорщик считает что этот хвост потом пригодится...) но это мои фантазии.
take
. Либо расставьте аннотации строгости руками, либо хотя бы соберите с оптимизацией, для начала.
x0 == x0'
должно вычислять x0
и x0'
, x0'
приводит к полному вычислению xs
и ks
, в результате они начинают занимать всю свою память, но не освобождаются, потому что передаются дальше
g ks x0 xs s
|x0 == x0' = (x0,s)
|True = seq (s+1) $ g ks x0' (x0:take (length ks -1) xs) ((s+1)::Int)
where
x0' = f xs ks /sum ks
f (x:xs) (k:ks') = x*k + f xs ks'
f _ _ = 0
основная засада для меня была в том, что "лишний" хвост xs вызывал утечку, хотя он явно нигде более не используется. Спасибо огромное за участие.
xs
утекала через задумку x0 : take _ xs
f
- это dot product, как я понимаю?
seq (s + 1)
смысла не имеет, сложение там ни к селу, ни к городу.
take
ами происходит - нужно разбираться. Но Вам в любом случае нужно понять как работают "задумки" aka thunks и как возникают space leaks. Об этом написано на Haskell wiki и в книге "Parallel and Concurrent Programming in Haskell" (имеется русский перевод).
[1..]
, на уровне компилятора я в этом разбираться не хочу, так как написание компиляторов не моя профессия. Меня пугает отсутствие единообразия результатов в зависимости от количества лишних в списке, то есть тут явно есть бифуркация между 0,1 и остальными числами - хотелось бы понять почему.
Я вот хочу смерджить две мапы таким образом, чтобы при слиянии элементов с одинаковыми ключами одному из них придумывался новый ключ (даже не важно какой) и оба элемента добавлялись бы в конечный мап.
Насколько я понимаю, https://hackage.haskell.org/package/containers-0.6.2.1/docs/Data-IntMap-Merge-Lazy.html этого не позволяет. Надо велосипедить самому?