13:11 < mentekid> rcurtin: I think you're right, having k as a constant and solving for k^b makes no sense...

13:12 < mentekid> I guess it's a 2-d space (x, k) mapping to y

13:14 < rcurtin> yeah, otherwise it would only make sense to fit d * x^c (where d = k^b)

13:14 < rcurtin> er, d = a*k^b

13:15 < mentekid> this makes a few things simpler

13:15 < mentekid> also the implementation more likely to be correct :P

13:15 < rcurtin> :)

14:43 < mentekid> rcurtin: So, what I've done so far works

14:43 < mentekid> or it appears to

14:44 < mentekid> I still need to do the integration, binary search and input/output modules, but it's progressing.

14:45 < mentekid> should I open a PR so you can see the code? Maybe you'll catch mistakes I haven't seen (like the non-constant k for example)

15:25 < rcurtin> sure, that sounds good to me

15:26 < rcurtin> I think you have already opened that PR so I will look when I have a chance

15:29 < mentekid> Yeah I did a few minutes ago

16:54 < marcosirc> sumedhghaisas: Hi

16:55 < sumedhghaisas> marcosirc: Hey marcos...

16:55 < marcosirc> Hi sumedh! how are you?

16:55 < sumedhghaisas> so sorry for yesterday... I started reviewing your code...

16:55 < sumedhghaisas> but I was very tired...

16:56 < marcosirc> Ok, no problem. I can imagine.

16:56 < sumedhghaisas> Very big PR it is :)

16:56 < marcosirc> Yes! Because I have been working many weeks in this

16:57 < marcosirc> I couldn't make a PR before, because it was not ready...

16:57 < sumedhghaisas> yeah... I know :)

16:57 < marcosirc> I have madea big change in the last commits :)

16:57 < marcosirc> I think this week is very important

16:57 < sumedhghaisas> I got scared ... looking at the number of commits :P

16:57 < marcosirc> Haha

16:57 < sumedhghaisas> I am still checking the entire thing...

16:58 < marcosirc> Because next week I think I should focus on testing.

16:58 < sumedhghaisas> the design looks good...

16:58 < marcosirc> Ok.

16:58 < marcosirc> I have made an important change in the design in the last commits

16:58 < sumedhghaisas> I have almost finished with single tree traversal...

16:58 < sumedhghaisas> I am looking at the whole changes...

16:59 < sumedhghaisas> so commit level won;t matter...

16:59 < sumedhghaisas> also tests were failing...

16:59 < marcosirc> I am checking the appveyor failure right now

17:01 < sumedhghaisas> ohh okay...

17:18 < rcurtin> I haven't looked over the commits yet (I will when I have a chance), so maybe this point is already taken care of, but we should be sure that we can use defeatist search with other types of trees too

17:26 < marcosirc> rcurtin: Ok. Do you mean pure defeatist search? Removing the backtracking step?

17:26 < marcosirc> I can implement a new tree traverser

17:27 < marcosirc> But in that case we would be considering the decision boundary as I mentioned in the previous pdf file. Not the splitting hyperplane.

17:27 < marcosirc> I think this is not a problem. Just something to take into account.

17:28 < rcurtin> marcosirc: hmm, let me take a look at the code and I'll let you know what I think

17:28 < rcurtin> I have a long flight tomorrow which should be perfect for reviewing code :)

17:28 < marcosirc> OK! :) Great!!

17:29 < marcosirc> I think we could implemente a new tree traverser: "DefeatistSearchTraverser" which simply avoids the "rescore" step.

17:29 < marcosirc> But for the actual implementation of spill trees, I consider a more complicated traverser

17:29 < marcosirc> because it implements "hybrid spill search"

17:31 < rcurtin> yeah; I'll take a look and let you know what I think. I'll probably need to review the paper again too :)

17:50 < marcosirc> rcurtin: Ok, great!

17:52 < marcosirc> I have to add many tests for all the code developed.

17:52 < marcosirc> rcurtin: Also, I have been thinking about the implementation of NeighborSearch class.

17:53 < marcosirc> I think we should define a enum type

17:53 < marcosirc> with three members: NAIVE, SINGLE_MODE and DUAL_MODE

17:53 < marcosirc> this way, constructors will be clearer.

17:54 < marcosirc> instead of using combinations of boolean values

17:54 < marcosirc> in the future we could add a new member

17:54 < marcosirc> DEFEATIST_MODE

17:54 < rcurtin> sure, I don't have any issue with that

17:54 < rcurtin> again reverse compatibility is the only thing to keep in mind

17:55 < rcurtin> so I think in some cases, maybe it is better to open the ticket saying it should be done, then when 3.0.0 release comes close, do it then

17:55 < rcurtin> it's hard to have a "stable API" when there is always so much to improve :)

17:59 < marcosirc> Ok, yeah I agree. I was thinking about reverse compatibility too..

17:59 < marcosirc> Ok, I will open a new ticket about this.

18:02 < marcosirc> Also, I have been thinking about tree's implementation (if you are busy now we can talk in another moment :) ).

18:02 < marcosirc> I think we should have a general class for each tree type, and an internal class which represents the Node class.

18:03 < marcosirc> So we can hold the tree's specific information in the main class, like the value of some parameters, etc.

18:03 < marcosirc> Also, for BinarySpaceTrees, we could hold the information of oldFromNewReferences in that class.

18:04 < rcurtin> I've thought about that at length; but it doesn't make it easy to use a subtree

18:07 < marcosirc> Ok, yes, I understand. I am not sure it will be a good option, but with the current approach we have some disadvantages..

18:08 < marcosirc> Given a tree, we can't have any information about "how it was built".

18:08 < marcosirc> I mean, the parameters, like: leafSize, tau (overlapping size), etc.

18:09 < rcurtin> that's true; but if the user builds the tree themselves, then they already know the parameters

18:09 < rcurtin> and in many other cases, the class holding the tree might hold those parameters

18:10 < rcurtin> I agree it is not necessarily ideal, but I think that we can't encapsulate a tree in its own class, because then "tree.Child(0)" won't return the same type

18:10 < rcurtin> unless we have a separate "TreeType" and "NodeType" class, and I'd like to avoid that complexity

18:12 < marcosirc> Yeah, I understand. I started thinking about this when working with the neighbor search class, when we want to transmit ownership of a reference tree. Now, we have to make NSModel a friend class of NeighborSearch class, to set the oldFromNewReferences. I was thinking how to avoid this "friendship".

18:13 < marcosirc> Yeah, I agree. I was thinking of having 2 separate classes, like you mention.

18:13 < marcosirc> TreeType and NodeType. NodeType could be a nested class of TreeType.

18:17 < marcosirc> I agree that it could increase the complexity...

18:32 < marcosirc> I will continue thinking about this!

18:48 < rcurtin> I spent a long time thinking about it over the years, and the conclusion I came to is that the TreeType (with no NodeType) design was the most flexible and straightforward

19:51 < marcosirc> lozhnikov: Hi, how are you? I am adding a new tree trait: "HasDuplicatedPoints" to determine if a given point can be included in more than one node.

19:52 < marcosirc> I can see that RectangleTree's traits include: HasOverlappingChildren = true

19:53 < marcosirc> Does it only means that the nodes's bounding box can overlap, or it also means that nodes can share points?

19:53 < lozhnikov> marcosirc: Hi, no the R tree has not got duplicated points

19:53 < marcosirc> Ok, thanks!

19:54 < marcosirc> I mean every rectangle tree flavour.

19:55 < lozhnikov> yes, I understand. The original implementation of the R+ tree allows that behavior. But the algorithm that I've implemented avoids duplicated points.

19:57 < marcosirc> lozhnikov: Ok.