[mlpack-git] (blog) master: details (771ab2b)

[gitdub at mlpack.org]

Repository : https://github.com/mlpack/blog
On branch  : master
Link       : https://github.com/mlpack/blog/compare/c011ca772bad62cbe5ac3c0f176f5fe318264b99...771ab2b5bd2db9a78d825ed83ce6a6c5090789a4

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

commit 771ab2b5bd2db9a78d825ed83ce6a6c5090789a4
Author: MarcosPividori <marcos.pividori at gmail.com>
Date:   Mon Jun 6 10:56:55 2016 -0300

    details


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

771ab2b5bd2db9a78d825ed83ce6a6c5090789a4
 content/blog/MarcosWeekOne.md | 9 ++++++---
 content/blog/MarcosWeekTwo.md | 4 ++--
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/content/blog/MarcosWeekOne.md b/content/blog/MarcosWeekOne.md
index a080ca5..48e8f2c 100644
--- a/content/blog/MarcosWeekOne.md
+++ b/content/blog/MarcosWeekOne.md
@@ -4,8 +4,11 @@ Tags: gsoc, knn, kfn
 Author: Marcos Pividori
 
 I am working this summer on the implementation of approximate nearest neighbor search.
-First, we want to update the existing dual tree algorithm to do approximate nearest neighbor search, modifying the prune rule to include an epsilon, as mentioned at the end of the paper [1](http://www.ratml.org/pub/pdf/2015faster.pdf).
-After reading the paper: "Tree-Independent Dual-Tree Algorithms" [2](http://www.ratml.org/pub/pdf/2013tree.pdf) in detail, I found some issues in the definition of the B2 bound. We were discussing about it in [3](http://github.com/mlpack/mlpack/issues/642) and, after thinking about the different special cases, we found some examples where actual definition could fail. We seem to have a solution. New week, I will work in updating existing code to fix this and compare the performance after this modification.
-When reviewing the implementation of tree types, I found a subtle mistake! Ball trees were using hyper rectangle bounds instead of ball bounds! [4](http://github.com/mlpack/mlpack/pull/646) It was fixed and is waiting to be merged.
+
+First, we want to update the existing dual tree algorithm to do approximate nearest neighbor search, modifying the prune rule to include an epsilon, as mentioned at the end of the paper [[1]](http://www.ratml.org/pub/pdf/2015faster.pdf).
+
+After reading the paper: "Tree-Independent Dual-Tree Algorithms" [[2]](http://www.ratml.org/pub/pdf/2013tree.pdf) in detail, I found some issues in the definition of the B2 bound. We were discussing about it in [[3]](http://github.com/mlpack/mlpack/issues/642) and, after thinking about the different special cases, we found some examples where actual definition could fail. We seem to have a solution. New week, I will work in updating existing code to fix this and compare the performance after this modification.
+
+When reviewing the implementation of tree types, I found a subtle mistake! Ball trees were using hyper rectangle bounds instead of ball bounds! [[4]](http://github.com/mlpack/mlpack/pull/646) It was fixed and is waiting to be merged.
 
 Next week, I plan to continue improving the neighbor search code, to fix the issue related to the bounds. Once this is working properly, I could add the modification to do approximate search and do some tests.
diff --git a/content/blog/MarcosWeekTwo.md b/content/blog/MarcosWeekTwo.md
index 8e321cd..c2f6be8 100644
--- a/content/blog/MarcosWeekTwo.md
+++ b/content/blog/MarcosWeekTwo.md
@@ -3,9 +3,9 @@ Date: 2016-05-05 21:00:00
 Tags: gsoc, knn, kfn
 Author: Marcos Pividori
 
-Last week we finished the discussion about neighbor search's bounds [1](http://github.com/mlpack/mlpack/issues/642).  I updated existing code to consider slighty different bounds. Then, I compared the performance, using the benchmarking system with a modification to measure the number of base cases for ALLKNN/ALLKFN. Results shown exactly the same num of base cases for many datasets, so we decided to go ahead and merge it.
+Last week we finished the discussion about neighbor search's bounds [[1]](http://github.com/mlpack/mlpack/issues/642).  I updated existing code to consider slighty different bounds. Then, I compared the performance, using the benchmarking system with a modification to measure the number of base cases for ALLKNN/ALLKFN. Results shown exactly the same num of base cases for many datasets, so we decided to go ahead and merge it.
 
-Then, I continued working in existing neighbor search code, updating the dual tree algorithm to do approximate nearest neighbor search. I modified the prune rule to include a relative error, as mentioned at the end of the paper [2](http://www.ratml.org/pub/pdf/2015faster.pdf), with a general implementation that works for both kfn and knn [3](http://github.com/MarcosPividori/mlpack/tree/approx-knn).
+Then, I continued working in existing neighbor search code, updating the dual tree algorithm to do approximate nearest neighbor search. I modified the prune rule to include a relative error, as mentioned at the end of the paper [[2]](http://www.ratml.org/pub/pdf/2015faster.pdf), with a general implementation that works for both kfn and knn [[3]](http://github.com/MarcosPividori/mlpack/tree/approx-knn).
 
 As we are doing approximate search, we can prune more than when an exact solution is required. For example, for knn, we consider the prune rule: