Hi George,
thanks for your detailed reply.
George Giorgidze wrote:
The key to the approach used in set-monad is to make progress with the
evaluation of the unconstrained constructors (i.e., Return, Bind, Zero
and Plus) without using constrained set-specific operations. It turns
out that for
Hi Tillmann,
Thanks for your interesting question regarding the performance
overheads of the Data.Set.Monad wrapper compared to the original
Data.Set library.
If you use set-specific functions there will not be any difference in
asymptotic complexity between Data.Set.Monad and Data.Set.
In
Hi,
David Menendez wrote:
As you noticed, you can get somewhat better performance by using the
combinators that convert to S.Set internally, because they eliminate
redundant computations later on.
Somewhat better? My example was three times faster, and I guess that
the fast variant is O(n)
On Sun, Jun 17, 2012 at 2:26 AM, Tillmann Rendel
ren...@informatik.uni-marburg.de wrote:
Hi,
David Menendez wrote:
As you noticed, you can get somewhat better performance by using the
combinators that convert to S.Set internally, because they eliminate
redundant computations later on.
Hi George,
George Giorgidze wrote:
I would like to announce the first release of the set-monad library.
On Hackage: http://hackage.haskell.org/package/set-monad
Very cool. Seems to work fine. But I am wondering about the impact of
using your package on asymptotic complexity (and thereby, on
On Sat, Jun 16, 2012 at 3:57 AM, Tillmann Rendel
ren...@informatik.uni-marburg.de wrote:
George Giorgidze wrote:
I would like to announce the first release of the set-monad library.
On Hackage: http://hackage.haskell.org/package/set-monad
Very cool. Seems to work fine. But I am wondering
I would like to announce the first release of the set-monad library.
On Hackage: http://hackage.haskell.org/package/set-monad
The set-monad library exports the Set abstract data type and
set-manipulating functions. These functions behave exactly as their
namesakes from the Data.Set module of the
