<div dir="ltr"><div>Thanks for pointing me to mwc-random. I like that they provide a normal distribution; that is handy. </div><div><br></div>I think by asking me parallelism or concurrency, you mean do I have algorithms that interact as they run in separate threads?<div><br></div><div>This is a backtracking search algorithm, so each thread can explore a subset of the search space with no need to communicate with other threads. Does that mean "concurrency"?</div><div><br></div><div>This is a pretty simple task. I hope that I don't have to delve deeply into concurrency/parallelism.</div><div><br></div><div>D</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 20, 2017 at 3:59 PM, Ivan Lazar Miljenovic <span dir="ltr"><<a href="mailto:ivan.miljenovic@gmail.com" target="_blank">ivan.miljenovic@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 21 June 2017 at 03:19, Dennis Raddle <<a href="mailto:dennis.raddle@gmail.com">dennis.raddle@gmail.com</a>> wrote:<br>
> Looking at my application needs, such as access to pseudorandom numbers and<br>
> threads, does this suggest a particular course of action?<br>
<br>
</span>For randomness, probably mwc-random, carrying the seed around in a<br>
StateT with IO on the bottom of the stack.<br>
<br>
For multi-threaded: parallelism or concurrency?  Simon Marlow's<br>
Parallel and Concurrent Programming in Haskell is an excellent book on<br>
the topic: <a href="http://shop.oreilly.com/product/0636920026365.do" rel="noreferrer" target="_blank">http://shop.oreilly.com/<wbr>product/0636920026365.do</a><br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> D<br>
><br>
><br>
> On Tue, Jun 20, 2017 at 1:40 AM, Ivan Lazar Miljenovic<br>
> <<a href="mailto:ivan.miljenovic@gmail.com">ivan.miljenovic@gmail.com</a>> wrote:<br>
>><br>
>> There are two general schools of thought as to how to deal with<br>
>> exceptions:<br>
>><br>
>> * ExceptT/MonadError from transformers/mtl:<br>
>><br>
>> <a href="http://www.mega-nerd.com/erikd/Blog/CodeHacking/Haskell/what_do_you_mean.html" rel="noreferrer" target="_blank">http://www.mega-nerd.com/<wbr>erikd/Blog/CodeHacking/<wbr>Haskell/what_do_you_mean.html</a><br>
>><br>
>> * The exceptions package (which is a lifted variant of<br>
>> Control.Exception in base):<br>
>> <a href="https://www.fpcomplete.com/blog/2016/11/exceptions-best-practices-haskell" rel="noreferrer" target="_blank">https://www.fpcomplete.com/<wbr>blog/2016/11/exceptions-best-<wbr>practices-haskell</a><br>
>><br>
>> On 20 June 2017 at 15:53, Dennis Raddle <<a href="mailto:dennis.raddle@gmail.com">dennis.raddle@gmail.com</a>> wrote:<br>
>> > Just want to bump this request as I have not gotten a reply.<br>
>> ><br>
>> > On Fri, Jun 16, 2017 at 1:45 PM, Dennis Raddle <<a href="mailto:dennis.raddle@gmail.com">dennis.raddle@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> I am wondering what exception/error and random classes I should use for<br>
>> >> my<br>
>> >> application.<br>
>> >><br>
>> >> The application will be doing Monte Carlo backtracking search. I want<br>
>> >> it<br>
>> >> to be multithreaded and run on all four cores on my MacBook.<br>
>> >><br>
>> >> I need detailed error messages in order to investigate errors. So I<br>
>> >> will<br>
>> >> throw errors or exceptions, then catch them in lower functions and<br>
>> >> annotate<br>
>> >> them with the parameters or computations within the lower function,<br>
>> >> then<br>
>> >> re-throw until finally the exception pops into the terminal.<br>
>> >><br>
>> >> Because it's multi-threaded, at least some parts will needs to be in<br>
>> >> IO.<br>
>> >> Also, because it's a Monte Carlo algorithm it will need to make<br>
>> >> pseudorandom<br>
>> >> choices.<br>
>> >><br>
>> >> Perhaps I should put everything in the IO monad? This will give me<br>
>> >> access<br>
>> >> to threads and the standard generator seed. But how about throwing,<br>
>> >> catching/rethrowing exceptions in IO? I have done this in pure code<br>
>> >> before:<br>
>> >> not sure if it's better to do it that way, in which case I could put<br>
>> >> some<br>
>> >> kind of state monad to hold the random seed together with an error<br>
>> >> monad and<br>
>> >> IO at the core of the monad stack.<br>
>> >><br>
>> >> Any advice welcome.<br>
>> >> D<br>
>> >><br>
>> ><br>
>> ><br>
>> > ______________________________<wbr>_________________<br>
>> > Haskell-Cafe mailing list<br>
>> > To (un)subscribe, modify options or view archives go to:<br>
>> > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
>> > Only members subscribed via the mailman list are allowed to post.<br>
>><br>
>><br>
>><br>
>> --<br>
>> Ivan Lazar Miljenovic<br>
>> <a href="mailto:Ivan.Miljenovic@gmail.com">Ivan.Miljenovic@gmail.com</a><br>
>> <a href="http://IvanMiljenovic.wordpress.com" rel="noreferrer" target="_blank">http://IvanMiljenovic.<wbr>wordpress.com</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
Ivan Lazar Miljenovic<br>
<a href="mailto:Ivan.Miljenovic@gmail.com">Ivan.Miljenovic@gmail.com</a><br>
<a href="http://IvanMiljenovic.wordpress.com" rel="noreferrer" target="_blank">http://IvanMiljenovic.<wbr>wordpress.com</a><br>
</div></div></blockquote></div><br></div>