exceptions, errors, random

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

exceptions, errors, random

Dennis Raddle
I am wondering what exception/error and random classes I should use for my application.

The application will be doing Monte Carlo backtracking search. I want it to be multithreaded and run on all four cores on my MacBook. 

I need detailed error messages in order to investigate errors. So I will throw errors or exceptions, then catch them in lower functions and annotate them with the parameters or computations within the lower function, then re-throw until finally the exception pops into the terminal.

Because it's multi-threaded, at least some parts will needs to be in IO. Also, because it's a Monte Carlo algorithm it will need to make pseudorandom choices.

Perhaps I should put everything in the IO monad? This will give me access to threads and the standard generator seed. But how about throwing, catching/rethrowing exceptions in IO? I have done this in pure code before: not sure if it's better to do it that way, in which case I could put some kind of state monad to hold the random seed together with an error monad and IO at the core of the monad stack.

Any advice welcome.
D


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exceptions, errors, random

Dennis Raddle
Just want to bump this request as I have not gotten a reply.

On Fri, Jun 16, 2017 at 1:45 PM, Dennis Raddle <[hidden email]> wrote:
I am wondering what exception/error and random classes I should use for my application.

The application will be doing Monte Carlo backtracking search. I want it to be multithreaded and run on all four cores on my MacBook. 

I need detailed error messages in order to investigate errors. So I will throw errors or exceptions, then catch them in lower functions and annotate them with the parameters or computations within the lower function, then re-throw until finally the exception pops into the terminal.

Because it's multi-threaded, at least some parts will needs to be in IO. Also, because it's a Monte Carlo algorithm it will need to make pseudorandom choices.

Perhaps I should put everything in the IO monad? This will give me access to threads and the standard generator seed. But how about throwing, catching/rethrowing exceptions in IO? I have done this in pure code before: not sure if it's better to do it that way, in which case I could put some kind of state monad to hold the random seed together with an error monad and IO at the core of the monad stack.

Any advice welcome.
D



_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exceptions, errors, random

Ivan Lazar Miljenovic
There are two general schools of thought as to how to deal with exceptions:

* ExceptT/MonadError from transformers/mtl:
http://www.mega-nerd.com/erikd/Blog/CodeHacking/Haskell/what_do_you_mean.html

* The exceptions package (which is a lifted variant of
Control.Exception in base):
https://www.fpcomplete.com/blog/2016/11/exceptions-best-practices-haskell

On 20 June 2017 at 15:53, Dennis Raddle <[hidden email]> wrote:

> Just want to bump this request as I have not gotten a reply.
>
> On Fri, Jun 16, 2017 at 1:45 PM, Dennis Raddle <[hidden email]>
> wrote:
>>
>> I am wondering what exception/error and random classes I should use for my
>> application.
>>
>> The application will be doing Monte Carlo backtracking search. I want it
>> to be multithreaded and run on all four cores on my MacBook.
>>
>> I need detailed error messages in order to investigate errors. So I will
>> throw errors or exceptions, then catch them in lower functions and annotate
>> them with the parameters or computations within the lower function, then
>> re-throw until finally the exception pops into the terminal.
>>
>> Because it's multi-threaded, at least some parts will needs to be in IO.
>> Also, because it's a Monte Carlo algorithm it will need to make pseudorandom
>> choices.
>>
>> Perhaps I should put everything in the IO monad? This will give me access
>> to threads and the standard generator seed. But how about throwing,
>> catching/rethrowing exceptions in IO? I have done this in pure code before:
>> not sure if it's better to do it that way, in which case I could put some
>> kind of state monad to hold the random seed together with an error monad and
>> IO at the core of the monad stack.
>>
>> Any advice welcome.
>> D
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



--
Ivan Lazar Miljenovic
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exceptions, errors, random

Dennis Raddle
Looking at my application needs, such as access to pseudorandom numbers and threads, does this suggest a particular course of action?

D


On Tue, Jun 20, 2017 at 1:40 AM, Ivan Lazar Miljenovic <[hidden email]> wrote:
There are two general schools of thought as to how to deal with exceptions:

* ExceptT/MonadError from transformers/mtl:
http://www.mega-nerd.com/erikd/Blog/CodeHacking/Haskell/what_do_you_mean.html

* The exceptions package (which is a lifted variant of
Control.Exception in base):
https://www.fpcomplete.com/blog/2016/11/exceptions-best-practices-haskell

On 20 June 2017 at 15:53, Dennis Raddle <[hidden email]> wrote:
> Just want to bump this request as I have not gotten a reply.
>
> On Fri, Jun 16, 2017 at 1:45 PM, Dennis Raddle <[hidden email]>
> wrote:
>>
>> I am wondering what exception/error and random classes I should use for my
>> application.
>>
>> The application will be doing Monte Carlo backtracking search. I want it
>> to be multithreaded and run on all four cores on my MacBook.
>>
>> I need detailed error messages in order to investigate errors. So I will
>> throw errors or exceptions, then catch them in lower functions and annotate
>> them with the parameters or computations within the lower function, then
>> re-throw until finally the exception pops into the terminal.
>>
>> Because it's multi-threaded, at least some parts will needs to be in IO.
>> Also, because it's a Monte Carlo algorithm it will need to make pseudorandom
>> choices.
>>
>> Perhaps I should put everything in the IO monad? This will give me access
>> to threads and the standard generator seed. But how about throwing,
>> catching/rethrowing exceptions in IO? I have done this in pure code before:
>> not sure if it's better to do it that way, in which case I could put some
>> kind of state monad to hold the random seed together with an error monad and
>> IO at the core of the monad stack.
>>
>> Any advice welcome.
>> D
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



--
Ivan Lazar Miljenovic
[hidden email]
http://IvanMiljenovic.wordpress.com


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exceptions, errors, random

Ivan Lazar Miljenovic
On 21 June 2017 at 03:19, Dennis Raddle <[hidden email]> wrote:
> Looking at my application needs, such as access to pseudorandom numbers and
> threads, does this suggest a particular course of action?

For randomness, probably mwc-random, carrying the seed around in a
StateT with IO on the bottom of the stack.

For multi-threaded: parallelism or concurrency?  Simon Marlow's
Parallel and Concurrent Programming in Haskell is an excellent book on
the topic: http://shop.oreilly.com/product/0636920026365.do

>
> D
>
>
> On Tue, Jun 20, 2017 at 1:40 AM, Ivan Lazar Miljenovic
> <[hidden email]> wrote:
>>
>> There are two general schools of thought as to how to deal with
>> exceptions:
>>
>> * ExceptT/MonadError from transformers/mtl:
>>
>> http://www.mega-nerd.com/erikd/Blog/CodeHacking/Haskell/what_do_you_mean.html
>>
>> * The exceptions package (which is a lifted variant of
>> Control.Exception in base):
>> https://www.fpcomplete.com/blog/2016/11/exceptions-best-practices-haskell
>>
>> On 20 June 2017 at 15:53, Dennis Raddle <[hidden email]> wrote:
>> > Just want to bump this request as I have not gotten a reply.
>> >
>> > On Fri, Jun 16, 2017 at 1:45 PM, Dennis Raddle <[hidden email]>
>> > wrote:
>> >>
>> >> I am wondering what exception/error and random classes I should use for
>> >> my
>> >> application.
>> >>
>> >> The application will be doing Monte Carlo backtracking search. I want
>> >> it
>> >> to be multithreaded and run on all four cores on my MacBook.
>> >>
>> >> I need detailed error messages in order to investigate errors. So I
>> >> will
>> >> throw errors or exceptions, then catch them in lower functions and
>> >> annotate
>> >> them with the parameters or computations within the lower function,
>> >> then
>> >> re-throw until finally the exception pops into the terminal.
>> >>
>> >> Because it's multi-threaded, at least some parts will needs to be in
>> >> IO.
>> >> Also, because it's a Monte Carlo algorithm it will need to make
>> >> pseudorandom
>> >> choices.
>> >>
>> >> Perhaps I should put everything in the IO monad? This will give me
>> >> access
>> >> to threads and the standard generator seed. But how about throwing,
>> >> catching/rethrowing exceptions in IO? I have done this in pure code
>> >> before:
>> >> not sure if it's better to do it that way, in which case I could put
>> >> some
>> >> kind of state monad to hold the random seed together with an error
>> >> monad and
>> >> IO at the core of the monad stack.
>> >>
>> >> Any advice welcome.
>> >> D
>> >>
>> >
>> >
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > To (un)subscribe, modify options or view archives go to:
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> > Only members subscribed via the mailman list are allowed to post.
>>
>>
>>
>> --
>> Ivan Lazar Miljenovic
>> [hidden email]
>> http://IvanMiljenovic.wordpress.com
>
>



--
Ivan Lazar Miljenovic
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exceptions, errors, random

Dennis Raddle
Thanks for pointing me to mwc-random. I like that they provide a normal distribution; that is handy. 

I think by asking me parallelism or concurrency, you mean do I have algorithms that interact as they run in separate threads?

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"?

This is a pretty simple task. I hope that I don't have to delve deeply into concurrency/parallelism.

D

On Tue, Jun 20, 2017 at 3:59 PM, Ivan Lazar Miljenovic <[hidden email]> wrote:
On 21 June 2017 at 03:19, Dennis Raddle <[hidden email]> wrote:
> Looking at my application needs, such as access to pseudorandom numbers and
> threads, does this suggest a particular course of action?

For randomness, probably mwc-random, carrying the seed around in a
StateT with IO on the bottom of the stack.

For multi-threaded: parallelism or concurrency?  Simon Marlow's
Parallel and Concurrent Programming in Haskell is an excellent book on
the topic: http://shop.oreilly.com/product/0636920026365.do

>
> D
>
>
> On Tue, Jun 20, 2017 at 1:40 AM, Ivan Lazar Miljenovic
> <[hidden email]> wrote:
>>
>> There are two general schools of thought as to how to deal with
>> exceptions:
>>
>> * ExceptT/MonadError from transformers/mtl:
>>
>> http://www.mega-nerd.com/erikd/Blog/CodeHacking/Haskell/what_do_you_mean.html
>>
>> * The exceptions package (which is a lifted variant of
>> Control.Exception in base):
>> https://www.fpcomplete.com/blog/2016/11/exceptions-best-practices-haskell
>>
>> On 20 June 2017 at 15:53, Dennis Raddle <[hidden email]> wrote:
>> > Just want to bump this request as I have not gotten a reply.
>> >
>> > On Fri, Jun 16, 2017 at 1:45 PM, Dennis Raddle <[hidden email]>
>> > wrote:
>> >>
>> >> I am wondering what exception/error and random classes I should use for
>> >> my
>> >> application.
>> >>
>> >> The application will be doing Monte Carlo backtracking search. I want
>> >> it
>> >> to be multithreaded and run on all four cores on my MacBook.
>> >>
>> >> I need detailed error messages in order to investigate errors. So I
>> >> will
>> >> throw errors or exceptions, then catch them in lower functions and
>> >> annotate
>> >> them with the parameters or computations within the lower function,
>> >> then
>> >> re-throw until finally the exception pops into the terminal.
>> >>
>> >> Because it's multi-threaded, at least some parts will needs to be in
>> >> IO.
>> >> Also, because it's a Monte Carlo algorithm it will need to make
>> >> pseudorandom
>> >> choices.
>> >>
>> >> Perhaps I should put everything in the IO monad? This will give me
>> >> access
>> >> to threads and the standard generator seed. But how about throwing,
>> >> catching/rethrowing exceptions in IO? I have done this in pure code
>> >> before:
>> >> not sure if it's better to do it that way, in which case I could put
>> >> some
>> >> kind of state monad to hold the random seed together with an error
>> >> monad and
>> >> IO at the core of the monad stack.
>> >>
>> >> Any advice welcome.
>> >> D
>> >>
>> >
>> >
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > To (un)subscribe, modify options or view archives go to:
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> > Only members subscribed via the mailman list are allowed to post.
>>
>>
>>
>> --
>> Ivan Lazar Miljenovic
>> [hidden email]
>> http://IvanMiljenovic.wordpress.com
>
>



--
Ivan Lazar Miljenovic
[hidden email]
http://IvanMiljenovic.wordpress.com


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exceptions, errors, random

Ivan Lazar Miljenovic
On 23 June 2017 at 14:54, Dennis Raddle <[hidden email]> wrote:

> Thanks for pointing me to mwc-random. I like that they provide a normal
> distribution; that is handy.
>
> I think by asking me parallelism or concurrency, you mean do I have
> algorithms that interact as they run in separate threads?
>
> 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"?
>
> This is a pretty simple task. I hope that I don't have to delve deeply into
> concurrency/parallelism.

Parallelism: split data set up, run the same operation on each sub-set.
Concurrency: do multiple things at once, possibly unrelated.

Many languages use concurrency to implement parallelism; Haskell
doesn't: see https://wiki.haskell.org/Parallelism_vs._Concurrency and
https://wiki.haskell.org/Parallel

For a start, have a look at the parallel package:
http://hackage.haskell.org/package/parallel ; in particular, par can
be used to fork off a new thread, and pseq can be used to ensure a
thread finishes before you continue.

>
> D
>
> On Tue, Jun 20, 2017 at 3:59 PM, Ivan Lazar Miljenovic
> <[hidden email]> wrote:
>>
>> On 21 June 2017 at 03:19, Dennis Raddle <[hidden email]> wrote:
>> > Looking at my application needs, such as access to pseudorandom numbers
>> > and
>> > threads, does this suggest a particular course of action?
>>
>> For randomness, probably mwc-random, carrying the seed around in a
>> StateT with IO on the bottom of the stack.
>>
>> For multi-threaded: parallelism or concurrency?  Simon Marlow's
>> Parallel and Concurrent Programming in Haskell is an excellent book on
>> the topic: http://shop.oreilly.com/product/0636920026365.do
>>
>> >
>> > D
>> >
>> >
>> > On Tue, Jun 20, 2017 at 1:40 AM, Ivan Lazar Miljenovic
>> > <[hidden email]> wrote:
>> >>
>> >> There are two general schools of thought as to how to deal with
>> >> exceptions:
>> >>
>> >> * ExceptT/MonadError from transformers/mtl:
>> >>
>> >>
>> >> http://www.mega-nerd.com/erikd/Blog/CodeHacking/Haskell/what_do_you_mean.html
>> >>
>> >> * The exceptions package (which is a lifted variant of
>> >> Control.Exception in base):
>> >>
>> >> https://www.fpcomplete.com/blog/2016/11/exceptions-best-practices-haskell
>> >>
>> >> On 20 June 2017 at 15:53, Dennis Raddle <[hidden email]>
>> >> wrote:
>> >> > Just want to bump this request as I have not gotten a reply.
>> >> >
>> >> > On Fri, Jun 16, 2017 at 1:45 PM, Dennis Raddle
>> >> > <[hidden email]>
>> >> > wrote:
>> >> >>
>> >> >> I am wondering what exception/error and random classes I should use
>> >> >> for
>> >> >> my
>> >> >> application.
>> >> >>
>> >> >> The application will be doing Monte Carlo backtracking search. I
>> >> >> want
>> >> >> it
>> >> >> to be multithreaded and run on all four cores on my MacBook.
>> >> >>
>> >> >> I need detailed error messages in order to investigate errors. So I
>> >> >> will
>> >> >> throw errors or exceptions, then catch them in lower functions and
>> >> >> annotate
>> >> >> them with the parameters or computations within the lower function,
>> >> >> then
>> >> >> re-throw until finally the exception pops into the terminal.
>> >> >>
>> >> >> Because it's multi-threaded, at least some parts will needs to be in
>> >> >> IO.
>> >> >> Also, because it's a Monte Carlo algorithm it will need to make
>> >> >> pseudorandom
>> >> >> choices.
>> >> >>
>> >> >> Perhaps I should put everything in the IO monad? This will give me
>> >> >> access
>> >> >> to threads and the standard generator seed. But how about throwing,
>> >> >> catching/rethrowing exceptions in IO? I have done this in pure code
>> >> >> before:
>> >> >> not sure if it's better to do it that way, in which case I could put
>> >> >> some
>> >> >> kind of state monad to hold the random seed together with an error
>> >> >> monad and
>> >> >> IO at the core of the monad stack.
>> >> >>
>> >> >> Any advice welcome.
>> >> >> D
>> >> >>
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Haskell-Cafe mailing list
>> >> > To (un)subscribe, modify options or view archives go to:
>> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> >> > Only members subscribed via the mailman list are allowed to post.
>> >>
>> >>
>> >>
>> >> --
>> >> Ivan Lazar Miljenovic
>> >> [hidden email]
>> >> http://IvanMiljenovic.wordpress.com
>> >
>> >
>>
>>
>>
>> --
>> Ivan Lazar Miljenovic
>> [hidden email]
>> http://IvanMiljenovic.wordpress.com
>
>



--
Ivan Lazar Miljenovic
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exceptions, errors, random

Dennis Raddle
Thanks! Quick question, if I can split my task into 4 completely independent subtasks, what if I code a single program, then invoke this program on each of the 4 subtasks and let the OS give each program a CPU core (there are 4 cores on my MacBook)? Would that be a simple way to take advantage of parallelism? 

Note that it's always a good idea to start with a simpler prototype anyway ("solve a simpler problem first" in the words of Poyla) so it's a good idea for me to write a prototype that does not use parallelism. If I can then make it parallel just by invoking it four times and let the OS do its thing, that would be nice.

D


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exceptions, errors, random

Ivan Lazar Miljenovic
On 23 June 2017 at 16:10, Dennis Raddle <[hidden email]> wrote:
> Thanks! Quick question, if I can split my task into 4 completely independent
> subtasks, what if I code a single program, then invoke this program on each
> of the 4 subtasks and let the OS give each program a CPU core (there are 4
> cores on my MacBook)? Would that be a simple way to take advantage of
> parallelism?

Not a very efficient method, but in essence yes.

>
> Note that it's always a good idea to start with a simpler prototype anyway
> ("solve a simpler problem first" in the words of Poyla) so it's a good idea
> for me to write a prototype that does not use parallelism. If I can then
> make it parallel just by invoking it four times and let the OS do its thing,
> that would be nice.

My take would be "build a non-threaded/serial solution, then try and
parallelise different parts".

>
> D
>



--
Ivan Lazar Miljenovic
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Loading...