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 functions.
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
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!
If
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 (r, g') =
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,
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 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 = StateT
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-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 =
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
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 =
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
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 quite
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
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
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 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
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
second and third versions
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 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 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
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 function that would
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 way...
I think my code
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
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 thought
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 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 return
28 matches
Mail list logo
