We're all guilty of throwing around the bang patterns to fix performance problems, and that is a reasonable solution.  But if you wish to understand the problem, see if you can narrow down much of your leak to a specific field within one of your types, then you can look at epoch and sub functions and identify why that particular field is not being fully evaluated by the time you have returned from epoch.  Hopefully it will be obvious in hindsight and you will not run into this next time you have similar code.  GHCI's debugger may also give you a nice way to determine where your problem lies.

On Mon, Jan 26, 2015 at 11:45 AM, Hans Georg Schaathun <georg+haskell@schaathun.net> wrote:
On Mon, Jan 26, 2015 at 09:55:03AM -0500, David McBride wrote:
> I don't think the problem is with trainNetwork, but rather epoch.  You
> might try adjusting your network datatype and sub datatypes in the manner
> of data Network = Network !Int !Int until you narrow down which piece is
> causing the problem.

It turns out that you are absolutely right.
A number of randomly inserted bang patterns got rid of the overflow.
Thanks a lot for the idea..

I feel even more clueless than I used too, but I have at least a way
to proceed.

--
:-- Hans Georg
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners