[mlpack-git] (blog) master: Fixes typo (e599a31)

[gitdub at mlpack.org]

Repository : https://github.com/mlpack/blog
On branch  : master
Link       : https://github.com/mlpack/blog/compare/d2e2a4ead1532bd0ed875fa307bd70e5d76e3bed...e599a31f0db49068397033b3e6c15e2e9f969ec5

>---------------------------------------------------------------

commit e599a31f0db49068397033b3e6c15e2e9f969ec5
Author: Yannis Mentekidis <mentekid at gmail.com>
Date:   Mon Jun 27 16:43:04 2016 +0100

    Fixes typo


>---------------------------------------------------------------

e599a31f0db49068397033b3e6c15e2e9f969ec5
 content/blog/YannisWeekFive.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/blog/YannisWeekFive.md b/content/blog/YannisWeekFive.md
index 5ff0772..94eb397 100644
--- a/content/blog/YannisWeekFive.md
+++ b/content/blog/YannisWeekFive.md
@@ -42,7 +42,7 @@ OpenMP can force single-core execution of parts of the code with `#pragma omp at
 
 # Thread book-keeping
 
-Once I was done with that and had it tested, I started implementing code to keep track of how many threads we use. That code started becoming very complicated, so I considered implementing a thread-control class and managing threads through it, but that has the potential of complicating the code too much. Many of the parts we're intervening with already have an increased level of code complexity (long functions with a lot of branching) and so adding more complexity might make the next person to look at the code want to learn where I leave and come murder me - something I would very much like to avoid.
+Once I was done with that and had it tested, I started implementing code to keep track of how many threads we use. That code started becoming very complicated, so I considered implementing a thread-control class and managing threads through it, but that has the potential of complicating the code too much. Many of the parts we're intervening with already have an increased level of code complexity (long functions with a lot of branching) and so adding more complexity might make the next person to look at the code want to learn where I live and come murder me - something I would very much like to avoid.
 
 So, I ended up going with a simpler solution. OpenMP by default does not allow for nested parallelism - that is, it doesn't allow a spawned thread to spawn threads of its own. This is very good: it's easy to accidentally get yourself in recursive situations where spawning more threads that spawn more threads (and so on) leads to either the program to crash or it being very slow.