On Mon, 2008-12-29 at 14:19 -0500, Ross Mellgren wrote:
> The problem is that you're trying to take a STMatrix from some other
> ST computation and freeze it in a new ST computation. The isolation
> between separate computations is done via the rank-2 type variable "s"
> in all those ST funct
On Sun, 2008-12-21 at 16:47 -0800, Ryan Ingram wrote:
> The problem is that you are trying to return a mutable array out of an
> ST computation. This lets the "mutability" of the computation escape.
> That's what the "s" type variable is for; without it, runST is just
> unsafePerformIO.
I'm try
On Sun, 2008-12-21 at 16:47 -0800, Ryan Ingram wrote:
> The problem is that you are trying to return a mutable array out of an
> ST computation. This lets the "mutability" of the computation escape.
> That's what the "s" type variable is for; without it, runST is just
> unsafePerformIO.
Thanks!
Hello,
I'm trying to write a function that would take an STArray and and
shuffle its elements. I'm having trouble with the ST monad, though, and
couldn't find out how fix this issue.
The problem happens when I use runST to extract the shuffled array from
the ST monad. I'm getting the following er
On Sat, 2008-09-20 at 14:56 +0200, Daniel Fischer wrote:
> > modify' f = do
> > s <- get
> > put $! f s
>
> Or try Control.Monad.State.Strict.
Control.Monad.State.Strict did it for me, but the strict modify didn't.
I tried using modify' and also
randomDouble = do
g <- get
let (
On Fri, 2008-09-19 at 23:16 +0200, Daniel Fischer wrote:
> Yes. What's IO gotta do with it?
I did it because of randomIO :(
> (or what about StateT (Graph a b) (State StdGen) ?).
Now there's something I wouldn't have thought of... I changed the
RandomGraph type to
type RandomGraph a b = State
On Fri, 2008-09-19 at 09:51 +0200, apfelmus wrote:
> There's also Martin Erwig's functional graph library in Data.Graph.Inductive
> (
> fgl on hackage).
I tried it some time ago, but for large graphs it has a very high memory
usage.
Best,
Andre
___
On Fri, 2008-09-19 at 10:35 +0200, Christian Maeder wrote:
> I agree. Duncan's version also looks more atomic to me,
[...]
OK, so what I have now is
addVertex :: Int -> a -> Graph a b -> Graph a b
addVertex v l g = Graph adj (numVertices g + 1) (numEdges g)
where adj = Map.insert v (l, Ma
On Thu, 2008-09-18 at 21:13 +0200, minh thu wrote:
> If you need the one inside the State monad, you can reuse the new
> version of addVertex.
You mean making the graph creation functions (which will call
addVertex/Edge) use the State monad instead? Interesting idea... what I
really wanted was to
On Thu, 2008-09-18 at 21:15 +0200, Henning Thielemann wrote:
> Think of the state monad as processing a graph in-place. Which graph is
> addressed is declared when running the State monad using runState or
> evalState.
Interesting. Is it good practice then to do something like
type GraphM a b
Hello
I'm trying to write a simple graph library for a project of mine
(actually, I'm porting it from OCaml) but I've got a design question
right in the beginning.
My Graph type is the following.
data Graph a b = Graph
{ adjacencies :: Map Int (a, (Map Int b))
, numVertices :: Int
On Thu, 2008-07-10 at 16:52 -0700, Don Stewart wrote:
> Well, they're radically different graph representations, and fgl
> hasn't been designed for large graphs.
Do you know if King and Launchbury's implementation (Data.Graph) scales
better?
> What C library is Ruby's binding to? It might be quit
On Thu, 2008-07-10 at 18:32 -0400, Ronald Guida wrote:
> Your ratios are about 1 : 3 : 8.
> That pretty close to quadratic growth, 1 : 4 : 9, so I think all is well.
Maybe, but 96MB of resident memory for a 1000-node graph looks bad,
especially considering p is low. Is the internal representation
Hello
I'm trying to create a directed graph using the Data.Graph.Inductive.
The graph is a random graph using the G(n, p) model, that is, each of
the n nodes is linked to every other node with probability p.
I'm seeing a large increase of memory usage when n grows (this is using
p = 0.1):
n = 10
On Sat, 2008-01-12 at 21:39 -0800, Jonathan Cast wrote:
> No. A cell is generated once either (a) it, or (b) a cell earlier in
> the list, is required. A cell is garbage collected once both (a) it,
> and (b) all cells earlier in the list, are no longer required. So if
> you process the lis
On Sat, 2008-01-12 at 16:00 -0800, Jonathan Cast wrote:
> Wait, the last entry? If you're just printing out the values, then
> no --- those should have been garbage collected already.
Won't they be garbage collected only after the last entry is used,
though? Since getDirectoryEntries returns a
On Sat, 2008-01-12 at 10:11 -0800, Jonathan Cast wrote:
> A nit: the list is almost certainly getting created lazily, or you'd
> get more than 300% more memory usage. But you still get the list's
> cons cells as your bookkeeping baggage, and they take up space in
> exchange for greater flexi
On Fri, 2008-01-11 at 19:14 -0800, Jonathan Cast wrote:
> These are all known and expected. As I said, you can expect lazy
> versions to normally be slower than explicit loops. The question is
> whether 50% more time and 300% more memory has a higher cost in your
> case than the extra compl
On Fri, 2008-01-11 at 20:20 -0200, Andre Nathan wrote:
> Both versions which use getDirectoryContents also use much more memory
> than the one which uses readDirStream (about 8M vs about 2M). Maybe I'm
> not exploting getDirectoryContents' laziness correctly? I expected the
On Fri, 2008-01-11 at 13:27 -0200, Andre Nathan wrote:
> I was wondering if laziness would make it run as if it was a single O(n)
> operation (get one directory entry "on demand", pass it to filter and
> then to insertInTree), because only one entry is used at a time, so that
On Thu, 2008-01-10 at 20:37 -0800, Jonathan Cast wrote:
> It might be faster; laziness usually has higher constants than direct
> implementations. But I doubt the difference is critical in this
> case, and I would definitely time a re-writing and throw it away
> unless it was significantly f
Hi Jonathan
On Wed, 2008-01-09 at 21:32 -0800, Jonathan Cast wrote:
> An actual coding question, abuse? We should be so lucky.
:) Your comments are much appreciated.
> This function is fairly complicated, simply because of the number of
> separate definitions involved; I would be looking for
Hello
I've just found time to finish writing my first "real world" program, so
I thought I'd post it here and ask for insight on general issues such as
if there's anything that isn't done "the Haskell way", or if there's
something that could be done more efficiently.
The code is at the bottom of
On Wed, 2007-12-19 at 17:54 -0600, Tommy McGuire wrote:
> (Note: I haven't gotten to it in the revisions following the comments I
> received here and there are many things that need work. The notes are
> incoherent, it's more Pascallish than Haskell, and there are no
> guarantees that it won't
On Wed, 2007-12-19 at 02:45 +0100, Daniel Fischer wrote:
> I believe instead of return $ foldr... you should use
> evalStateT $ foldM (flip buildTree) Map.empty entries
This seems to have done it:
evalStateT $ (foldM (flip buildTree) Map.empty entries)) Map.empty
(the second argument to
On Tue, 2007-12-18 at 16:47 -0200, Andre Nathan wrote:
> I'm trying to finish the process tree construction but I guess I'll need
> some help again.
I guess I could do away with StateT and just pass the PsMap around as a
parameter, but I guess that wouldn't be the haskell wa
Hello
On Mon, 2007-12-17 at 21:22 -0200, Andre Nathan wrote:
> Thanks everyone for the great suggestions. The code is much cleaner now
> (not to mention it works :)
I'm trying to finish the process tree construction but I guess I'll need
some help again.
My idea is to have a fun
On Mon, 2007-12-17 at 17:56 -0600, Derek Elkins wrote:
> Have you read Wadler's papers?
Yeah, I read the two you mentioned. While I can't say I've already
understood 100% of them, I completely agree with you in that they're the
best texts on monads, from what I've seen (maybe because they explain
On Mon, 2007-12-17 at 17:33 -0200, Andre Nathan wrote:
> Hello (Newbie question ahead :)
Thanks everyone for the great suggestions. The code is much cleaner now
(not to mention it works :)
This is the first non-tutorial program I'm writing and all this monad
stuff is easier than I th
Hello (Newbie question ahead :)
I'm trying to write a program which will build a tree (here represented
as a Map) of unix processes. The tree should be built by reading the
process information stored in /proc/PID/status. There is also another
Map which will be used for faster insertions on the pr
On Fri, 2007-05-18 at 22:32 +0200, Tillmann Rendel wrote:
>[snip]
> Now you should be able to use do notation with your own Parser type.
Thanks! Monads and instances weren't mentioned until that point, so I
was assuming that all that was needed for the "do" notation to work was
having "(>>=)" and
Hello
I've been reading Programming in Haskell, and I'm trying to go through
the parser examples in chapter. However, I'm getting a type error when
using the "do" notation. Here's the code I'm trying to load in ghci,
which is copied from the book:
import Prelude hiding ((>>=), return)
import Char
32 matches
Mail list logo
